#bzr 2008-03-10
<Odd_Bloke> abentley: Thanks for the review. :)  I'll resubmit tomorrow.
<abentley> Odd_Bloke: np
<abentley> Odd_Bloke: in fact, KeyError is at least a plausible exception for name_hook to throw.
<mwhudson> does anyone have a clue how to do log-type operations without a whole heap of whole-history operations yet?
<ubotu> New bug: #200412 in bzr "Undescriptive error message when user isn't part of LP team." [Medium,Confirmed] https://launchpad.net/bugs/200412
<red> hi, i ran the command " bzr init-repo sftp://username@silenceisdefeat.org/~/repo" and bzr was hung up without any output. I use bzr 1.2 standalone win32 version under cygwin bash shell. How can I debug my problem?
<ubotu> New bug: #200413 in bzr-webserve "Rss feeds should show revisions" [Undecided,New] https://launchpad.net/bugs/200413
<bob2> have a look in ~/.bzr.log
<red> thx
* bpeterson changed the topic of #bzr to: "http://bazaar-vcs.org/ | Bazaar 1.2 is out! | https://launchpad.net/bzr/1.2/1.2"
<red> This is the content of .bzr.log:
<red> bzr arguments: [u'init-repo', u'sftp://username@silenceisdefeat.org/~/repo']
<red> looking for plugins in C:/Documents and Settings/jerryc/Application Data/bazaar/2.0/plugins
<red> looking for plugins in C:/Program Files/Bazaar/plugins
<red> looking for plugins in c:\Program Files\Bazaar\lib\library.zip\bzrlib\plugins
<red> Looking for plugins in 'c:\\Program Files\\Bazaar\\lib\\library.zip\\bzrlib\\plugins'
<red> Names in archive: ['__init__.pyc', 'launchpad/__init__.pyc', 'launchpad/account.pyc', 'launchpad/lp_indirect.pyc', 'launchpa
<red> I can not figure out from this content. should i install python and bzr source to debug?
<Peng> red: Certain -D options might help.
<Peng> I dunno.
<red> ok, I will try _D
<bob2> you need a -Dxxx option, but I can't seem to find the list of them anymore
<Peng> bzr help global-options
<Peng> I dunno which one would help though.
<red> thx
<Peng> None of them seem relevant to me.
<Peng> red: Do other things over sftp work?
<Peng> red: I'd guess it has to do with prompting you for your password.
<Peng> But I dunno.
<red> is this command correct " bzr -Derror init-repo --no-tree sftp://chenbin@silenceisdefeat.org/~/repo"? I tried "sftp://username:passwd@url
<red> there is no prompt for password if i run "sftp://username@url"
<Peng> Yeah, but -Derror isn't helpful here..
<Peng> Does ~ work?
<Peng> I've never used it.
<fullermd> On sftp it does; bzr+ssh doesn't.
<fullermd> (but don't worry, that'll be fixed a release or two after the smart server is added)
<Peng> I just tried it on both sftp and bzr+ssh and it seemed to screw up badly.
<red> real command is "bzr init-repo sftp://username@silenceisdefeat.org/~/repo"
<Peng> Never mind, I'm an idiot.
<red> I created repo at first on remote server
<red> I cannot install software on silenceisdefeat.org
<Peng> (I was using "sftp//" instead of "sftp://".)
<bob2> does 'ssh username@silenceisdefeat.org ls ~/repo' work?
<red> sh username@silenceisdefeat.org "ls ~/repo" does work.
<red> ssh username@silenceisdefeat.org "ls ~/repo" does work.
<red> I've got it
<red> this seems a bug of bzr
<red> I don't know why, but on the dos command shell, I succeeded and got the password prompt. in the cygwin, there is no password prompt and the whole program is hung up.
<red> As I mentioned af first, I install bazaar 1.2 standalone version. But I run the bzr command in cygwin bash shell.
<red> I reported the bug at https://bugs.launchpad.net/bzr/+bug/200436. Thank you all.
<ubotu> Launchpad bug 200436 in bzr "bazaar 1.2 (standalone) failed in cygwin shell" [Undecided,New]
<ubotu> New bug: #200436 in bzr "bazaar 1.2 (standalone) failed in cygwin shell" [Undecided,New] https://launchpad.net/bugs/200436
<Farhadix> hi guys , where I can set what revision that I want to branch?
<Peng> Hopefully he figured it out...
<muszek> hi... I'm just learning bzr.  how would I find out when (which revnos) was a particular file changed?
<Peng> muszek: bzr log file? bzr annotate file?
<muszek> Peng: thanks
<jelmer> dato: ping
<dato> jelmer: pong
<jelmer> dato: I was wondering if you could sponsor a bzr-dbus upload?
<dato> jelmer: yes, I noted it in my TODO when you sent mail to -maint
<jelmer> dato: Cool, thanks.
<dato> jelmer: I just need to find a bit of time for it :)
<jelmer> :-)
<jelmer> We missed at the sprint last week!
 * dato wonders if "you" or something else is missing above
<jelmer> uhm, yes :-)
<dato> *g*
<uniscript> any idea when bzr-svn for bzr 1.2 will be available?
<jelmer> uniscript: Hopefully somewhere at the end of this week
<uniscript> OK great ta
<nevans> jelmer: I'm up to date with http://people.samba.org/bzr/jelmer/bzr-svn/stable/, and I'm getting "using experimental bzr-svn mappings; output may change between revisions" . . . there's nothing to worry about as far as normal usage (esp. with respect to data-loss), is there?  :-)
<jelmer> nevans: you should not be using it for production type data but a release instead
<ubotu> New bug: #200569 in bzr "[PATCH] v1.2 setup.py fails under python 2.3.5" [Medium,Confirmed] https://launchpad.net/bugs/200569
<nevans> jelmer: thanks.  I'll switch to one of the release branches.
<nevans> jelmer: should I delete my svn-cache or my bzr repo?  could running off of the newer code have "corrupted" either of them so that the older release branch of bzr-svn won't know how to cope?
<ubotu> New bug: #200575 in bzr ""Address already in use " crashes smart server" [Undecided,New] https://launchpad.net/bugs/200575
<jelmer> nevans: In theory, yes. In practice however, there haven't been any regressions recently afaik
<LarstiQ> jelmer: s/adaption/adoption/
<jelmer> LarstiQ: ?
<LarstiQ> jelmer: the title of your blog post :)
<jelmer> doh!
<AfC> jelmer: I forgot to ask you last week. What's the bzr-svn release that corresponds to bzr 1.2?
<jelmer> AfC: There is none yet
<jelmer> I had meant to release it last week but was distracted by other things
<AfC> I'm sitting here at the GTK hackfest listening to these guys next to me absolutely slaughter themselves fighting with git usage. I'd like to just go "and here it is in bzr" but I kinda need to have my shit together first
<AfC> jelmer: certainly
<AfC> jelmer: no worries
 * AfC wonders if his distro has backported the subversion changes that bzr-svn relies on.
<jelmer> AfC: what distro are you running?
<AfC> I hope so. I had a very poor time trying to get subversion working built from source.
<AfC> jelmer: Gentoo
<jelmer> AfC: There is an overlay (not sure what that means exactly) that has them
<jelmer> https://edge.launchpad.net/bzr-gentoo-overlay
<AfC> jelmer: overlay is the equivalent of "well, I posted a patch". Until it's into Gentoo's official tree it's meaningless.
<jelmer> ah, ok
<AfC> It's like expecting people to depend on a .deb that's not official. It may exist, but it's not usable without  a fight
<fullermd> Don't worry, it'll all be fixed when svn 1.5 is released...   I'm sure it'll happen in a week or two, no problem.
<AfC> fullermd: oh really? That's encouraging
<AfC> [Part of this is that someone did an import of GTK using launchpad, but that's really not any use so long as the upstream project is using Subversion]
<fullermd> Well, it's been a couple weeks out for, like, 18 months now...
<AfC> I suppose I could risk trying that overlay. I don't know who wrote it, what's in it, or whether it is trustworthy.
<AfC> fullermd: that too
<AfC> Now if launchpad used bzr-svn, THAT would be useful.
<Peng> Using other overlays in Gentoo is pretty easy, IIRC.
<Peng> More like adding something to your /etc/apt/sources.list.
<AfC> I didn't say it wasn't easy. I said it wasn't sound
<Peng> Ok.
<AfC> [and even more pragmatically, in my experience when someone does a private overlay the problem goes away for them so they no longer are incented to push their work to upstream (in this case, the distro proper) - which means the problem remains unsolved for everyone else]
<AfC> [so, for me to go and use that overlay would mean I would no longer be agitating for the problem to be fixed, and the quality level for everyone else remains low. Far better for bzr if the necessary fixes get into Portage officially]
<Odd_Bloke> AfC: LP does SVN imports...
<AfC> Odd_Bloke: but you don't mean "using bzr-svn to publish a branch which is actually backed by an external project that is in Subversion" do you?
<Odd_Bloke> AfC: Probably not, but I'm not sure I understand exactly what you mean. :)
<AfC> import (as I understand it) is a one way transform for a project that is switching VCS. bzr-svn allows you to use Bazaar against an upstream project that uses (and will continue to use) Subversion
<AfC> what I was just suggesting would be interesting & cool would be
<Odd_Bloke> AfC: LP does tracking imports, so that any new upstream revisions are mirrored.
<AfC> if Launchpad hosted the bzr-svn infrastructure and sync'd against upstream
<AfC> Hm.
<jelmer> AfC: it has been discussed in the past
<AfC> jelmer: I didn't really think it was likely to be an original idea
<AfC> I'm probably only sensitive to this because it's taken a while for me to get bzr-svn up and running
<jelmer> AfC: However, the restrictions that bzr-svn puts on the way conversions are done make it impossible to be used by launchpad
<AfC> Well, I'm just as happy to leave them out of it.
<jelmer> AfC: bzr-svn uses deterministic revision ids so can't change the way mappings are done without changing the revision ids
<abentley> jelmer: oh?  What restrictions are these?
<AfC> jelmer: interesting
<jelmer> abentley: I meant the referential integrity has to be maintained
<abentley> Why is that a problem?
<jelmer> it makes it impossible to change the mappings halfway through
<jelmer> without changing revids
<jelmer> if I add support for svn:keywords in bzr-svn now, I need to change the revision id prefix it's using
<jelmer> wheras launchpad could just add support for it and add it in the new revisions it imports without users getting funny "Branches diverged" errors
<abentley> Otoh, deterministic conversions are useful, and Launchpad might be willing to put up with that upgrade pain for such a gain.
<jelmer> abentley: True, but afaik that was the reason launchpad decided against bzr-svn a while back
<jelmer> abentley: btw, did path tokens get discussed later in the week during the sprint ?
<abentley> No, they were never discussed.
<Odd_Bloke> Could someone vote 'Resubmit' on http://bundlebuggy.aaronbentley.com/request/%3C20080310005229.11704edf@lapbert.oxbridgetech%3E for me?
<abentley> Odd_Bloke: Just submit the fixed version.
<jelmer> abentley: :-(
<Odd_Bloke> abentley: Sure. :)
<jelmer> hmm, I think this is the first year I haven't brought up revision id aliases
<jelmer> :-P
<Prodoc> Earlier I started with putting an existing project folder under version control (init, add, commit), now I'd like to have that folder as a repository and move the existing files to a subfolder ('main') to allow me to create branches in separate folders next to the 'main' subfolder. How should I proceed? Is it possible to do this afterwards and keeping the current revisions?
<Odd_Bloke> Prodoc: Create a separate shared repo (using 'bzr init-repo repo') and 'bzr branch <existing dir> repo/main'.
<Prodoc> Odd_Bloke: performing 'bzr branch <existing dir> repo/main' before or after I copied the existing project (including the .bzr folder I assume), to the 'main' folder?
<Odd_Bloke> Prodoc: The 'bzr branch' will do the copying, as well as using the shared repository.
<Prodoc> so I just have to perform the 'bzr init-repo repo' on the current version controlled folder?
<Odd_Bloke> Prodoc: It's best to do it outside of the version-controlled folder, to avoid confusion.
<Odd_Bloke> You can move the repository (and it's branches) where you want later.
<Prodoc> ah yes, now I see what you mean, cheers
<Prodoc> ow, and the existing revision history will be retained?
<LarstiQ> yes
<LarstiQ> hi poolie
<Pengwn> How is bazzar diff from git ?
<LeoNerd> How is an orange different to an apple?
<Pengwn> ok I will get to the point.
<Odd_Bloke> git has a lot more citric acid? :p
<Pengwn> I found these distributed scms suffer compatibility between windows and linuxes
<Pengwn> not really distribted.
<LeoNerd> Also bear in mind that while we're bzr users in here, many of us won't know git that well
<LeoNerd> Or at all
<Pengwn> basically how easy to get my revisions between windows and linux machines.
<Pengwn> so I don't have to worry about setting up ssh or starting a deamon to pull/push to and from.
<LarstiQ> afaik, bzr still has better windows support than git
<Peng> Bazaar has pretty good Windows compatibility, but not many of the developers concentrate on Windows, and it has case-insensitive issues.
<LeoNerd> The repo format is portable, the program is portable... to my knowledge though, bzr won't itself handle linefeed issues
<LarstiQ> Peng: indeed
<LarstiQ> LeoNerd: we want to do that though
<Pengwn> I don't mind even if would handle ascii files as binary objs.
<Peng> The current workaround is using a text editor that doesn't suck. :P
<fullermd> Oh, that's not necessarily a requirement.  People could even use emacs...
<Pengwn> or vim.
<LarstiQ> tsk :P
<LeoNerd> (g)vim can easily cope with either line format anywhere
<LeoNerd> But.. I imagine you're going to be storing source code, etc..?
<LarstiQ> the problem is other tools, like, say, patch
<LeoNerd> Make sure the compiler/interpreter on each platform can cope
<luks_> LarstiQ: patch will happily convert line endings
<LarstiQ> luks_: does it nowadays? It sure used to convert everything to native on windows.
<luks_> at least the one on windows does
<LarstiQ> anyway, for interested people, http://bazaar-vcs.org/SprintLondonMarch08/Brainstorms and http://bazaar-vcs.org/LineEndings would be starting points for implementing it
<Pengwn> I just need a simple tool to efficently transfer versioned  binary diffs between windows and linux and not worry about setting up a whole lot of servers doing push and pull it should simply ask during syncing chose the remote and local when conflicts arrive.
<luks_> Pengwn: that's as trivial as running "bzr send"
<luks_> LarstiQ: the problem with implementing in is that bzrlib reads from the working tree all over the source base :(
<luks_> there is no central place for such operations
<Pengwn> when I do bzr send from a window machine how would the other window machine recieve it?
<LarstiQ> luks_: reads or writes?
<luks_> both, and md5sums
<LarstiQ> luks_: the idea is to have a transform layer via tree operations
<luks_> I've tried it a few months ago, but I gave up as it would mean refactoring quite a lot of code
<luks_> Pengwn: "bzr send" works over email
<LarstiQ> luks_: did you document your experiences somewhere?
<luks_> so yuou get the patch by mail, and then "bzr pull" it
<luks_> LarstiQ: nope
<LarstiQ> ok
<luks_> just in my private and probably already deleted branch :)
<LarstiQ> doh :P
<Pengwn> to put it a little simpler I would like to have versioned files with unison syncing and samba transparency.
<Pengwn> any tool that would remove the trouble of setting up samba would be awesome.
<luks_> not sure if that's simpler
 * luks_ doesn't know that means :)
<luks_> Pengwn: bzr is a version control tool, not a backup solution and not directory sync tool
<luks_> if your only intention is to move files between machines, bzr or any other vcs is probably not going to make you happy
<Pengwn> yep that's what I am looking for then a versioned diff backup solution able to sync from any linux window system.
<LeoNerd> unison ?
<LeoNerd> I've only used it between Linux boxen, but I know it's designed for Lin/Win or Win/Win too
<Pengwn> problem with unison it goes thru the whole directory structure and takes to much band width this way git handles better with sha1 comparison but pulling and pushing to linux is ok but to windows is a pain in the ***
<LeoNerd> Umm...
<LeoNerd> unison runs on both machines
<LeoNerd> It does local timestamp and checksumming, nowhere near the network
<LeoNerd> You have to run it _on_ both machines, though
<LeoNerd> Running it on one side to do a local-to-SMB isn't going to gain you anythingh
<Pengwn> how hard is it to setup bazar to do bzr send and get ?
<poolie> Pengwn: pretty easy, assuming there is a reasonable way to send mail from the source
<poolie> like either sendmail or an smtp server
<Pengwn> can I unison to sync directories then use bzr on top of it ?
<Pengwn> I mean bzr locally on windows and linux boxes?
<Pengwn> sync directories or repos i.e.
<luks_> another option would be "bzr serve" if you can temporarily open a port on one of the machines, and they are accessible from each other
<Pengwn> bzr serve is a python server?
<Pengwn> or c server?
<awilkins> Python
<luks_> almost everything in bzr is python
<Pengwn> is bzr server a push pull thing or I can commit and checkout from it like cvs?
<luks_> both
<Pengwn> cool.
<luks_> but it doesn't handle any authentification
<Pengwn> fine with me.
<Pengwn> atleast plain text passwords?
<awilkins> No
<luks_> nope, nothing
<awilkins> Use bzr+ssh if you want security
<Pengwn> ssh is not for windows :)
<awilkins> There are SSH daemons for Win32 AFAIK
<Pengwn> another big problem otherwise would have stuck to git.
<awilkins> You can certainly use windows as a client to bzr+ssh
<luks_> https://code.launchpad.net/~parker-friikz/bzr-auth/trunk
 * awilkins has done it
<Pengwn> can I limit the clients to bzr serve?
<Pengwn> client connection i.e.?
<Pengwn> say to one.
<Parker-> heh
<Parker-> maybe I should continue with that :P
<luks_> Pengwn: are you planning to use it on a central server?
<luks_> Parker-: you shuold! :)
<luks_> is it usable yet?
<Parker-> mostly yes
<Parker-> :D
<Parker-> but.. it works
<luks_> Pengwn: if it's a central server and it runs any unix based system, you can just use bzr+ssh
<luks_> which works fine on windows as a client
<Parker-> need to leave train.. laters..
<Pengwn> Ok this is the scenario. I work on windows , linux boxes all over the place I want to commit/checkout on any box and before leaving in the evening to save my code/commits on any spare box available at the client side. I work mostly in a vpn so I can connect to any box but don't want to go thru headace setting up ssh/samba what ever crap.
<awilkins> Pengwn: if ssh is installed on your target psuh box, your headache is limited to generating keypair for yourself and adding it to the authorized_keys list in your /home/.ssh folder on the target
<awilkins> And then running pageant / putty on the Win32 bopx
<luks_> or just to use password :)
<awilkins> luks_: Ah, well, I learned to do it before bzr had auth callbacks :-)
<awilkins> It finally pushed me over to using PK auth for everything, none of my boxen support password anymore.
<awilkins> Anyway, yes, Pengwn, you just need plink (from putty suite) to use win32 as an ssh client. Small, no-install executable.
<luks_> actually, you don't
<awilkins> Other client in mind?
<luks_> the bzr installer comes with paramiko installed
<luks_> which provides ssh support without any external dependencies
 * awilkins ... is out of date because of the auth-callbacks thing
<awilkins> I needed something with an ssh-agent
<luks_> paramiko _can_ use putty's ssh agent :)
<Pengwn> awilkins: the headace there is I am working on a windows box all day after ftping my repo now I come to my hotel room connect to slow vpn and save changes to a windows laptop. ftp is again damn slow and remote windows box doesn't have ssh setup.
<awilkins> Have to go catch train back later
<luks_> Pengwn: bzr will download only as much as it needs, which usually isn't that much after one working day
<Pengwn> you mean with bzr serve?
<Pengwn> or bzr-ssh?
<luks_> any transport
<luks_> you would simple replace the 'ftping my repo' step with 'bzr push'
<luks_> and then 'bzr pull' on the laptop
<Pengwn> cool.
<Pengwn> I will try that out then.
<luks_> you can use sftp://, ftp://, bzr+ssh://, bzr://
<Pengwn> thanks luks.
<Pengwn> so bzr is well supported on windows and linux very well?
<Pengwn> I mean my bzr serve should hang I am screwed again.
<luks_> bzr works equally on windows and linux
<luks_> the only things that are different are caused by missing features of either OS
<Pengwn> the best windows scm server is p4s.exe. perforce's. Never hanged on me maybe once.
<Pengwn> basically I have to say how well is python on windows : )
<luks_> but probably the best you can do is to always push the changes to one server and use that server from each machine you are working on
<Pengwn> that's the problem. servers sometimes in different location country and bandwidth sucks.
<LarstiQ> Pengwn: it's not clear to me exactly what problem you are trying to solve.
<Pengwn> admin problems automation problems etc. etc. huge repo like 2GB and need to transfer around on different client places.
<Pengwn> yeah maybe I should stip down the take away the exe/binaries but damn lazy to do that so code and installables all in one repo.:)
<ubotu> New bug: #200599 in bzr "exception error "Connection reset" caused by push" [Undecided,New] https://launchpad.net/bugs/200599
<Bloguero__Connor> what the difference between init and init-repo?
<beuno> Bloguero__Connor, init-repo is a shared repository
<Bloguero__Connor> so, init is only for private?
<beuno> Bloguero__Connor, I wouldn't call it private, it's jsut for one repository
<beuno> the otbher one shares the revisiones
<beuno> so it saves space if you're branching the same repo
<fullermd> Er.  init-repo creates a shared repo; init creates a branch.
<Bloguero__Connor> wich one saves space?
<james_w> and init will create a non-shared repo if you are not in a shared repo when you call it.
<beuno> Bloguero__Connor, it depents on what you're going to do  ;)
<james_w> "bzr help repositories"
<Bloguero__Connor> OK. If someone creates a sharedrepo at http://someplace.com/repoX, and I want to colaborate, should I use "bzr branch http://..."?
<beuno> Bloguero__Connor, share repos are only relevant locally
<Bloguero__Connor> why?
<Odd_Bloke> Bloguero__Connor: A 'shared' repo is only called 'shared' because multiple branches use it to store revisions.
<Odd_Bloke> Those branches share the repository.
<Bloguero__Connor> If I have sftp access to the shared repo, what diff make if it is local or in another machine?
<beuno> Bloguero__Connor, none
<Bloguero__Connor> beuno, you said before that share repos are relevant only locally
<beuno> Bloguero__Connor, right, because they save space when creating new branches in the shared repo
<beuno> they re-use the same common revisions
<beuno> so you don't duplicate them
<beuno> but it makes no difference when branching out externally
<Odd_Bloke> Bloguero__Connor: I think you may be being confused by the use of the word 'repository'.  In bzr, a repository is _only_ a place to store revisions.  Branches are what make sense of these revisions (and are what you can share in the way you seem to mean).
<Bloguero__Connor> so share repo is called shared because it shares files between branches, not because it shares branches between users.
<Odd_Bloke> Bloguero__Connor: Yes. :)
<Pengwn> guys back.
<Pengwn> I did bzr serve --directory=c:\myhome
<Pengwn> how do i access or sync with this from another windows machine?
<beuno> Pengwn, bzr://host/branch
<Pengwn> I am getting errors saying bzr: ERROR: not a branch "C:/myhome/"
<Odd_Bloke> Pengwn: Is C:/myhome/ a branch?
<Pengwn> using bzr pull bzr://141.144.64.18:4155/myhome
<Pengwn> nope directory.
<Odd_Bloke> Pengwn: That'll be your problem then.  You can only pull from branches.
<Pengwn> is branch nick and branch one and the same?
<james_w> Pengwn: no
<Pengwn> ok how to create a branch and serve it?
<Pengwn> there's no default branch?
<james_w> Pengwn: "cd branch; bzr serve"
<james_w> or "bzr serve --directory=c:\location\of\branch"
<luks_> Pengwn: bzr init & bzr add (or be more specific here) & bzr commit
<Pengwn> cd c:\myhome; bzr init ; bzr add; bzr commit ; bzr serve  ??
<Pengwn> then on my other machine bzr pull  bzr://141.144.64.18:4155/myhome  ??
<beuno> Pengwn, that's right, if you just want to have one branch, yes
<luks_> you probably don't want to do add your whole home directory, though
<beuno> luks_, it's a windows home, it's probably empty  :p
<beuno> james_w, does bazaar still use absolute paths with the smart server, or deso it do relative now?
<LarstiQ> beuno: in what sense?
<james_w> beuno: I don't know I'm afraid.
<LarstiQ> if I do bzr serve --directory ~/src/bzr ; then bzr branch bzr://larstiq/bzr.dev works
<beuno> LarstiQ, that's it
<beuno> thanks  :D
<james_w> beuno: how is Prague?
<beuno> james_w, absolutely great. Having a chance to get back some brain-functions working  :p
<james_w> :-)
<beuno> james_w, tomorrow is your last day at previous work?
<dato> james_w: hey, meant to ask the other day: are you coming to debconf?
<james_w> Does anyone know who admins planet.bazaar-vcs.org?
<dato> LarstiQ: same for you
<james_w> beuno: yes it is \o/
<james_w> dato: I wasn't planning on it, but it sounds like there may be a chance that I am now.
<dato> james_w: ok :)
<beuno> james_w, so from when on can I start complaining about Ubuntu doing things wrong to you?
<james_w> beuno: um, you'd be better of complaining to someone else? :)
<Pengwn> oh damn do i have to bzr init on both machines?
<beuno> Pengwn, no, just do branch instead of pull
<beuno> (once, to create the initial branch)
<james_w> dato: I think it would be great if at some point you could send a message to the list outlining the features that made git so compelling for you.
<james_w> dato: I realise you have mentioned a couple already, which is better than most people who just say that there are things without really pointing them out, so thanks for that.
<dato> ok, I could think about them
 * dato takes a note
<james_w> dato: thanks.
<LarstiQ> dato: I had been filling in fields in penta slowly, I need to complete that.
<Pengwn> Wow bzr is cool on windows.
<Pengwn> hope it's equivalently cool on linux :)
<Pengwn> by next best tool :)
<beuno> Pengwn, like everything else, even cooler  :p
<LarstiQ> beuno: now now :P
<Pengwn> but seems I have to go the physical c:\myhome directory and do bzr pull bzr://hostname:4155
 * beuno goes back to his corner and sits back down again
<Pengwn> the bzr://hostname:4155/myhome doesn't work.
<Pengwn> says c/myhome/ is not a branch.
<Odd_Bloke> jam: o/
<LarstiQ> Pengwn: what does `bzr info` say when in c:\\myhome ?
<jam> Odd_Bloke: hi
<Odd_Bloke> jam: Thanks for the reviews earlier. :)
<jam> np, trying to get the merge queue down to something reasonable
<jam> Odd_Bloke: did you have a good train journey back home?
<Odd_Bloke> jam: Yeah, managed to get a seat and everything. :p  How was your flight?
<Pengwn>   branch root: .
<Pengwn> Related branches:
<Pengwn>   parent branch: bzr://141.144.65.18:4155/
<james_w> hi jam.
<jam> The flight was rather uneventful, they managed to arrive 30-min early, but then take >1hr to get my luggage unloaded
<jam> hi james_w
<Odd_Bloke> Perhaps the luggage arrived on time. :p
<jam> Pengwn: and you did "cd c:; bzr serve" first?
<jam> (if you did cd C:\myhome, then the appropriate branch is "bzr branch bzr://hostname/"
<Pengwn> no cd c:\myhome; bzr serve
<jam> Since paths are relative to the cwd
<jam> otherwise it would be branching "c:\myhome\myhome" which obviously doesn't exist
<Pengwn> hey thanks
<Pengwn> bzr://hostname:4155/myhome works
<dato> LarstiQ: ok :)
<Pengwn> after cd c:\ ; bzr serve
<Pengwn> how the hell it bzr know c:\myhome is the bzr root without being in it?
<Odd_Bloke> Pengwn: Because that's where you ran 'bzr serve' from?
<radix> Peng: it maps URLs to file system paths
<radix> erg. pengwn
<Pengwn> ahh got now cd c:\myhome; bzr://hostnaem:4155/ fails :)
<Pengwn> The logic is then If bzr serve find the BZR ROOT client cannot use the path info. If bzr serve doesn't find the BZR ROOT the client has to tell it where to find it. :)
<LarstiQ> Pengwn: bzr serve doesn't care where it is run from, it will take an incoming request and then look in $serveroot + $relpath
<LarstiQ> Pengwn: so yes
<poolie> hello jam
<LarstiQ> Pengwn: you could also (on a unix system) do `bzr serve --directory=/` and that way expose your entire filesystem, but you probably don't want that
<jam> hi poolie
<jam> How was your travel back?
<Pengwn> LarstiQ: what is the $serverroot on windows it just says .
<poolie> not too bad
<poolie> you?
<beuno> Pengwn, wherever you specified bzr serve to run from
<LarstiQ> Pengwn: it is either the directory you run bzr serve from, or what you specified with --directory
<Pengwn> I gues it cannot transalte c: and d: etc then ?
<LarstiQ> Pengwn: so 'cd c:/myhome/; bzr serve', $serverroot would be 'c:/myhome'.
<LarstiQ> Pengwn: what do you mean?
<beuno> Pengwn, you might be able to use shortcuts to link to d:, but windows is a bit uncertain for me
<beuno> LarstiQ, I think he means server contents from c:/foo and d:/bar
<LarstiQ> beuno: hmm
<beuno> you know, there is no / in win
<mneptok> beuno: there is if your machine meets the Windows Vista Ultimate POSIX Professional Edition minimum hardware specs.
<beuno> mneptok, you mean kubuntu with the vista skin?   :p
<davi> welcome to emacs
<Pengwn> once the bzr serve finds the BZR root it always give $server + $relpath ans not a branch.
<Pengwn> it recongnizer "c:/myhome" and not "c:\myhome"
<Pengwn> so once it finds the root and  i say bzr pull bzr://hostname:4155/proj1 it doesn't find it.
<Pengwn> i have to cd c:\myhome\proj1 and then do bzr pull bzr://hostname:4155
<LarstiQ> Pengwn: this sounds wrong
<LarstiQ> Pengwn: you have a bzr server running from c:/myhome, right?
<Pengwn> windows is always wrong for me :)
<Pengwn> yep.
<LarstiQ> Pengwn: could you then try mkdir c:\temp; cd c:\temp; bzr branch bzr://hostname/proj1
<Pengwn> bzr serve --directory="c:/myhome"
<Pengwn> I am in C:
<LarstiQ> Pengwn: could you try my way first? I'd like to rule out funky window pathnames first
<Pengwn> C:\myhome>bzr pull bzr://141.144.65.18:4155/proj1/
<Pengwn> bzr: ERROR: Not a branch: "bzr://141.144.65.18:4155/proj1/".
<mtaylor> statik: ping
<LarstiQ> Pengwn: that's not really what I asked you :P
 * LarstiQ is tempted to boot into windows and check
<Pengwn> I just have to be out of the location where there is no .bzr directory and then the bzr://hostname:4155/path works.
<Pengwn> some how my PWD is overiding the branch infomartion to the bzr serve.
<Pengwn> ok got to go  now.
<AfC> You shouldn't have to specify the port number
<jam> poolie: overall uneventful, which is how I prefer travelling :)
<poolie> hello afc
<AfC> Good evening Martin
<mneptok> hey poolie
<james_w> poolie: hi. How are you?
<james_w> poolie: who is it that admins the bzr planet?
<poolie> good, thankyou
<poolie> though in an unusual personal timezone
<poolie> canonical IS
<poolie> I can pass on requests or comments
<james_w> poolie: I thought it was a little early for you.
<james_w> I would like to be added if you approve, does that need to go through them?
<poolie> that's probably easiest if you don't find them here
<poolie> lamont (in us/mountain time) can do it for example
<poolie> can you pm me the urls
<poolie> or mail
<jelmer> abentley: ping
 * lamont notes that #canonical-sysadmins is where one can generally expect to find zero or more awake sysadmins
<lamont> (this server)
<abentley> jelmer: pong
<jelmer> abentley: Do you know how to get kid to not insert a HTML header above pages?
 * jelmer has a bundlebuggy patch which adds rss feeds and this is the last bit he can't get to work
<poolie> lamont, james_w: sent
<abentley> The header will be coming from your master template.
<james_w> poolie: thanks.
<jelmer> abentley: I mean the <!DOCTYPE > line on top, which is inserted even while it is not there in my kid template
<abentley> jelmer:  one sec
<mwhudson> did i show this screenie off in here yet? http://people.ubuntu.com/~mwh/hacked_up_changelog_view_3.png
<poolie> mwhudson: released yet? :)
<mwhudson> poolie: well, i released 1.2 and 1.2.1 yes
<mwhudson> poolie: that changelog view is not even committed to a branch though i think, it's a total hack
<poolie> oh, interesting
<abentley> jelmer: expose it like this: "@expose(template='livelistings.templates.atom_events', format='xml', content_type='application/xml')"
<LarstiQ> mwhudson: fair enough :)
<jelmer> abentley: Thanks!
<poolie> mwhudson: i don't think you need different font sizes btw
<abentley> The content_type would probably be different.
<poolie> they're already distinguished by placement and weight
<jelmer> abentley: yep, application/rss+xml probably
<jelmer> it works \o/
<mwhudson_> grr
<mwhudson> did i miss anything?
<fullermd> Thunder.  Lightning.  Dancing girls.  3 pirouetting elephants.
<mwhudson> cool
<mwhudson> i guess i should set up a proxy one of these days
<Prodoc> anyone available to make a small change to the bazaar user-guide so I don't have to get the source first and create a patch and stuff?
<LarstiQ> Prodoc: sure
<LarstiQ> with sufficient detailed suggestions I can actually do that :)
<Prodoc> LarstiQ: the following sentence in http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#id41 doesn't really flow: 'On the other hand, Mary might want to merge into her branch the work Bill has done in his.'. The following makes more sense imho: 'On the other hand, Mary might want to merge the work Bill has done in his branch into her branch.'
<LarstiQ> hmm
<Prodoc> nitpicky I know ;-)
<Prodoc> I had to read it over 3x
<LarstiQ> I actually prefer the first sentence.
<LarstiQ> but I'm not a native speaker, and I know my mind sometimes works rather strangely
<Prodoc> or leave out 'in his branch' in the suggested sentence
<jelmer> http://bundlebuggy.vernstok.nl/bzr-gtk/rss?selected=pending&unreviewed=n
<Prodoc> that would make: 'On the other hand, Mary might want to merge the work Bill has done into her branch.', a lot clearer imo
<abentley> jelmer: Cool.
<abentley> jelmer: But I won't be able to put it on the main BB instance, because that query is really hard on the DB.
<jelmer> abentley: it should be the same query as for the index page
<abentley> jelmer: Yes.  The index page is really hard on the DB.
<jelmer> ouch :-(
<abentley> Yeah.
<abentley> Mainly because that box is underpowered, I think.
<abentley> It runs at a decent speed on my 3-year-old laptop.
<abentley> The first entry produces a parse error for me: XML Parsing Error: not well-formed
<abentley> Location: file:///
<abentley> Line Number 60, Column 7:
<LarstiQ> what box is it running on?
<abentley> It runs on aaronbentley.com, which is a virtual machine hosted by unixshell
<jam> abentley: I believe poolie discussed getting it hosted by Canonical servers, has anything come of that?
<jam> I know one concern is just getting enough admin resources for a Canonical machine
<jam> They like to lock the machines down pretty tight
<abentley> jam: more recently, we've been talking about using a different host.
<abentley> poolie was just talking to me about it.
<mtaylor> hey guys
<mtaylor> in a post-push hook
<mtaylor> is there any way to get ahold of the revnos that the revisions will be in the remote tree?
<poolie> jam, i think it's just you and me to talk today, as spiv is in canada and igc is on leave
<LarstiQ> is Rob doing ok?
<poolie> in what way?
<poolie> he seemed ok yesterday
<LarstiQ> poolie: he wasn't too well the last days I saw him
<poolie> oh right
<poolie> i think he was mostly over it by the time we left
<poolie> though i am feeling a bit sick myself today
<LarstiQ> poolie: ai, beterschap
<lifeless> moin
<james_w> hi lifeless.
<james_w> are you feeling better now?
<lifeless> comes and goes a bit
<Stavros> hello
<lifeless> may head up to doctor later today and get a considered opinion
<lifeless> hi Stavros
<Stavros> i would like to create a setup where the live server automatically updates its working tree with any revision tagged "release", is this possible?
<lifeless> yes; it will need a cronscript at this point, or a client side hook
<Stavros> aha, well, since it has to pull from another repo, i'm thinking cronscript
<Stavros> but how can i read the tag?
<james_w> Stavros: does "bzr tags" help?
<Stavros> not really, i need to do it programmatically
<Stavros> i'd probably need a cronjob to pull at regular intervals and a hook to update the tree on release/restart apache?
<jam> Stavros: are you doing it in shell, or in python?
<jam> Stavros:  because you could just do "bzr pull -r tag:release" from shell
<jam> From python it would be more:
<Stavros> jam: probably in python, because i need tags preserved (i'm not entirely sure how tags work), so the tags would be something like "Release 1.2.2"
<jam> tag_revision = branch.tags.lookup_tag('release')
<jam> Ah, you want Release XXX not just "Release"
<Stavros> yes, something like that
<Stavros> it's the same thing in python, that's why i didn't mention it
<jam> So in that case, you could do:
<jam> b = bzrlib.branch.Branch.open('remote_location')
<Stavros> actually i should read up on bzr scripting because i have no idea how to do this
<jam> tags = b.tags.get_tag_dict()
<jam> for name in tags:
<jam>   if name.lower().startswith('release'):
<jam> ..
<jam> it sort of depends how you want to decide to use 1.2.2 over 1.2.1
<jam> etc
<Stavros> i shouldn't have any problems with the actual script, i just want to know where to put it/how you go about writing hooks/etc
<Stavros> is there a webpage that explains that stuff?
<Stavros> is it this? http://bazaar-vcs.org/WritingPlugins
<james_w> Stavros: that has some of it. I don't know if it will have all that you need though. Feel free to ask questions in here if not.
<Stavros> will do, thanks
<frsk> 7w 21
<frsk> Gah.
<Stavros> wow, you can version your bzr plugins with bzr
<Stavros> i think my head just exploded
<Stavros> are bzr tags just text that is associated with a release number?
<jam> Stavros: tags are just a name associated with a revision_id
<Stavros> err yes, why do i keep calling revisions releases, i'll never know
<Stavros> that is quite elegant
<jam> And yes, all of my tags are bzr branches in ~/.bazaar/plugins
<Stavros> and tags are unique?
<Stavros> jam: what was that?
<jam> tags are not universally unique
<Stavros> hmm
<jam> sorry, all of my plugins are branches ....
<jam> not tags :)
<Stavros> ah
<Stavros> tags aren't unique? how does that work then?
<james_w> they are unique to a branch, and a merge may cause a tag conflict that you have to resolve.
<Stavros> oh
<Stavros> well, a branch is as universal as it gets, isn't it
<james_w> so if I tag one revision as "release 1.1" and you tag a different one as "release 1.1" then there needs to be intervention when we merge to say who was right.
<Stavros> true
<huslu> can someone kindly tell me what's the difference between --no-trees and the default in init-repo command? won't they both start out with emptry directory?
<LarstiQ> huslu: they will. The difference is what happens when you bzr init/branch branches into it
<huslu> LarstiQ: thanks but what is the difference when you branch (or push?) into it (with when init-repo was started with --no-trees)
<LarstiQ> huslu: with --no-trees you'll just get a branch but no working tree. Ie, branchname/.bzr/ but no other files under branchname/
<LarstiQ> huslu: which goes nicely with having a lightweight checkout of that branch somewhere else on your filesystem where you do actual development
<huslu> LarstiQ: k, so if i understand correctly, all the --no-trees does is, keeps the revision history in a different place?
<poolie> lifeless: can i call?
<LarstiQ> huslu: no, the revision history is kept in the same place. The only difference is to wether create a working tree at the same place as the branch or not.
<LarstiQ> huslu: but you can see for yourself, bzr init-repo repo; bzr branch lp:bzr-gtk repo/gtk; bzr init-repo --no-trees repo-no-trees; bzr branch repo/gtk repo-no-trees/gtk
<LarstiQ> huslu: and then ls repo/gtk repo-no-trees/gtk
<Stavros> wait, to create a hook all i need to do is write a function and register it?
<huslu> LarstiQ: right, so the difference is that the files are not in the repo-no-trees directory?
<LarstiQ> huslu: that sentence is a bit amibguous. All the files needed to reconstruct a working tree are in both repositories
<LarstiQ> huslu: you can get the same effect on repo-no-trees by doing: cd repo-no-trees/gtk; bzr checkout .
<LarstiQ> huslu: but the default will still be to create tree-less branches then
<LarstiQ> huslu: the other way around, cd repo/gtk; bzr remove-tree
<Stavros> does a "pull" update the working tree if it had no local changes?
<LarstiQ> Stavros: yes, also if it did.
<LarstiQ> Stavros: that is, non-committed local changes
<Stavros> LarstiQ: it just overwrites the changes?
<Stavros> that can't be right
<LarstiQ> Stavros: if you have diverging commits, it will tell you it has diverged
<Stavros> ah
<LarstiQ> Stavros: no, it merges the content
<huslu> LarstiQ: ok, that helps, now, can you help me to see the light when or why is it beneficial to not to store the working tree there?
<Stavros> how do i make it so it doesn't update the wc?
<LarstiQ> huslu: each working tree consumes diskspace, you don't always need them
<LarstiQ> Stavros: I'd have to check to be sure, but I'd think invoking the method on Branch instead of WorkingTree
<LarstiQ> huslu: or for example if you use a workflow where you `bzr switch` between branches but have only 1 working tree
<Stavros> hmm
<huslu> LarstiQ: ok, i haven't gotten around to that part yet. but your explanation made things more clear, i'll keep learning.
<Stavros> hmm, well, this doesn't help my plan for the self-updating servers...
<LarstiQ> Stavros: alternatively, you could decouple the branch and the checkout, update the branch, and then update the working tree to the latest release tag
<LarstiQ> huslu: np
<Stavros> LarstiQ: you mean push to the branch>
<Stavros> ?
<LarstiQ> Stavros: no, pull
<Stavros> how would i do it so the wc wasn't updated, though?
<LarstiQ> Stavros: I'd go with a branch without wc, and the wc in a different location
<Stavros> ah
<Stavros> not very elegant, though
<LarstiQ> or more elegant, depending on how you look at it :)
<Stavros> well, the more elegant solution would be one that didn't require me to keep the repo and the files in separate locations and copy between them :p
<LarstiQ> Stavros: or if you could go without local changes, pull, and then revert to the latest release tag
<LarstiQ> Stavros: copy? Eh, no
<LarstiQ> Stavros: branch in one location, lightweight checkout in another
<Stavros> oh
<poolie> does anyone know if python-glade2 2.8.6 will be enough for bzr-gtk
<Stavros> hmm, what was that other solution? pull and revert?
<poolie> re bug 200366
<Stavros> actually that should work
<fullermd> Urg.  Not very well.
<LarstiQ> Stavros: the drawback of that is that is going to do more writes to disk than needed
<LarstiQ> fullermd: to poolie's question or Stavros comment?
<fullermd> The latter.
<Stavros> LarstiQ: it doesn't matter much, it's not that many files
<Stavros> fullermd: what would you recommend?
<mamato> hmm, any way to use bzr (for commits, reverts, etc) while using 'bzr gdiff'?
<Stavros> mamato: does it lock?
<fullermd> I haven't been much paying attention.  But you'll work yourself into an unpleasant corner using rever tlike that.
<mamato> yep! not sure why...
<Stavros> fullermd: the server doesn't have any local changes, and this is the best solution so far...
<Stavros> the absolute best would be if there was a "bzr pull --no-update" option
<Stavros> so it didn't update the working copy
<LarstiQ> fullermd: the use case is only updating the working tree to revisions tagged with a release
<Stavros> and then i manually reverted to the latest revision whenever i wanted
<fullermd> How do you define a 'release'?
<mamato> Stavros: it's not like gdiff allows you to do much :S
<LarstiQ> Stavros: well, in my mind that is exactly served by having branch and tree not co-located
<Stavros> LarstiQ: hmm, i should read up on a lightweight checkout
<Stavros> fullermd: a release is the well-tested code
<Stavros> that should run on production
<Stavros> all other commits should run on dev
<fullermd> I know, but what in bzr terms makes the release?  A sliding tag?  Somebody updating a revno in a control file?
<Stavros> fullermd: oh, a tag
<Stavros> not sliding, just tag "release x.x.x"
<Stavros> or even sliding, same thing
<fullermd> The problem is that `revert -r` is not `update -r`; you'll wind up in Conflict City every time you pull.
<Stavros> oh
<Stavros> that won't do, then
<fullermd> I'd just make a sliding LATEST_RELEASE tag, and pull -rtag:LATEST_RELEASE.
<Stavros> why would it conflict, though? there are no local changes
<fullermd> There are, though.  revert makes local changes.
<Stavros> ah
<fullermd> (you may need pull --overwrite because of the rough corners of tags)
<LarstiQ> fullermd: something I wanted to ask early, does it do the lookup of tag:LATEST_RELEASE in the parent branch?
<Stavros> i would like to be able to track releases, so i'm not very partial to the sliding tag idea
<fullermd> LarstiQ: Yah.  pull -rwhatever refers to revs in the branch pulled from.
<fullermd> Well, the idea is that you update the sliding tag to point at a release when you make it and are sure it's ready; that way it all Just Happens.
<LarstiQ> fullermd: oh, doh
<fullermd> If you don't slide a tag, you have to go update the tag in the pull'ing script every release, since it needs to go somewhere different.
<Stavros> yes, but i've had times when i needed to revert to the previous release
<Stavros> fullermd: i was thinking of a plugin that parsed it and selected the latest revision tagged with "release"
<dato> fullermd: `bzr tags --sort=time | tail -1 ` ;)
<ubotu> Launchpad bug 200366 in bzr "Ubuntu package bzr-gtk for Dapper depends on package not available for Dapper." [Medium,Confirmed] https://launchpad.net/bugs/200366
<Stavros> something like dato's
<fullermd> Then you'd just slide the tag back, and the pull'ing copy will follow next time it runs (with --overwrite in that case, definitely)
<Stavros> fullermd: yes, but the problem is remembering where the tag was
<fullermd> Who needs to remember?  It was the same as rel_3_4, then rel_3_5, then rel_3_6, then OOPS 3.6 was horked up, move it back to rel_3_5
<Stavros> fullermd: that's not sliding, though
<Stavros> or can you have multiple tags per release?
<fullermd> Sure it is.  You have defined tags for each release, *AND* a DEPLY_THIS_CODE tag pointing at whatever you want the server running at the moment.
<Stavros> err, revision
<Stavros> ah, THAT i like
<fullermd> Sure.  You could have a thousand tags pointing at one rev.
<Stavros> great gret
<fullermd> And you should, actually.  I don't think anybody's done it, so we need a guinea pig   ;>
<Stavros> so i tag a rev in my local repo and push it to the main one
<Stavros> haha, damn you
<Stavros> then i do bzr pull -rtag:PRODUCTION ?
 * fullermd nods.
<Stavros> aha, let me try that
<fullermd> Probably need pull --overwrite; otherwise it won't step backward if you have to move the tag back.
<Stavros> aha, okay
<fullermd> (and it may not pull the tag quite right either, due to above)
<Stavros> does "bzr tag tag1 tag2" tag with two tags, or tag with one tag with a space in it?
<fullermd> I think it may give an error...
<Stavros> aha
<Stavros> also, are tags fully reversible? i can delete them without any trace, no?
<fullermd> I'd do something like `bzr tag -r-1 RELEASE_3_5 ; bzr tag -rtag:RELEASE_3_5 PRODUCTION`
<Stavros> why -r-1?
<Stavros> oh
<Stavros> i see, yes
<fullermd> Well, or -rwhatever; find the rev to tag the release, then use the release tag to set the PRODUCTION tag.
<Stavros> yes
<fullermd> I _think_ pull --overwrite doesn't delete tags gone upstream.  It should move moved ones, though.
<mamato> is it possible to have bzr commit display the diffs in the bottom part of the file it has you edit for comment, where the list of files is?
<fullermd> Tags got to that awkward state where they're plenty good enough for 90% of uses, and the other 10% isn't near the top of anybody's priority list   :|
<james_w> mamato: bzr commit --show-diff
<mamato> hehe, nice!
<Stavros> offtopic, does anyone use fish?
<mamato> james_w argh... not available... i guess my bzr is too old :(
<fullermd> Mmm...   NEWS says it was in 0.91.  That's a fair couple steps back now...
<mamato> i use what ubuntu gave me (and it's up to date)... it's 0.90.0 :(
<Stavros> it seems to be working
<Stavros> mamato: yeah, ubuntu is a bit bacjk
<Stavros> use the repository on the site
<Stavros> fullermd: is there any way i could push to that server and have it detect if the PRODUCTION tag changed revisions and restart servers/etc?
<Stavros> i mean, do all that on push instead of pull
<fullermd> With push?  I dunno...   I s'pose you could parse the output at least, looking for an 'update' (or whatever it says) keyword.  Not sure if the exit code says anything.
<james_w> Stavros: the normal way to do this would be using branches I think. However that may not help you.
<Stavros> hmm
<Stavros> so the easiest way would be to write a crontab to pull every x minutes?
<fullermd> Yeah, that's how I'd do it.
<fullermd> (well, it's not of course, but it's how I'd do it given you general setup  ;)
<Stavros> how would you do it?
<Stavros> with another setup?
<fullermd> Well, I do all my deployals via install(1)   :p
<Stavros> pff :p
<mamato> rrrrrhhh... newer bzr requires newer libc and python-central...
<mamato> oops... nevermind
<mamato> any way to have --show-diff be the default?
<mamato> aliases won't even work transparently since option has to come after command :(
<Peng> defaults?
<Peng> Err, I dunno. That's an hg thing. :P
<Stavros> heathen!
<mamato> hmm... should have looked more carefully at hg before choosing bzr i guess ;)
<Stavros> sacrilege
<Stavros> actually i think they're more or less the same
<Stavros> bzr has better merging
<LarstiQ> Peng: what is a hg thing?
<fullermd> Huh?  Why don't aliases work?
<mamato> well you cant alias it as 'bzr commit'
<Peng> I'm pretty sure you can.
<fullermd> Sure you can.
<fullermd> Wait.  bzr aliases, not shell aliases.
<james_w> mamato: are you referring to shell aliases? did you realise that bzr itself supports aliases?
<mamato> was talking about shell aliases
<james_w> mamato: http://bazaar-vcs.org/CommandAliases
<Peng> Oh.
<Peng> Bazaar aliases can do this fine. I just tested it.
<james_w> yeah, I have that alias set up.
<mamato> nice! so bzr does allow default options!
<james_w> And it automatically supports inverse options, so that you don't have to worry about doing unalias to get around any issues.
<james_w> for instance if you alias "commit = commit --strict" this won't let you commit with unknown files in your working tree. However if you want to do it once for some reason you can run "bzr commit --no-strict" which expands to "bzr commit --strict --no-strict" and the latter takes precedence.
<mamato> while i'm at it, is it possible to add colors or bolds to diff? (w/o launching gtk)
<Odd_Bloke> mamato: The 'cdiff' command in bzrtools adds colour.
<mamato> thx!
<mamato> just in case, you got a trick to colorize the --show-diff of commit in vim too?!
<james_w> mamato: a vim plugin to do that may be quite straightforward, but I haven't heard of one yet.
<mamato> hehe oki
<jelmer> I think I saw one being posted on Google code
<jelmer> a generic one for vcs'es
<mamato> one last thing then... a replacement for less which would work with colorized output?
<james_w> jelmer: vcscommand?
<jelmer> james_w: yeah, probably
<jelmer> somebody posted a patch that added bzr support for it
<james_w> jelmer: yeah, I think that provides :vcs commit or similar, but it may have what mamato wants.
<jelmer> yeah, it allows you to run vimdiff between the base of the working tree and the working tree
<Stavros> is there a switch to commit the wc just like it is, even if it's a few revisions back or whatever?
<james_w> mamato: bzr cdiff | less -R do what you want?
<mamato> hÃ©hÃ©, found my 'less -R' for now
<mamato> yep, thx!
#bzr 2008-03-11
<Verterok> moin
<Odd_Bloke> Verterok: o/
<Verterok> Odd_Bloke: hey, my ssh connection works again :-)
<Odd_Bloke> :)
<ubotu> New bug: #200816 in bzr-loom "combine-thread sounds like it merges, but it doesn't" [Undecided,New] https://launchpad.net/bugs/200816
<ubotu> New bug: #200819 in bzr-loom "combine-thread silently drops unmerged changes" [Undecided,New] https://launchpad.net/bugs/200819
<Odd_Bloke> jelmer: http://bundlebuggy.vernstok.nl/bzr-gtk//request/%3C1200860579.32181.3.camel@dasch.egmont-kol.dk%3E is giving me a 500 error, traceback at http://paste.pocoo.org/show/32888/
 * mwhudson points people with brain cells to spare at his mailing list post
<huslu> the help says that with push target branch will not have its working tree populated, but when i do push all the files get there. what does it mean?
<bob2> push only updates working copies on the local machine (i.e. file:/// urls)
<huslu> ok push does not actually 'push' the files. do i have to use checkout?
<bob2> it pushes the branch
<bob2> does the thing you're pushing /to/ have a checkout already?  if so, "bzr up" (or ssh remotehost 'cd /remotepath ; bzr up' or whatever)
<Peng> (If you really want to update the working copy when pushing, and have a good reason for it, and are using sftp or ssh, get the push-and-update plugin.)
<huslu> no, i am pushing to a place that was empty
<bob2> "bzr up" should get the files then (and'll need to be run after every push or you need the plugin Peng mentioned).
<huslu> unfortunately i am confused about these commands, and i have read manuals and online help.
<bob2> which part's got you?
<huslu> right now pulling, pushing, updating. they all sound similar and not exactly sure what they are now meant to do.
<bob2> ah, ok
<huslu> push only seems to copy over the .bzr dir
<Peng> Exactly.
<bob2> pull and push work on the branch level - they pull/push changes at the internal bzr data level
<Peng> (Of course, pull also runs update afterwards, making things more confusing.)
<bob2> "update" updates a working copy, incorporating any changes that have been stored by bzr, but haven't been applied to the workign copy files yet
<bob2> it does the same as "svn up" would
<huslu> i haven't used svn, so update always makes sure local working tree is up to date with where ever it came from?
<bob2> right
<bob2> though the local working tree might have local uncommited changes
<huslu> so apart from the plugins, is there a way to get the files over to remote side with one local command?
<bob2> no, that's the point of the plugin - it is transport dependent
<bob2> er, "being able to do update is transport dependent"
<doko> any reason that we still have the 1.2 release candidate in hardy?
<awilkins> doko: Don't think it matters, AFAIK, RC was identical to release
<awilkins> Dead in here, innit. THey're all knackered after the Sprint in London
<Peng> There was one change in 1.2: "Fix failing test in Launchpad plugin."
<ubotu> New bug: #200927 in bzr-svn "crash when generating file id map" [Undecided,New] https://launchpad.net/bugs/200927
<Stavros> hello
<Stavros> is bzr faster than svn?
<jam> Stavros: it sort of depends on what you are doing. For many things bzr can work purely locally, making it a lot faster
<jam> If you are using a checkout in bzr, and are on a local lan, and committing changes to a 500MB file, I think svn is faster
<Stavros> jam: it seems that for all operations bzr is much faster (svn takes about ten seconds to even begin committing/whatever), but i don't know if it depends on wc siz
<Stavros> size
<jam> And you don't have the option to pull history locally for svn
<jam> So "initial checkout" can be misleading
<Stavros> oh yeah, local diffs are great
<Stavros> well, it's worth a slow initial checkout for fast diffs
<jam> So yeah, not having to connect to a remote server can give bzr a big speed advantage
<Stavros> is there a good bzr gui, by the way?
<jam> bzr-gtk is the standard one, which is evolving a tortoisebzr/nautilusbzr and Olive
<Stavros> aha
<jam> There is also qbzr, which I haven't used
<Stavros> yes, i tried qbzr, it was nice
<Stavros> its diffing was better than bzr-gtk
<jam> http://bazaar-vcs.org/QBzr
<jam> Because it did side-by-side diffs?
<Stavros> yes
<jam> bzr-gtk could probably grab "meld" to do that
<Stavros> rather pretty, too
<jam> but sure
<AfC> Is it true that initial checkout of a bzr branch is slower than initial checkout of a Subversion one? I'm sure there are times, where that's true, but in general, bzr is getting faster and faster each release. Subversion has always been pokey.
<jam> AfC: well, if you have a project with 3GB of history, downloading that is a bit slow
<Stavros> AfC: well, it has to transfer everything...
<jam> I would imagine with shallow branches it gets better
<jam> We could also do a lightweight checkout, but I don't think we've done a lot of work optimizing that path over the network
<AfC> jam: yeah
<AfC> So I've got bzr-svn pulling a (large) Subversion repo for the first time. Hooray and all that. Now, obviously I can branch from this locally, work on my branches, push/merge back, etc.
<AfC> But what about collaboration? Going through the n-hours it'll take to pull this thing down,
<AfC> is not an experience I'd like to force on the (mostly Git) users around here. Can I just hand them the bzr branch
<AfC> or, do I like cp -a / scp -pr the "repo" containing what bzr-svn pulled down, ...?
<AfC> (around here == a hackfest on that project)
<AfC> (so if I can use an ethernet cable and two seconds of pushing to move the revisions to a compatriot that would be good, I expect)
<LarstiQ> AfC: you could bzr serve it up I guess, or ship them the repository + branch
<AfC> LarstiQ: Thanks. The variation here is that they all too have read/write access to the upstream Subversion repository, so ideally they could likewise use the trunk branch. Not sure if that's the sort of use case that people had in mind
<AfC> LarstiQ: but you think handing them a tarball of the fetched and init'ed and champagned repo would work?
<LarstiQ> AfC: I'm not entirely clear on what they need to do with it and such. But with the repo and branch they should have all revisions used and a branch handle to it.
<LarstiQ> AfC: if they need to communicate with svn again, they need bzr-svn as well and it might do caching of svn data again
<AfC> Oh, I just thought of one thing that could be a problem: the URL I checked out has my username in it (as it is svn+ssh). That's not going to be very sharable
 * LarstiQ has never tried shipping the result
<AfC> LarstiQ: I'm just trying to avoid them having to do the initial bzr-svn pull. Which is ... lengthy
<LarstiQ> right
<LarstiQ> AfC: I suggest testing under a different user if it will need to do the bzr-svn caching again
<AfC> and makes Bazaar look really bad, unfortunately. And as there is increasing momentum towards Git around here I want to try and compete with that before it is too late
 * LarstiQ nods
<AfC> LarstiQ: good idea
<AfC> LarstiQ: (I rather suspect it might; that part only took a minute, so that's not so bad)
<LarstiQ> AfC: if it were plain bzr, bzr pull --remember url-without-username will then prompt them for their username later on. Not sure how bzr-svn deals with auth
<AfC> Interesting
<LarstiQ> those are the only things I can think of right now
 * LarstiQ does a small test
 * AfC supposes he should have used something smaller than GTK+ as his first use of bzr-svn :)
<LarstiQ> maybe :)
<AfC> The trick that someone suggested of doing init && pull rather than branch
<AfC> to provide resumability seems a good idea
<LarstiQ> AfC: yes, although qua data it should already be resumable if you use a shared repository, the actual revision objects get shoved into that
<AfC> Mmm
<AfC> LarstiQ: Yes, of course
<LarstiQ> AfC: then the branch is only a pointer to the last revision, remaining problems are that the branch isn't initialised as being one, so you need to remove the directory and branch again
<LarstiQ> so yeah, init and pull is a nicer ui
<LarstiQ> unfortunately
 * LarstiQ got his svn branch, procedes to test with a different user
<AfC> I'm only using whatever the current release is (0.4.7?) so I'm not sure if this has been addressed, but it sure is a bit lean on progress reporting.
<LarstiQ> AfC: ok, I copied over a repo plus branch, the other user can log/st/diff/ci without having bzr-svn
<LarstiQ> now to test if they can push up to svn
<AfC> Yup
 * AfC is only seeing about 3 revisions per second coming in. This is clearly going to take a while.
<LarstiQ> AfC: my suspicion was right, the second user after installing bzr-svn and running bzr push http://svn... gets to also cache the svn information. Which is rather quick I'm happy to say.
<Af1> yeah
<LarstiQ> committing fails because of auth, let me check that
<Af1> did the fact that the thing that was copied had a different URL as its origin cause a problem? Doesn't sound like it
<Af1> Ah, ok
<jemarch> hello
<LarstiQ> AfC: I was using anonymous http at first
<LarstiQ> there is no svn+ssh running there
<AfC> np
<AfC> Now that I think about it: in bzr context it shouldn't matter at all. You just push to the URL you're pushing to. It just remains to be seen whether the guts of bzr-svn are unable to cope with that usecase
<LarstiQ> ok, I'm think I'm shafted on that front
<LarstiQ> svn python bindings prior to 1.5 don't allow you to do anything with authentication
<LarstiQ> you can work around it by forcing svn to cache credentials
<LarstiQ> AfC: if you don't require people to push to svn, everything should work nicely
<AfC> Well, I'll see if I can find a) a small project at that host + b) someone sympathetic to test with
<LarstiQ> if not, there is the bit of authentication I can't test for you atm
<LarstiQ> AfC: cool
 * LarstiQ heads of to his appointment
<AfC> LarstiQ: {shrug} the project is in Subversion. Nothing I can do about that at the moment. And given that some people are using svn, others git-svn, and (I hope more than 0) bzr-svn to get to it, I expect it will remain the common point for some time to come, unfortuantely.
<AfC> LarstiQ: see ya. Thanks for checking things
<jam> AfC: I believe there is a bzr-svn cache that you will also need to give the other users
<jam> with that and the bzr branch
<jam> they shouldn't have to do the 'mega-pull'
<AfC> jam: based on LarstiQ's experiments just now, not passing the bzr-svn cache across wasn't a show stopper - it just went and "re" did it. The cost of that was about a minute, so no biggie.
<jam> ah, ok
<jam> I thought that was one of the bigger expenses, but I guess not
<AfC> (bit harder to tuck into a tarball or whatever, so that worked out well)
<AfC> jam: I would have thought so too
<AfC> but hey
<jam> AfC: is that for the large project? or a small one
<AfC> GTK+
<jam> that sounds pretty big :)
<AfC> The launchpad import was 15256 revisions and 197929 KB as reported by bzr info -v.
<AfC> But I don't want to use that.
<jam> sure, bzr-svn can be used to collaborate between the two
<AfC> I (and everyone else here) has write permissions on the upstream project. So it's not a case of export and abandon, it's "want to use bzr to show it off, but unfortunately against a Subversion project"
<AfC> and so the launchpad import is kinda useless.
<awilkins> If you can get bzr-svn absolutlely ironclad, it's the major reason to use BZR
<awilkins> Well, A major reason
<awilkins> Justifying things to risk-averse managers is a major decider of project adoptance in the real world
<awilkins> Oh, can anyone give me feedback about using bzr with WebDAV? Do you just install a standard WebDAV plugin on your Apache instance?
<AfC> jam: any sense if it is indeed best practise to frequently restart bzr-svn when doing its "mega-pull"?
<awilkins> AfC: I wrote a script to do it a few hundred revisions at a time
<awilkins> AfC: Otherwise it would just fill all available memory and crap out
<awilkins> I define best practice in this case as "it works, so go with it"
<ubotu> New bug: #200993 in bzr "AssertionError on revert" [Undecided,New] https://launchpad.net/bugs/200993
<jam> AfC: when the svn binding leak, it is definitely recommended to loop over "bzr pull -r XXX" by like 100 or 1000 at a time
<jam> Since we also have the possibility of getting disconnected, etc, I would also recommend it.
<jam> I don't know the internals of svn => pack pulling, if it commits anything while it is running or not
<jam> I can check real quick
<jam> AfC: it seems that bzr-svn is opening and closing a "write group" for every revision
<jam> which might be part of the performance issue
<jam> but it does mean that after any pull the data will be in the target
<jam> even if stopped halfway
<awilkins> jam: Yes, it repacks after each revision
<LarstiQ> sounds rather like something spiv and jelmer looked at at the sprint
 * awilkins cheers
<jam> I certainly would recommend doing it every 100 or so
<jam> That's what I do in cvsps and some other converters
<jam> I think Ian has fast-import hooked up to do it every 10000
<awilkins> As far as I can tell, the hardlink support is the only API break that effects bzr-svn, so you can just add a None parameter to the API and run on
<awilkins> Would this "not packing every revision" thing be present in a more recent revision?
<jam> awilkins: well, I have tip, and it seems to be there
<jam> sorry, it still packs every revision
<jam> I was unclear
<awilkins> jam: tip of 0.4?
<awilkins> or trunk?
<jam> 0.5.0.exp.0
<AfC> Oh, nice. I left bzr-svn running for the last hour, and it grew to 1.7 GB
<jam> trunk, I believe
<awilkins> Yeah, it does that
<AfC> of RAM in use.
<jam> http://bazaar.launchpad.net/~jelmer/bzr-svn/trunk/
<awilkins> the RAM use gets bigger than the source repository is :-P
 * awilkins waits for his MKS resync to finish
<awilkins> Ancient VCS programs and hokey operating systems ain't no match for a good blaster at your side....
 * awilkins is still waiting for MKS
 * awilkins is still waiting for MKS
<AfC> Is bzr-svn trunk safe to use? (ie, is it recommended, more performant, etc? Or is that branch considered unstable except at releases [I don't know jelmer's release practises])
<awilkins> "bleeding edge, may break existing imports every now and then"
<LarstiQ> AfC: it is recommended to use releases
 * awilkins is still waiting for MKS
<LarstiQ> 15:01:10< nevans> jelmer: I'm up to date with http://people.samba.org/bzr/jelmer/bzr-svn/stable/, and I'm getting "using experimental bzr-svn mappings; output may change
<LarstiQ> 15:03:20< jelmer> nevans: you should not be using it for production type data but a release instead
<LarstiQ> specifically
<AfC> LarstiQ: very well
<AfC> Incidentally, as I was trying to grab that branch I got
<AfC> bzr: ERROR: Repository KnitPackRepository('file:///home/andrew/vcs/launchpad/bzr-svn/.bzr/repository/') is not compatible with repository KnitRepository('http://bazaar.launchpad.net/%7Ejelmer/bzr-svn/trunk/.bzr/repository/')
<AfC> which is an error I don't understand
<awilkins> Means the repository formats are not compatible
<awilkins> were you doing a branch inside a repsository folder?
<awilkins> Or pulling into a pre-inited repo?
<awilkins> Incpompatible repo formats are one of the things about bzr I find discomfiting
 * awilkins is still waiting for MKS
<LarstiQ> AfC: yeah, that sucks :(
<LarstiQ> AfC: ties into the 'too many formats in play'
<LarstiQ> discussion we had
 * awilkins is still waiting for MKS and now wants to wage Jihad on Mortice Kern Systems
<awilkins> You should deprecate some of them, split them out of the codebase and make them plugins, including conversion routines to newer formats. Of course, that needs robust converters.....
<AfC> awilkins, LarstiQ: originally, yes, but then I got the same error when I tried to pull into a --knits repo.
<AfC> "1.0". Sure.
<awilkins> It's dirstate-with-trees AFAIK
<awilkins> Yeah, 1.0 was a bit premature... SVN waited for almost geological time before delcaring 1.0
 * awilkins is still waiting for MKS
 * AfC is trying the 100 revisions at a time approach. It's taking a while.
<awilkins> Yup, it certainly does
<awilkins> It's not too bad once it's finished.
<awilkins> I got the trunk of a 1.5GB repo converted in about 12 hours... then deleted it accidentally :-(
<spiv> jam: yes, bzr-svn does commit a write group for every revision
<spiv> jam: I asked jelmer about it, it's done intentionally so that interrupted imports can be continued.
<spiv> jam: I agree though, I think I'd like to see a less extreme policy like every 100 commits.
<LarstiQ> 15:54:52 <jelmer> nadeel van meerdere revisies per write group is dat je eigenlijk heuristiek nodig hebt om te bepalen hoeveel revisies je per keer wilt
<LarstiQ> 15:55:44 <jelmer> en dat is oa afhankelijk van hoe duur het sluiten/openen van een write group is, en dat is weer repository-specifiek
<LarstiQ> drawback of multiple revisions per write group is that you need a heuristic to determine how many revisions you want per batch
<awilkins> My Dutch is a leeeetle bit rusty
<LarstiQ> which among others depends on how costly it is to open/close a write group, and that again is repository specific
<LarstiQ> awilkins: hey, you saw it was Dutch ;)
<LarstiQ> anyway, that's the translation
<awilkins> LarstiQ: Nope, I just know Jelmers NS maps to .nl
<LarstiQ> awilkins: ah.
<LarstiQ> Dutch and English really look a lot alike to me
 * dato sends glasses in LarstiQ's direction.
<spiv> LarstiQ: well, there already is a heuristic
<spiv> LarstiQ: it's just that it's hard-coded to 1 ;)
<LarstiQ> spiv: I'm just the messenger! ;)
<barry> does anybody know what this error means: 'bzr: ERROR: Files are in different branches' ?
<barry> more importantly, how to fix that? :)
<spiv> barry: what's the command?
<barry> spiv: bzr branch rocketfuel pristine; cd pristine; bzr diff . ../rocketfuel
<LarstiQ> barry: bzr diff -r branch:../rocketfuel
<barry> LarstiQ: thanks, that seems to work.  is that something that's changed since 1.0?
<LarstiQ> barry: let me look that up, it changes when I wasn't present to object at least
<LarstiQ> barry: yeah, 1.1rc1
<LarstiQ> barry: oh, the NEWS entry suggests --new
<spiv> There's bzr diff --old/--new now.
<barry> LarstiQ: ok, cool, thanks.  yesterday i updated from 1.0 to 1.2
<LarstiQ> * The syntax ``bzr diff branch1 branch2`` is no longer supported.  Use ``bzr diff branch1 --new branch2`` instead. This change has been made to remove the ambiguity where ``branch2`` is in fact a specific file to diff within ``branch1``.
 * LarstiQ mourns the passing of `bzr diff branch1 branch2`
 * barry does too, but atleast there's a workaround!
<barry> LarstiQ: thanks!
<LarstiQ> barry: glad to be of help
 * LarstiQ tries the expense form once again
 * awilkins has finished waiting for MKS
 * awilkins wonders why MKS is still eating a whole CPU when it's claiming to be doing nothing
<awilkins> Perhaps it something to do with having 42 threads going.....
<ubotu> New bug: #201040 in bzr "Break-lock of a branch bound by another branch causes "infinite" recursion" [Undecided,New] https://launchpad.net/bugs/201040
<Stavros> can i version my code automatically? i.e. include a placeholder that bzr will fill in automatically with revision number/version?
<asabil> Stavros: iirc not supported yet
<Stavros> ah, thanks
<LarstiQ> Stavros: you can use `bzr version-info`
<Stavros> LarstiQ: oh, i see, so i can output a python file with the relevant strings, then?
<dato> Stavros: rather, in any format you want, with --template (I think)
<Stavros> yes, thanks, that's a good solution
<sque> Hi!
<sque> I did bzr add on a folder and addded recursively all the files in it, but I needed only the folder. Now how can I remove versioning from files inside this folder without removing them?
<itzsid> I got this one in project ideas, "Update the PQM with an XMLRPC interface instead of an email based one. So that when 'pqm-submit' is finished, you know the pqm has your data. Also, it would be nice if the pqm could perform quick sanity checks at this time."
<itzsid> could some body explain it more clearly ??
<LarstiQ> sque: bzr rm --keep
<sque> LarstiQ Ty!! :D
<james_w> itzsid: PQM at the moment only works by email, this means that you send an email, and then some time later you either get a confirmation or an error. Adding XMLRPC means that you get an error straight away, rather than having to worry about emails being held up.
<james_w> itzsid: are you interested in doing a bzr SoC project then?
<james_w> hi LarstiQ
<itzsid> james_w: may be, i was just looking for ideas
<james_w> itzsid: there are probably more ideas not on the page if you have any you want to suggest.
<LarstiQ> heya james_w
<itzsid> james_w: do you know if anyone doing that XMLRPC interface ?? I am quite interested
<james_w> itzsid: I think Odd_Bloke was interested in that one.
<itzsid> james_w: its ok
<spiv> itzsid: PQM could validate requests earlier than it currently does
<spiv> itzsid: if you send a request with the wrong GPG key, or for a branch you don't have access to, or for a branch that PQM doesn't know about, PQM should be able to report that problem immediately.
<spiv> itzsid: instead, it waits until the request hits the top of the queue before doing even basic checking.
<itzsid> spiv: ok, Is there any similar idea left, where some work can be done ?
<LarstiQ> similar in what sense?
<spiv> itzsid: well, the problem I just mentioned is still waiting for someone to work on it AFAIK :
<spiv> :)
<itzsid> spiv: Are you talking about a different idea than james_w ?
<itzsid> spiv: because he told Odd_Bloke was interested in this one
<spiv> itzsid: yeah, I am.
<spiv> itzsid: the "it would be nice if the pqm could perform quick sanity checks at this time." part.  It's orthogonal to adding an XML-RPC interface in my opinion.
<kiko> spiv, is the fact that you need to break-lock multiple times to free a branch up a known bug?
<spiv> kiko: partly
<spiv> kiko: it seems that there's multiple server-side processes waiting (one per client that attempted to acquire the lock while it was already locked?), so you need to break-lock to clear the backlog.
<kiko> could the smart server be smarter about that?
<spiv> kiko: although the server-side ought to have a lock wait time of 0 seconds now, IIRC.
<spiv> So I'm a bit surprised it's still occuring.
<spiv> So "known bug" in the sense of "known to happen", but not in the sense of "fully understood".
<kiko> I see.
<itzsid> spiv: I got it
<LarstiQ> spiv: it is, but I'd think both can be done under one PQM umbrella this summer.
<Odd_Bloke> Moin.
<Odd_Bloke> (he said, at 6:10pm)
<spiv> LarstiQ: ah right, I came in halfway through and didn't realise we were talking about GSoC projects.
<sque> I want to push some changes on my branch at lauchpad
<sque> from linux it worked with my ssh key
<sque> now that I am from windows how can I do it?
<LeoNerd> pagent?
<sque> just discovered it
<itzsid> spiv: I looked at the ideas page but couldn't get it. Do you have any more ideas which could be worked ??
<sque> LeoNerd: must I create a new ssh key? or can I use it the one created inside linux?
<LeoNerd> Either will work..
<LeoNerd> Best practice says you should make a new key per client machine
<LeoNerd> The private key ought never to leave the machine it was generated on, see
<LarstiQ> itzsid: what would you like to work one?
<sque> it is the same machine
<sque> dual-boot
<itzsid> LarstiQ: anything involving XMLRPC
<LarstiQ> itzsid: I don't know that we have much of that. Somewhat related would be SmartServer work.
<itzsid> LarstiQ: what's SmartServer
<LarstiQ> itzsid: a smart server that implements higher level logic, as opposed to dumb vfs transports
<LarstiQ> itzsid: http://bazaar-vcs.org/Specs/SmartServer and http://bazaar-vcs.org/SmartServer/RemoteObjectHacking
<itzsid> LarstiQ: is it there for GSoC ?
<james_w> itzsid: you can propose anything you like for GSoc.
<itzsid> james_w: I mean, is it in the scope to be done as a GSoC Project
<james_w> itzsid: yeah, if you define what you want to do well enough.
<james_w> There is plenty to do on the smart server, so just "work on the smart server" is probably too generic, but "add verbs for this, this, and this to the smart server" may be better.
<itzsid> james_w: ok
<AfC> Here's maybe a better question that what I was asking earlier: are the revisions created by Launchpad's vcs-import and by bzr-svn compatible?
<jelmer> AfC: Nope
<AfC> ie, can I use the vcs import, and then update it with, and push back to, with bzr-svn?
<AfC> jelmer: I didn't think so. Damn, etc
<jelmer> AfC: That's actually what you were asking earlier worded differently :-)
<AfC> jelmer: sorry.
<AfC> jelmer: (though I have long ago learned that sometimes you need to ask the right question :))
<jelmer> no worries, it's a fair question
<AfC> jelmer: LarstiQ was quite helpful with some testing there
<jelmer> AfC: what sort of testing?
<AfC> jelmer: someone should tell the launchpad people that their import is pretty difficult to make use of as a result
<AfC> jelmer: oh, I was exploring what would happen if someone tar'ed up a bzr-svn created branch+repo and scp'd it to another person locally (or over the net for that matter) t
<AfC> to amortize the cost of constructing the initial bzr-svn branch
<jelmer> AfC: ah
<jelmer> AfC: if you have the memory leak fix that's in ubuntu hardy it should be pretty quick I expect
<jelmer> what did you find?
<AfC> I'm getting about 1 revision every 5 seconds; it will be a non-starter if I try to promote Bazaar to the people championing Git if it takes this long to compose
<AfC> jelmer: he got most of the way, but couldn't test whether or not pushing back to a different username would work
<jelmer> AfC: What version are you using exactly?
<jelmer> I fixed a quite large performance bug in it with spiv during the sprint
<AfC> (I know; awesome)
<AfC> the patched version of subversion 1.4.6 and bzr-svn 0..4.7
<AfC> [where "patched" is "that which was necessary to make it run at all, as defined by bzr-svn"]
<AfC> Anyway, I'm doing the "pull 100 at a time" thing right now.
<jelmer> The memory leak fix may help somewhat there
<jelmer> the memory leak also slows it down because of the way the APR memory pools are implemented
<AfC> I tried building Subversion from source but it didn't go very well
<jelmer> it only works during a full moon
<jelmer> and with the exact right version of SWIG, etc
<AfC> Is the "memory leak fix" something other than "that which was necessary to make it work at all"?
<jelmer> yes
<AfC> (I mean, my Gentoo ebuild builds it from source fine. I just couldn't quite replicate those conditions by hand very well)
<AfC> jelmer: ah
<jelmer> We fixed the memory leak only a couple of months ago
<jelmer> the other patches are over a year old by now I think
<AfC> Maybe I should do 10 revisions at a time
<AfC> ah
<AfC> gotcha
<AfC> Sure would be nice if the Subversion team would do 1.4..7
<AfC> {sigh}
<jelmer> or 1.5.0, that would remove the need to do any patches at all
<spiv> jelmer: thinking of making releases, when's the next bzr-svn release? :)
<jelmer> spiv: 5 minutes from now :-)
<jelmer> I'm fixing the last 5 tests at the moment
<spiv> Sweet.
<AfC> spiv: I dunno. Do you think we can wait that long?
 * AfC wonders if the Subversion crew do snapshot releases?
<jelmer> I think they may do something like that for Subversion 1.5
<AfC> I just poked around on their website, and couldn't find anything in released form
<AfC> Ouch. This is taking 2 minutes per 10 revisions. Only 14,000 to go
<AfC> [Now I understand why shallow branches are going to be important when they land]
<awilkins> jelmer: Want a win32 test log?
<jelmer> awilkins: Sure
<awilkins> jelmer: Hold on... for which bzr version
<jelmer> awilkins: Please use the 0.4.8 branch
<jelmer> That's the one I'm trying to release at the moment
<awilkins> Revision 939?
<awilkins> Oh, it diverged from r 939?
<jelmer> yes
<jelmer> that's the 0.4 branch
<jelmer> which will become 0.4.9, not 0.4.8
<awilkins> well, it's on both branches
<awilkins> 0.4 is on 945
<snod> o.w 20
 * awilkins pulls 0.4.8 again
<Zectbumo> it looks like the Summer of Code project to integrate bazaar in Visual Studio didn't happen.
<jelmer> Zectbumo: It's up on launchpad
<Zectbumo> August 2007 was supposed to be the code checkin
<Zectbumo> jelmer: oh, where is that?
<jelmer> Zectbumo: yes, where are you looking for it?
<jelmer> https://edge.launchpad.net/bzr-visualstudio
<Zectbumo> aha, perfect, thanks jelmer
<awilkins> jelmer: Erm, am I getting this right, http://people.samba.org/bzr/jelmer/bzr-svn/0.4.8/ at r 906?
<Zectbumo> jelmer: does the VS plugin work?
<mxpxpod> I just used bzr-svn to commit something to a project I work on and bzr set some properties on the subversion trunk... is there a way to keep that from happening?
<james_w> mxpxpod: no, they are necessary for bzr-svn to keep track of what happened.
<jelmer> awilkins, yep
<jelmer> Zectbumo: not sure, I've never used it myself
<james_w> mxpxpod: are you using trac by any chance?
<jelmer> Zectbumo: afaik it at least works to some degree
<jelmer> awilkins: I'll be back in a couple of hours
<mxpxpod> james_w: yeah, I am
<mxpxpod> james_w: http://trac.dojotoolkit.org/changeset/13037
<jelmer> awilkins: Thanks for doing this. Kevin Light is also interested in packaging Subversion 1.5 (with the memory leak fix) and bzr-svn 0.4.8 for Windows
<jelmer> awilkins: So hopefully bzr-svn 0.4.8 will rock on Windows!
<james_w> mxpxpod: yeah, it's ugly and that's unfortunate. However if you want to make bzr-svn work two way it is necessary, as svn doesn't track the merges itself.
<jelmer> mxpxpod: IIRC there was some option to hide those properties in trac
<jelmer> svk has the same problem
<mxpxpod> james_w: so, I should just specify the files I'm committing explicitly each time?
<jelmer> mxpxpod: it will always set those file properties
<james_w> jelmer: hi. OOI are you compatible with svk in any way?
<mxpxpod> jelmer: darn... that's kinda ugly
<jelmer> mxpxpod: it's the way these things work in Subversion
<mxpxpod> a buddy of mine uses git-svn and it doesn't set props like that...
<jelmer> mxpxpod: yes, but git-svn doesn't allow roundtripping afaik
<mxpxpod> roundtripping?
<jelmer> yes, working on a svn branch as if it was a native bzr branch
<jelmer> sorry, really have to go now. back in a couple of hours
<awilkins> mxpxpod: It looks ugly in Trac, but that's about it ; and I strongly suspect SVN 1.5 implements merge tracking a similar way
<awilkins> svk also sets custom props
<awilkins> Although not *quite* so heavily
<mxpxpod> awilkins: I'll talk to the dojotoolkit server op and see if we can't get trac to hide those props
<awilkins> http://trac.edgewall.org/wiki/TracIni#browser-section
<mxpxpod> awilkins: thank you
<awilkins> Not sure theres one for the timeline though
<mxpxpod> awilkins: what's the timeline?
<asabil> Zectbumo: last time I tried it worked
<Zectbumo> asabil: tried it as in worked with it? or just played with it?
<asabil> Zectbumo: I just played with it
<mxpxpod> awilkins: oh, you mean the trac timeline
<james_w> beuno: nice work on the podcast, I like it.
<mxpxpod> awilkins: do you know if that list of properties to hide can be a glob?
<beuno> james_w, thanks!  I listened to it again, and I would of liked to of explained things a little better
<awilkins> Dammit, this laptop really is bogged down with a tonne of pointless IT services crap
<awilkins> The person who invented on-access virus checking should be shot for crimes against computing
<mxpxpod> ok, I have a checkout of an svn repo and it has three bzr: props on it: bzr:revision-id:v3-trunk1, bzr:file-ids, and bzr:revision-info... will those three props be on there whether I use a checkout or a branch?
<awilkins> I should think so
<awilkins> It's a checkout of a bzr branch?
<mxpxpod> no, I did this: bzr checkout svn://blah
<mxpxpod> the reason I'm asking is that I want to make sure that I've got all the bzr: props that could show up in the hide_properties list
<awilkins> jelmer: http://filebin.ca/ohcutg/log.zip
<awilkins> mxpxpod: Do a grep through the source
<awilkins> They're all in mapping.py
<mxpxpod> awilkins: cool
<mxpxpod> awilkins: what about those ones that bring in a mapping version... like bzr:ancestry and bzr:revision-id
 * mxpxpod wishes trac would allow him to do hide_properties = bzr:*
<awilkins> They all seem to be in one block of constants at the top of mapping.py
<alexreg> hi
<alexreg> i'm trying to use bzr-ssh/sftp on windows, but launchpad seems to be rejecting the key...
<alexreg> (seems to be authenticating fine in putty however)
<awilkins> alexreg: Are you using pageant?
<alexreg> yeah. the key's been added
<awilkins> Does it work with another ssh host?
<alexreg> haven't tried. is there any simple way to do so?
<awilkins> Unless you have a shell account on another box, possibly not :-)
<alexreg> i'm thinking it's unlikely to be a host problem, considering putty auths well
<alexreg> yeah: i suppose i could set one up on ubuntu under a VM, if it's worth it...
<awilkins> Are you using plink or the native paramiko support?
<alexreg> not sure. i ran the standard windows installer, with all options on.,
<awilkins> Putty/plink on the path?
<alexreg> i assume paramiko is standard?
<awilkins> yes
<alexreg> yup, just checked that
<awilkins> I know plink works with my local SSH server
<alexreg> i should let you know: this is what happens with sftp
<alexreg> Permission denied (publickey).
<alexreg> bzr: ERROR: Unable to connect to SSH host bazaar.launchpad.net; EOF during negotiation
<awilkins> set BZR_SSH=plink
<alexreg> with bzr-ssh...
<alexreg> bzr: ERROR: Unsupported protocol for url "bzr-ssh://alexreg:felagund@bazaar.launchpad.net/~alexreg/windows-ssh-server/de
<alexreg> vel"
<alexreg> ok i'll try that
<james_w> alexreg: it's "bzr+ssh".
<awilkins> Dunno Oh, and that
<alexreg> sorry, typo
<awilkins> Tried Filezilla sftp: ?
<awilkins> (filezilla uses the putty implementation)
<alexreg> oh right: now i am getting the same error with bzr+ssh. thanks
<alexreg> will do
<awilkins> If you have pageant running it even uses the keys
<alexreg> sorry for the delay: filezilla is logging in correctly
<mxpxpod> if I'm using bzr-svn, should I be using checkout or branch to get svn repos?
<awilkins> mxpxpod: branch
<mxpxpod> awilkins: and then to commit, just do a bzr commit; bzr push?
<awilkins> mxpxpod: You have to have a bzr branch to work with. You can checkout from that
<awilkins> mxpxpod: For the moment, I think it's bzr svn-push (unless jelmer merged it with the std API already)
<mxpxpod> awilkins: ok
<mxpxpod> awilkins: and that will merge with trunk?
<alexreg> awilkins: so are you thinking the issue is bzr-specirfic now?
<alexreg> awilkins: yeah, i use sftp
<awilkins> alexreg: Dunno, did you try setting BZR_SSH=plink
<mxpxpod> hrmm... bzr-svn doesn't like svn views
<mxpxpod> or, rather, svn:externals
<alexreg> BZR_SSH is an env var?
<awilkins> alexreg: yes
<awilkins> mxpxpod: No, svn:externals not supported
<mwhudson> james_w: hi
<mxpxpod> awilkins: ok, thanks
<james_w> hi mwhudson
<mwhudson> james_w: thanks for replying to that mail :)
<james_w> mwhudson: I felt the need to since you asked so nicely :)
<mwhudson> james_w: i was going to try and discuss it here, but actually i think just replying to your mail makes more sense :)
<james_w> mwhudson: that's up to you.
<alexreg> awilkins: thanks, all seems to be working well now :)
<alexreg> awilkins: out of curiosity, why is plink required?
<awilkins> alexreg: I presume because the standard SSH support doesn't work :-)
<awilkins> alexreg: I never tried the paramiko support ; I'm a long-time putty user, so plink was a natural choice for me
<alexreg> awilkins: fair enough. putty does seem to be the most stable/reliable package for all ssh things in windows
<alexreg> i appreciate the help...
<alexreg> bye
<awilkins> You're welcome
<mwhudson> james_w: replied, does it make more sense now?
<james_w> mwhudson: yes, thanks. I replied as well.
<james_w> mwhudson: people were telling me that you are an ex-Bristol resident, 'tis true?
<mwhudson> james_w: yes, it's true
<mwhudson> james_w: thanks for the reply
<james_w> mwhudson: that's where I live currently, when did you leave?
<mwhudson> james_w: january
<james_w> really? That's a shame.
<james_w> well, I guess it's not for you :)
<mwhudson> yeah, seems like a missed oppourtunity
<mwhudson> where do you live?
<mwhudson> i was on oakfield road off whiteladies
 * mwhudson on phone now
<james_w> mwhudson: top of St. Michaels Hill.
<mwhudson> james_w: so we were like half a mile apart
<mwhudson> oh well
<mwhudson> james_w: do you work in bristol?
<mxpxpod> does "bzr update" work on branches?
<Odd_Bloke> mxpxpod: Yes, but I suspect that isn't the question you're trying to ask. :)  'bzr update' operates on bound branches (i.e. checkouts of other branches), and updates the local branch to be the same as the remote branch.  Running 'bzr update' on an unbound branch (i.e. one created with 'bzr init' or 'bzr branch') will not really do anything.
<mxpxpod> Odd_Bloke: hmm, ok
<Odd_Bloke> mxpxpod: Does that help?
<mxpxpod> I think so
<mwhudson> (well update also updates the tree wrt the information in the branch)
<mwhudson> (but ignore this for now)
<mxpxpod> I've got a bunch of bzr branches from svn repos and I'm trying to figure out how to update them
<Odd_Bloke> mxpxpod: How did you create them?
<mxpxpod> bzr branch http://some-svn-repo.com/trunk
<mxpxpod> do I want to update them using bzr merge?
<bob2> mxpxpod: bzr pull ...
<bob2> mxpxpod: well, actually, depends what you're doing with them.  if the svn and bzr branches are both being developed on (ie one does not have a subset of revisions of the other), then you want merge.
<mxpxpod> on some, I'm just tracking upstream
<mxpxpod> on others, I'm actually doing development
<bob2> "bzr merge --pull" will pull if possible, merge if needed
<Odd_Bloke> mxpxpod: The standard workflow would be to have a local, pristine mirror of the SVN branches (in which 'bzr pull' is used).  You would then branch off of that pristine mirror to do work (and would 'bzr merge' changes from the mirror branch in).
<mwhudson> _probably_ what would be sensible is ...
<mwhudson> to do what Odd_Bloke just said
<mwhudson> james_w: replied again
<mxpxpod> Odd_Bloke, bob2, and mwhudson: thanks
<Odd_Bloke> mwhudson: Incidentally, I'd like to have a look at the colouring of revision backgrounds (bug #199571) but won't have time to do so for a week or two (because I went to the sprint rather than doing the work I'm now doing :p).
<ubotu> Launchpad bug 199571 in loggerhead "contents browser could show age of lines by varying shades of a single colour" [Undecided,New] https://launchpad.net/bugs/199571
<mwhudson> Odd_Bloke: :)
<mwhudson> Odd_Bloke: did you go to the web viewer argument^Wdiscussion session at the sprint?
<Odd_Bloke> Well, the work I should be doing now but am instead catching up on email and chatting on IRC.
<Odd_Bloke> mwhudson: I don't think so, sorry.
<mwhudson> ok
<Odd_Bloke> Or, if I did, I wasn't paying enough attention to remember that I was there. :p
<mwhudson> i am just looking for victims to bounce ideas off
<mwhudson> i guess the sydney folk should be awake now...
<beuno> mwhudson, if you're here in 15', I went to that session  :D
<mwhudson> beuno: not going anywhere
<beuno> (on the hpne)
<beuno> argh, phone
<Odd_Bloke> Impressive typo. :p
 * jml waves
<james_w> mwhudson: I just finished my job today, so I guess the answer is "I did..."
<Odd_Bloke> jml: o/
<james_w> hi jml
<mwhudson> james_w: oh right
<james_w> mwhudson: I don't have anything to reply right now, but I'll read it again tomorrow and see if anything strikes me.
<mwhudson> james_w: thanks
<james_w> jam: I keep getting bounces from your secondary MX. I think you said you were graylisting. I seem to be graylisted by your primary MX, and my server then retries with the secondary and gets rejected (550 Administrative prohibition)
<james_w> jam: ah, it seems it's not graylisting that pushes it on to the secondary, but "450 Client host rejected: cannot find your hostname"
<beuno> mwhudson, back  :D
<beuno> sorry I haven't answered your thread, I'm still hoping around different places, and don't have much time to answer coherently
<beuno> but I have a while now  :)
<beuno> mwhudson, one thing that would be cool is to able to expand the history navigation, when looking at a specific commit, what files where touched
<beuno> also, I haven't looked at the code, but, how complex would it be to implement a nice interface with CSS and javascript to navigate history. I already have been doing some of that work for a PHP app, and I think it might be useful
 * beuno just notices the "files" bit on there, so ignore my first comment
<LarstiQ> Zectbumo: if you have any questions on the VS integration, feel free to ask.
<LarstiQ> james_w: you should probably mention branch.last_revision_info() before branch.revision_history()
<LarstiQ> james_w: although you are correct for that use case, in a lot of cases people don't need the full mainline history but just the last revision
<LarstiQ> james_w: and in that case calling revision_history() is a performance killer
<james_w> LarstiQ: does last_revision_info() return revno as well? Isn't there last_revision() as a shortcut for revision_history()[-1]?
#bzr 2008-03-12
<Zectbumo> LarstiQ: thanks :)
<james_w> LarstiQ: thanks for the tips though, I think it's important to mention.
<LarstiQ> james_w: last_revision_info also returns a revno, last_revision does last_revision_info()[0], and for Branch6 formats last_revision_info does not touch the revision history, since the information is stored in that branch format
<james_w> LarstiQ: great, thanks.
<LarstiQ> james_w: it is especially fun and noticable when doing a revision_history() of Mozilla over the network
<LarstiQ> 9Mb of revision history just to print the revno, ugh
<LarstiQ> Zectbumo: I'll go to bed in a second, but I'll read backlog
<LarstiQ> Zectbumo: quite a bit of work has been done last summer and it is functional, it could use more polish
<LarstiQ> Zectbumo: I suppose you're a VS user?
<Zectbumo> LarstiQ: I just started
<Zectbumo> er, was forced
<Zectbumo> LarstiQ: well, I'm going home from work now, so no worries
<LarstiQ> Americas timezone?
<Zectbumo> yup
<mwhudson> beuno: hi
<beuno> mwhudson, hey
<mwhudson> beuno: so i heard a rumour you had some kind of php app we might want to steal ideas from?
<lifeless> ideas/css/ajax/voodo
<mwhudson> beuno: i have to say i'm a little tired of suggestions like "implement a nice interface with CSS and javascript to navigate history."
<mwhudson> because the design is much, much harder than the implementation :)
<beuno> mwhudson, right. I've actually been working on a web app for bzr for the last year
<beuno> so I have quite some work on the interface bits
<beuno> I should be arriving back home on the 20th, and my primary use of free time will be to get the interesting bits out of it
<beuno> and open source them
<beuno> and maybe let you take a peak beforehand to see if it's useful for you
<beuno> the rest of the PHP should follow, just think the css + ajax might be of more use now
<mwhudson> that would be very cool, yes
<beuno> so, it wouldn't be impossible to slap a new interface on that?
<beuno> s/that/loggerhead
<mwhudson> shouldn't think so
<beuno> cool. I'll be more than happy to work on this with you, using what I already have, or starting from scratch if there are good reasons to do so
<mwhudson> is there a public facing version of this app anywhere?
<beuno> mwhudson, no, that's the problem
<beuno> but I will get it up somewhere I can let you look
<mwhudson> beuno: as i've been posting to the list, it's developing a coherent and sensible model for navigation that's got me stumped at the moment
<mwhudson> beuno: can you explain briefly what you did?
<beuno> mwhudson, yes, let me try
<beuno> basically, what I have right now, is PHP getting all bzr history into a database. All that is used as a part of our internal workflow software, so there are many unrelated bits. Among those bits, you have one, that is currently broken due to last minute changes, which is history navigation through an ajax interface
<beuno> since most users that use the system are bzr-ignorant
<beuno> I went through a few redesigns with a few of the graphic designers to make it easier to understand
<beuno> that led me to a more comprehensive history navigation, but also to some bzr-unrelated things I have to strip out to open it up to the world
<beuno> it's all CSS + mootools for ajax effects
<beuno> so it should be easy to port on top of pyhton
<mwhudson> ok
<beuno> there are also some nice looking icons I have to make sure aren't used somewhere else
<mwhudson> that still doesn't explain to me what the history navigation is like :)
<mwhudson> (sounds pretty cool though)
<beuno> ah, right
<beuno> let me try and describe from memory
<beuno> I don;t think it's too much far off what you have right now, at least what I saw on the last PNG
<beuno> it shows all revisions, and you can expand them with ajax as many levels deep as there is
<beuno> each one has all the relevant information on it, commiter, time, message, files changed/added/removed
<beuno> everything related to that revision can be seen by clicking on it
<beuno> and without refreshing the page
<mwhudson> do you have separate views for annotate/file listing/revisions ?
<mwhudson> revisions with diffs, rather
<beuno> there are some additional links which take you to per-file histories
<beuno> yes, although, if IIRC, we don't have annotate yet implemented
<beuno> just file listing and revisions
<mwhudson> ok
<beuno> and you jump from one to the other if needed
<beuno> of course, none of this seems like much unless I can show
<beuno> which I can't, because I'm 16.000km away from the office
<mwhudson> when looking at the file history, do you show the actual revisions that change the file or the mainline revisions that merge the changing revisions?
<beuno> (and, about 10 hours work to fix new bugs introduced when updating it)
<mwhudson> (is there much of a mainline/non-mainline distinction?)
<beuno> actual revisions that change the file is the one that sticked. Before, we showed the files, just in a very greyed out color to show that it wasn't actually touched in that revision
<mwhudson> i'm not sure i understand
<mwhudson> you tried more than one approach?
<beuno> yeap
<beuno> it evolved over time as people complained
<beuno> it's been a long year  :D
<mwhudson> interesting :)
<beuno> yes, I would of really liked to get this out in the open before, but I just kept postpoing til I could clean up the code
<beuno> for which I ended doing things directly on bzrlib
<beuno> which ended up with me at the sprint
<mwhudson> heh, i know that one :)
<beuno> so now I have to go back to the start
<beuno> I'm sure you do much better  ;)
<beuno> my thought after the sprint where
<beuno> if I can show what I have right now to you
<beuno> and you feel it's worth working on
<beuno> I can invest a few days in abstracting a bit more so we can share the same interface code
<beuno> and make sure all future work gets merged back both ways
<beuno> (or even for some other project, I suppose)
<mwhudson> well, i'm definitely extremely interested in seeing the results of incorporating a year's worth of user feedback
<beuno> also, we don;t use IE at all, so there might be some IE-specific CSS and Javascript bugs I don'y know about
<mwhudson> well, i don't either (surprise, surprise) but i'm sure we can find some way of testing it
<beuno> (my typing is awful today)
<beuno> hehe
<beuno> good to hear
<mwhudson> and/or just paying someone to make the problems go away
<mwhudson> i also don't know and don't really want to know php
<beuno> right, we can talk about that later on, I might be able to put in some time from my web designers into it, but it depends on how bad it is  :p
<beuno> I'll make sure none leaks into the interface
<nDuff> has anyone written a plugin for p4 support?
<mwhudson> beuno: so, when do you think you'll have something i can look at?
<mwhudson> some time after the 20th?
<beuno> mwhudson, exactly  :)   it should be before the end of march, it's high on my ToDo list, especially after the fine folks from Canonical fed me and gave me nice slippers for a whole week  :p
<LarstiQ> nDuff: yes
<LarstiQ> nDuff: that is, I recall robey posting about it
<mwhudson> beuno: i'm away for the last week of march (roughly speaking)
<beuno> mwhudson, ok, I'll probably mail to the list than, start gathering feedback so you have a much bigger backlog to read when you get back
<beuno> or, spend some more time polishing it
<mwhudson> beuno: well, i don't want to imply anything at all about you, but i always get a little bit afraid when people say they will do something "the week after next" or so
<mwhudson> that it will never happen
<mwhudson> so the sooner the better, i can live without polish :)
<beuno> sounds reasonable
<beuno> I'll just send it out as soon as I get it running again
<beuno> at the very least. screenshots
<mwhudson> thanks a lot!
<beuno> thank me when it's sent  :D
<abentley> Odd_Bloke: ping
<Odd_Bloke> abentley: Pong.
<abentley> I'm just submitting one of your patches.  What shortname would you like in the log?  Odd_Bloke?  dwatkins?
<Odd_Bloke> abentley: Go for the latter. :)
<abentley> Odd_Bloke: done
<ubotu> New bug: #199629 in trac-bzr "Expose bzr source code?" [Wishlist,Triaged] https://launchpad.net/bugs/199629
<james_w> http://wingolog.org/archives/2008/03/11/using-newfangled-version-control-systems-from-emacs
<james_w> last paragraph is quite interesting.
<Odd_Bloke> abentley: Thanks. :)
<jml> what's the bug for renaming .bzr.backup?
<beuno> jml, bug #124325
<ubotu> Launchpad bug 124325 in bzr "Naming of .bzr.backup directory makes deleting .bzr easy" [Medium,In progress] https://launchpad.net/bugs/124325
<jml> thanks
<beuno> welcome'
<jml> beuno: you were working on renaming the bzr package at the sprint. right?
<jml> how's that going?
<beuno> jml, sent a patch to the list during the sprint
<jml> sweet
<beuno> let me fetch the merge request for ya'
<beuno> (didn't get merged)
<beuno> http://bundlebuggy.aaronbentley.com/request/%3C2422be180803040403y6873e4f0pa7fffe32551a12a1@mail.gmail.com%3E
<beuno> feel free/incentived to review (approve?) it  :D
<jml> I can't approve it -- don't have voting privs
<beuno> well, at least you can make some noise!
<jml> beuno: and I'm running out of review juice for today :)
<beuno> aw, it's fine
<beuno> it's almost 3am, I should be sleeping anyway
<Odd_Bloke> beuno: Whereabouts are you ATM?
<beuno> Odd_Bloke, still in Prague til thursday
<Odd_Bloke> beuno: Cool.
<beuno> then, Madrid for a week or si
<beuno> then, home!
<beuno> anyway, I'm off to sleep
<beuno> night everyone!
<james_w> night beuno
<Odd_Bloke> How long does a PQM run take?
<Odd_Bloke> Also, it turns out that I'm the top contributor to bzr: https://launchpad.net/bzr/
<Odd_Bloke> Who know?
<Odd_Bloke> *knew
<james_w> Odd_Bloke: I think it's more than 30 minutes.
<james_w> more if the queue is busy, but it shouldn't be at the moment.
<james_w> although I can't remember if we still share a PQM with launchpad, which obviously slows things down.
<james_w> There's a page somewhere to view the current queue state, but I can never remember where it is.
<james_w> Odd_Bloke: it seems you get a lot of karma for https://code.launchpad.net/~daniel-thewatkins/
<Odd_Bloke> james_w: Yeah, thumper said that that's the case currently.
<Odd_Bloke> Because few people are using LP Code.
<Odd_Bloke> Well, the current PQM run has been going for around an hour and a half. :p
<Odd_Bloke> (https://pqm.bazaar-vcs.org/)
<thumper> james_w: register some more barnches and you too can bask in the karma glory
<thumper> Odd_Bloke: aren't you in the UK?
<Odd_Bloke> thumper: I am, yeah.
<thumper> Odd_Bloke: what the hell are you doing up then?
<Odd_Bloke> thumper: The work I should have been doing last week. :p
<thumper> :)
<james_w> thumper: :-)
<jamesh> james_w: bzr has a separate PQM instance these days.  It may be running on the same box though.
<thumper> Odd_Bloke: not necessarily few using LP code, just many less than use bugs
<james_w> jamesh: thanks.
<Odd_Bloke> thumper: Yeah, that's probably true.  Surely that's always going to be the case though, so those who do use it will always have high karma?
<Odd_Bloke> (Not that that is necessarily a bad thing)
<thumper> Odd_Bloke: perhpas
<james_w> it would be great if someone could review http://bundlebuggy.aaronbentley.com/request/%3C1204811147.4995.4.camel@ganieda.vernstok.nl%3E
<james_w> I think it's a great thing to have, and is quite simple.
<james_w> Odd_Bloke: you're clearly not doing work, I keep getting bur tracker emails triggered by you :)
<Odd_Bloke> james_w: I'm multitasking... *shifty eyes*
<kanhaiya_kk> hi all
<kanhaiya_kk> i want one simple help
<kanhaiya_kk> i had setup bzr
<kanhaiya_kk> also i know how to use bzr upto a extent for simple project containing only files.
<kanhaiya_kk> but i dont know how to use this bzr for database related projects.
<kanhaiya_kk> how this bzr synchronise databases from client to servre ?
<kanhaiya_kk> server*
<kanhaiya_kk> can anybody put light on this ?
<luks> what do you mean by 'bzr synchronise databases'?
<luks> if you want to upload/download revisions from the server, use bzr pull and bzr push
<luks> but you probably mean something different, as you said it in context of 'database related projects'
<Peng> Humm.
<Peng> How should lp: URLs be represented in branch.conf?
<Peng> It seems they're expanded.
<kanhaiya_kk> luks: im asking about databases synchronisation
<kanhaiya_kk> consider i have a project on server which have mysql database
<luks> bzr versions files, not databases
<Peng> (This is with bzr.dev, with the directory service stuff.)
<kanhaiya_kk> luks: yes yes
<kanhaiya_kk> thats only i was aksing
<kanhaiya_kk> luks: okay means bzr ll not play any role for database synchronisation ?
<luks> right
<kanhaiya_kk> luks: okay thank you
<Peng> Ackpth! bzr-svn opened like a hundred connections. Finally, most of the way through, it bombed on some branch.
<Peng> There was a + sign in the URL>
<kanhaiya_kk> luks: need one more help. im bit confuse in that
<kanhaiya_kk> i ll explain you my scenario first
<luks> ok
<kanhaiya_kk> i have bzr setup on server
<kanhaiya_kk> i have one project called VTS on server
<kanhaiya_kk> i have 2 clients
<kanhaiya_kk> im checking out that project on client using bzr checkout sftp://192.168.100.96/var/www/VTS VTS_local
<kanhaiya_kk> on client i do changes in file and after that i do ...
<kanhaiya_kk> bzr commit and bzr update
<kanhaiya_kk> but now the problem that i facing is that, i cant browse the changes through browser on server...means using http://192.168.100.96/VTS/ (this is server)
<kanhaiya_kk> luks: im cuming in 10 min
<luks> kanhaiya_kk: well, if you want to browse the changes via web, you need to install something that allows you to do that on the server
<luks> https://launchpad.net/bzr-webserve/ and https://launchpad.net/loggerhead/ are two options
<luks> maybe there are some others, but I don't know of them
<Peng> bzrweb.
<kanhaiya_kk> luks: okay
<kanhaiya_kk> but the procedure, im adopting is right na ?
<kanhaiya_kk> luks: i dont want to browse bazaar repository. simply i want to browse my project.
<luks> not sure what does that mean :)
<luks> oh
<kanhaiya_kk> are you getting what i mean to say ?
<luks> I probably repeat this too often in this chanel, bzr is a version control system
<luks> not a deployment tool
<luks> if you want the working tree on the server, you need to create it (but I assume you already have it) and update it everytime you push to it
<kanhaiya_kk> that is right. but is it necessary that i have to ssh server and do "bzr update" for reflecting changes
<luks> there is push-and-update plugin, which does both in one step
<kanhaiya_kk> okay
<luks> but I'd still consider a different approach
<luks> using 'bzr push' to update a live website just doesn't seem right to me personally
<kanhaiya_kk> tell me what is your approach ?
<kanhaiya_kk> okay okay
<kanhaiya_kk> then ?
<luks> I'd use 'bzr checkout' for the website
<luks> and then run 'bzr update' every time I want to update it
<luks> but I'd push to a different location, never to /var/www
<kanhaiya_kk> this is for what ?
<kanhaiya_kk> means due to ?
<luks> it gives you separation between the source code repository and the running website
<kanhaiya_kk> okay.
<luks> just like I'd never install a svn commit hook to update a website, I'd never push directly to a running website from bzr
<kanhaiya_kk> then what do you do for browsing the changes from server ?
<luks> 'bzr update'
<kanhaiya_kk> by doing ssh to server?
<luks> yes
<kanhaiya_kk> that means i have to provide access to server to each developer ?
<luks> you would need to do that with the push-and-update plugin, too
<kanhaiya_kk> okay fine.
<kanhaiya_kk> is this comes with apt-get ?
<luks> there are other options, like running it regulary from cron or watching for changes in the branch
<luks> what? the plugin?
<kanhaiya_kk> yes
<luks> no, I don't think so
<kanhaiya_kk> okay
<luks> https://launchpad.net/bzr-push-and-update
<kanhaiya_kk> okay.
<kanhaiya_kk> now just i want your suggestion ?
<luks> my suggestion was to not do it automatically
<luks> which is not what you want :)
<kanhaiya_kk> generally we do opensource development on CMS,PHP projects.
<kanhaiya_kk> no thats not the case
<fullermd> I too am often surprised at the number of people who want the VCS to handle deployment...
<fullermd> Always seems weird to me.  I did it once with CVS many years ago, and it was horrible.  All sorts of reasons come to mind to avoid it.
<kanhaiya_kk> so what procedure should we follow, so that each developer dont have to bother about time. means by simply giving 2-3 commands he can commit changes and also can browse the changes from server, without giving them ssh access to server
<fullermd> Not least among them, that what's in the VCS isn't directly what needs to be deployed.  There's all sorts of things in there that shouldn't go on a live site, the arrangement of the files that should isn't the same, and there's often stuff like permission frobbing that needs to be done too.
<awilkins> Need some kind of continuous intgration server that runs a build / deploy script when you push to a certain branch
<kanhaiya_kk> luks: ?
<awilkins> Shame there are no server-side commit hooks yet ; but you could probably adapt push-and-update given that it just uses SSH to run "bzr update" on the target branch after it runs
<luks> kanhaiya_kk: I don't know of anything that wouldn't involve scripting
<kanhaiya_kk> okay
<luks> but as I said, the whole 'developer dont have to bother' seems wrong to me
<luks> the developer _should_ bother
<luks> and not all changes require just updating the working tree
<luks> for example sometimes you need to change the schema
<luks> (DB schema)
<luks> how would you do it if your main repository is the running website and automatic 'bzr update' is the only way to access it?
<kanhaiya_kk> luks: hmmm
<mlh> I have an idea to solve this, but it would indeed need scripting
<mlh> a lot of the scripting could be standardized
<kanhaiya_kk> mlh: hmm tell me
<mlh> keep the metadata has ordinary textfiles
<kanhaiya_kk> im totally confused. Our team is thinking to use bzr for development server
<mlh> generate or sync to/from the text file with scripts
<mlh> version the textfile with bzr (or any other vcs)
<kanhaiya_kk> okay
<fullermd> The rest is just a SMOP   :p
<mlh> :-)
<rlubert1> hi, I'm using a "bound branches" model...but on the server repository I always get "working tree out of date"...can you help me?
<awilkins> rlubert1: Pushes do not update the remote tree
<luks> I wonder if there is some kind of FAQ page on the wiki
 * awilkins vote to have this emblazoned in letters of fire at the top of all bzr documentation pages.
<fullermd> There is.
<fullermd> Whether it includes Q's that are really FA is another matter...
<rlubert1> awilkins: ok, thanks
<kanhaiya_kk> can i get examples for bzr enabled projects ?
<fullermd> awilkins: If you think it would help; it only tells you so every time you push   :p
<awilkins> No offense to yuo, rlubert1, it just constitutes about 90% of the questions asked in here :-)
<Peng> kanhaiya_kk: Projects that use bzr?
<awilkins> http://bazaar-vcs.org/WhoUsesBzr
<rlubert1> awilkins: I was following this example: http://bazaar-vcs.org/BzrUsingBoundBranches, no problem
 * Peng notes that WhoUsesBzr is linked to from the homepage.
<kanhaiya_kk> Peng: yes
<ubotu> New bug: #201362 in bzr-svn (universe) "Bzr-svn cannot be loaded " [Undecided,New] https://launchpad.net/bugs/201362
<rlubert1> awilkins: "bzr init-repo --no-trees sftp://centralhost/srv/bzr/X-repo/ "  that is even better...as clearly mentioned on the doc page...... /me
<plex1> how do I create a branch and check it out of an old revision?
<LeoNerd> bzr branch -r 10 path/to/parent
<plex1> what is path to parent?
<LeoNerd> Well, wherever the parent.. the thing you are branchingh
<plex1> I'm branching my local copy
<plex1> do I need to create a new dir in bzr to do this?
<LeoNerd> Well it'll need to be stored somewhere new
<plex1> wow
<plex1> ok
<LeoNerd> cd .. ;  bzr branch -r 10 whereIjustwas
<LeoNerd> Or   bzr branch -r 10 . ../some-new-branchname-here
<LeoNerd> Or other variations on the same theme
<plex1> got it
<Odd_Bloke> Moin.
<speakman> When I'd like to start over with "bzr init", can I just rm -rf .bzr to remove any old bazaar traces from a project?
<speakman> Or how do I else remove bzr out of a project?
<Odd_Bloke> speakman: You can, yes.  However, 'mv .bzr .bak.bzr' might be better, to ensure you don't lose any data accidentally.
<speakman> idea; add an "uninstall" option to "bzr"; "bzr uninstall" which removes bazaar from the project. A more clean way than rm -rf .bzr.
<speakman> Odd_Bloke: ok thanks!
<speakman> (can I post this idea as a bug, or how do I post feature requests?)
<ubotu> New bug: #201399 in bzr "bzr commit filename commits all files" [Undecided,New] https://launchpad.net/bugs/201399
<nonamekiller> i have one question: can i install Bazaar on usb drive and then connect to server from different clients?
<nonamekiller> anybody?
<speakman> I'm not sure I udnerstand the question asked.
<nonamekiller> oh my dumn english :(
<nonamekiller> can i install bazaar on USB?
<speakman> I think that's more of a Python question
<speakman> you could check this site out: http://www.portablepython.com/
<nonamekiller> on the bazaar-vcs.org i read: "Bazaar: ... Embeddable. A key design feature of Bazaar is support from the ground up for pluggable storage formats..."
<nonamekiller> i want embed Bazaar into my application. Is it real?
<radix> nonamekiller: bzr is implemented mostly as a Python library, so especially if your application is written in Python, it's very easy to use it as a library.
<nonamekiller> radix: can i embed it in my java application?
<radix> nonamekiller: that's harder :) the easiest for *simple* embedding outside of the Python world is probably by spawning system commands to run bzr.
<radix> I don't know if bzrlib works in Jython, but if it does that could also be a possibility.
<awilkins> Jython is only compatible with python 2.2
<Peng> It would be possible to write Python programs that deal with bzrlib to provide an easier interface.
<Peng> It's pretty good with IronPython though!
<awilkins> Although I'm told it will be better after the Google Summer of Code
<awilkins> Peng: You are joking righ?
<Peng> awilkins: I don't think so.
<Peng> Also, didn't Sun just hire the main Jython devs?
<radix> awilkins: I'm pretty sure it's been updated beyond 2.2
<radix> awilkins: it might not be fully compliant with any later releases, but I know it's got some features from later releases.
<awilkins> Peng: I've tried reasonably seriously to get it to work in IronPython, the test suite wont run because there's no "subprocess" module
<awilkins> And that's just the first stumbler
<awilkins> Well, not wuite the first, I patched around the first
<radix> Peng: they hired some guys. maybe jython will get better
<Peng> Hum.
<awilkins> But IronPython introduces a whole bunch of issues, platform caps detection, missing modules, etc
<radix> I'm hoping some people will notice pypy-jvm and get that working :)
<Peng> I thought you or someone else said IronPython was pretty close.
<Peng> My mistake then.
<awilkins> IronPython can be cadged into loading bzrlib if you patch bzrlib
<awilkins> (this is the Lapha 8 build of 2.0)
<awilkins> 2.0 alpha 8 is much closer to python 2.4 / 2.5 than 1.1
<awilkins> I wish I had the time and motivation to take it further, but I don't ; the first thing you'd have to do is write a subprocess module ; either as a lib, or as a builtin for IronPython
<awilkins> The win32 implementation of subprocess in lib doesn't work because it needs mscvrt which isn't a builtin of IronPython
<awilkins> Although I suppose it might be easier to make a mscvrt module for IPY than a subprocess :-)
<awilkins> I had a look, but I've not had the time to get around the Scary Attribute Jungle that's in there
<nonamekiller> is there exist portable python?
<awilkins> I was told Jython is pretty close (by Guillermo Gonzales, I think)
<radix> nonamekiller: CPython runs on pretty much all the platforms anyone cares for.
<radix> (not counting mobile ones, but it's pretty good there too :)
<awilkins> There's also a USB distro of the Win32 CPython if that's what you mean
<nonamekiller> yes!
<nonamekiller> thx!
<awilkins> http://www.portablepython.com/
<radix> oh, is that what "portable" means these days?
<awilkins> You might have to write a quick batch file to open a command prompt with the right ENV variables set up (to make it less of a hassle typing t:\python25\python.exe t:\python25\scripts\bzr all the time)
<luks> the py2exe'd installer of bzr and setting BZR_HOME should work on an USB drive
<awilkins> True, but it's not as fabulously flexible
<awilkins> Although it's probably faster to load
<awilkins> Can you use plugins with that version?
<luks> sure
<awilkins> Apart from some of the GUI ones, according to the page
<luks> you can use even the GUI ones
<awilkins> Even ones that use GTK and things like win32com?
<luks> if you install them, then yes
<luks> but that applies also to bzr with standalone python, since they are not in stdlib anyway
<luks> there isn't really many differences between py2exe'd applications and standalone python
<awilkins> I've always just used the "Full Monty" (ahaha) because I knew I'd probably end up hacking the code anyway.
<ubotu> New bug: #201409 in bzr-loom "pulling a loom resets to last-recorded state" [Undecided,New] https://launchpad.net/bugs/201409
<p_masho> anyone who can help a newbie ?
<james_w> p_masho: sure, ask away.
<p_masho> have taken a snapshot of a repos.. have hacked two files and addes an image ..so
<p_masho> done > bzr add path/to/images/foo.png
<p_masho> but.. my patch file which I assume I get off bzr diff > patch.file has got all sorts of stuff
<Peng> p_masho: What do you have a patch for, and what stuff?
<awilkins> Anyone recommend a tool for drawing directed acyclic graphs for illustrating version control concepts?
<luks> visio :/
 * awilkins dry-retches
<luks> other than that, dot from graphviz
<awilkins> I have it, but I hate it because my *other* project is a Big Ball of VBA/VB6 Mud plugin for Visio
 * awilkins will probably use Visio *spit*
<fullermd> xfig!   :p
<ubotu> New bug: #201422 in bzr-gtk "'WorkingTree4' object has no attribute 'iter_changes'" [Undecided,New] https://launchpad.net/bugs/201422
<james_w> p_masho: can you explain what you mean by "all sorts of stuff" please.
<p_masho> james_w: its perl (spits)  so its the compiled files generated by make that turn up.. ;-(
<james_w> p_masho: ah, so you want to ignore them rather than version them I assume?
<james_w> what extension do they have?
<p_masho> .pl
<james_w> hmm, are they in a "build" directory or something?
<p_masho> what I want is an ignore
<schierbeck> phanatic: should i bump the required bzr version?
<p_masho> anyway I'm hacking away atmo to make it work the way I want it and will be back here later on how to create the patch file.. in all probability ;-)
<phanatic> schierbeck: yes, please. send a merge request to the list, and i'll approve it immediately (so you can merge it right now)
<phanatic> schierbeck: thank you :)
<schierbeck> phanatic: (1, 3), right?
<schierbeck> np :)
<phanatic> schierbeck: yep, jelmer mentioned that in his last mail, and that seems reasonable
<james_w> p_masho: if you do "bzr rm --keep build" if they are in a build directory, and then "bzr ignore build" you should get what you want.
<schierbeck> phanatic: okay, it's sent
<phanatic> schierbeck: wow, it's a 725K diff?
<schierbeck> yeah, it's the wrong bundle
<schierbeck> i'll send the right one now
<schierbeck> hehe :)
<phanatic> shall i let it through the mailing list, or just discard?
<schierbeck> 725K seems rather big for a one-line change...
<schierbeck> just discard
<schierbeck> okay, it's sent
<schierbeck> phanatic: did this one get through?
<LarstiQ> schierbeck: that's one big line ;)
<schierbeck> hehe
<schierbeck> committed!
<phanatic> __schierbeck__: great, thanks! :)
<jelmer> awilkins: Thanks for that test log
<awilkins> jelmer: You're welcome, wish I had more time to hack on it.
<jelmer> I'm not entirely sure what could be causing those errors though
<jelmer> it's good to see it's down to 32 errors
<awilkins> I might have a look on the train.
<awilkins> THe train is tedious enough without something to occupy the mind
<awilkins> And my laptop is too wimpy to run my current projects in any sensible timeframe
<awilkins> Just used shelve for the first time :-)
<awilkins> ... and I'm just about to use it again :-)
<awilkins> Gah, why does Eclipse have to be so ANNOYING about it's workspace file structure
<fox> hola
<jelmer> hey schierbeck
<fox> hola a todos en el sistema
<schierbeck> hi jelmer
<schierbeck> fox: hola mi compadre!
<schierbeck> or something like that :)
<fox> hello men
<fox> habla en espaÃ±ol
<fox> cmom esta todo en el sistema
<schierbeck> fox: tienes una pregunta?
<schierbeck> i really ought to brush up on my spanish skills...
<beuno> fog, este es un canal de habla inglesa, pero si tenes alguna pregunta especifica, podes contactarme por privado e intento ayudarte  :)
<beuno> argh!
<beuno> fox, ^
<beuno> fog, ignore me :D
<Odd_Bloke> fox is gone.
<beuno> ah, irssi is laggy today
<ubotu> New bug: #133029 in bzr-svn "Branching scheme documentation needs improvement" [Low,Won't fix] https://launchpad.net/bugs/133029
<mtaylor> hey guys - can I get some logical help on dealing with revision graphs?
<mtaylor> I'm working on a post push hook
<mtaylor> to which I get an old revision and a new revision
<mtaylor> I want to send a log of what's being pushed, which I can get from show_log(old_revision, new_revision) right?
<mtaylor> (ok, I need more params than that, but that's the idea)
<mtaylor> except when I do that, I get the old_revision included in the log
<mtaylor> so I want logically old_revision+1
<mtaylor> but I'm not sure how to get that
<mtaylor> other than starting at new_revision, walking down the graph until I get to old_revision and backing up one
<mtaylor> which seems ugly...
<mtaylor> am I missing something sensible here?
<james_w> mtaylor: I think that is right.
<james_w> mtaylor: I'm not positive there is a better way though.
<mtaylor> blast
<james_w> s/is/isn't/
<james_w> There's probably a function somewhere to get all the descendents of new_revision that are not old_revision or it's decendents.
<james_w> That is exactly what the log code does to work out the indents.
<james_w> merge_sort may be the way to get the information.
<james_w> sorry, I'm not familiar with the API to give you code though.
<Leonidas> I'm havin a problem with bzr being too verbose
<Leonidas> it enables the logger and logs messages into stdout.
<Leonidas> Is there a way to fix this?
<dato> there is -q
<Leonidas> dato: well, it is really not that easy
<Leonidas> context: when I use bzr its fine
<Leonidas> then someone else uses that checkout, he gets the logging, although he uses the same commands as I do
<Leonidas> it also complains about "No handlers could be found for logger "bzr""
<spiv> Sounds like a difference in installation, maybe?  Different version of bzr, different plugins, something like that?
<Leonidas> spiv: it is running on the same system
<Leonidas> when I 'su' into his account, I get the same useless logging
<mtaylor> james_w: yup. the walking the graph down worked.
<mtaylor> ugly as sin though
<mtaylor> def get_parent(old, cur, graph):
<mtaylor>     for new_rev in graph[cur]:
<mtaylor>         if new_rev == old:
<mtaylor>             return cur
<mtaylor>         else:
<mtaylor>             return get_parent(old, new_rev, graph)
<mtaylor> new_graph = self.branch.repository.get_revision_graph(self.new_revid)
<mtaylor> start_rev = get_parent(self.old_revid,self.new_revid,new_graph)
<mtaylor> did the trick
<james_w> mtaylor: does it do what you want when pushing a merge?
<spiv> Leonidas: does "which bzr" report the same bzr in both cases?  Does "bzr --no-plugins" fix teh problem?
<Leonidas> spiv: yes, both are the same and --no-plugins does not change anything
<stelu> hi, i want to put /etc under version control and i couldn't find any plugin for permissions. i am using "find" command to collect the permisions and ownerships (as a workaround)
<stelu> is there a more elegant solution to this?
<LeoNerd> bzr specifically doesn't look after permission bits, except the +x bit
<hmeland> stelu: I haven't tried using it myself, but I think         my $os_name
<Peng> etckeeper
<hmeland> http://david.hardeman.nu/software.php might solve it.
<hmeland> Does metakeeper have bzr support?
<hmeland> sorry, etckeeper?
<stelu> thank you. i will hava a look at it
<Peng> http://kitenet.net/~joey/code/etckeeper/
<Peng> It supports git and hg, but there's a bzr plugin, or something.
<Peng> I heard that bzr is missing one hook that etckeeper uses though.
<hmeland> Yup, see the release notes for 0.12.
<Peng> Hah, ok.
<Peng> I didn't click "these changes" cuz I assumed it would be a big changelog.
<hmeland> Me neither, I just read the second bullet point on the page you just linked to. :-)
<hmeland> ... and having now clicked the link, I understand your "Hah" exclamation. :-)
<james_w> Leonidas: I'm guessing but it might be that the user can't write to their .bzr.log
<jelmer> hmm, looks like a local import of Samba 4 with bzr-svn now goes at ~2 revs per second
<mtaylor> james_w: not sure... must go check.
<spiv> Leonidas: weird.  Something must be different, but I'm not sure what.
<Leonidas> spiv: my bet would be the permissions, since we share the same checkout
<Leonidas> (and it worked before)
<spiv> Leonidas: that seems like a weird thing to cause that behaviour, but I guess anything is possible.
<abentley> Permissions on ~/.bzr.log, perhaps?
<Leonidas> abentley: ah, good idea
<Leonidas> abentley: indeed. That solved it. Thanks a lot
<abentley> np
<Leonidas> abentley: maybe it would be good to include a meaningful error message in cas the logfile is not writeable?
<abentley> Leonidas: Absolutely.
<Leonidas> :)
<james_w> I think the problem comes from the logging.get_logger call succeeding but printing the warning and being broken.
<james_w> it looks like you can check manager.emittedNoHandlerWarning on the logger after any logging call (debug, warn etc.) to find out if this is the case.
<Leonidas> james_w: are you able to reproduce the problem?
<james_w> Leonidas: I haven't tried, I was just looking at the code.
<Leonidas> In case you need testers, I volunteer :)
<james_w> I'm not really sure what the fix would be.
<james_w> Would you like to file a bug about the issue?
<Leonidas> james_w: I'll try.
<Leonidas> hmm, I need to remember my lauchpad login :)
<siretart> bzr: ERROR: Repository KnitPackRepository('file:///srv/scratch/packages/bzr/repo/.bzr/repository/') is not compatible with repository KnitRepository('http://bzr.debian.org/pkg-bazaar/bzr-builddeb/trunk/.bzr/repository/')
<siretart> how to work around that?
<james_w> hi siretart
<siretart> hey james_w!
<james_w> siretart: pull from http://bazaar.launchpad.net/~james-w/bzr-builddeb/trunk instead
<james_w> how are you?
<siretart> oh, finally got my hand to do some bzr experimenting again :)
<siretart> how are you?
<siretart> are the bzr branches on alioth obsolete?
<james_w> siretart: they are a bit behind at the moment. I'm not sure what the best plan is.
<james_w> alioth was having issues one day, so I pushed to launchpad, and haven't pushed back for a while.
<siretart> hmm.. now I get this: ... is not compatible with repository RemoteRepository(bzr+ssh://siretart@bazaar.launchpad.net/%7Ejames-w/bzr-builddeb/trunk/.bzr/)
<james_w> I think having them under pkg-bazaar is useful.
<james_w> ah, that's not nice.
<siretart> perhaps we can make lp pull from alioth?
<james_w> yeah, that's probably the best solution.
<james_w> I don't know what is going on there, I don't think it should say RemoteRepository there.
<james_w> can you try http:// for a minute?
<siretart> if that doesn't work, we could install cronjobs to make alioth pull from lp via cronjobs
<siretart> bzr: ERROR: Repository KnitPackRepository('file:///srv/scratch/packages/bzr/repo/.bzr/repository/') is not compatible with repository KnitPackRepository('http://bazaar.launchpad.net/%7Ejames-w/bzr-builddeb/trunk/.bzr/repository/')
<siretart> I'm using bzr 1.0.0 atm
<james_w> now that's just plain silly isn't it, it's not compatible with something of the same type?
<siretart> yeah
 * LarstiQ wagers subtrees
<Peng> "bzr info" your local repo and the URL.
<Peng> Also, upgrade!
<siretart> steps to reproduce: bzr init-repo /tmp/foo-repo ; bzr get http://code.launchpad.net/~james-w/bzr-builddeb/trunk /tmp/foo-repo/trunk
<Peng> Heh, format of the remote branch is "unnamed".
<Peng> Yep, it's rich-root-pack.
<Peng> You need a rich-root-pack repo to use it.
<Peng> bzr init-repo --rich-root-pack.
<Peng> james_w: You should upgrade the branch format. It's Branch5, which is what, dirstate-tags?
<james_w> Peng: probably.
<lifeless> moin
<siretart> Peng: thanks! that was it!
<james_w> sorry siretart I don't know how I got rich-root-pack there.
<james_w> hi lifeless
<siretart> james_w: no problem. I'm currently rearranging my local repositories on my laptop
<siretart> james_w: Ran 256 tests in 28.106s
<siretart> FAILED (failures=8, known_failure_count=1)
<siretart> is that expected?
<james_w> ouch, can you pastebin the log please?
<siretart> this is running 'your' trunk branch on bzr 1.0.0
<siretart> james_w: http://siretart.tauware.de/tmp/selftest.log
<Leonidas> james_w: ok, wrote that report: https://bugs.launchpad.net/bzr/+bug/201580
<ubotu> Launchpad bug 201580 in bzr "Better error message on readonly log files" [Undecided,New]
<Leonidas> erm, exactly :)
<james_w> Leonidas: thanks.
<james_w> siretart: ah, it's picking up your ~/.bazaar/builddeb.conf
<james_w> siretart: so blackbox tests are failing, I need to come up with some way to avoid that.
<ubotu> New bug: #201580 in bzr "Better error message on readonly log files" [Undecided,New] https://launchpad.net/bugs/201580
<siretart> oh, yes, if I remove the orig-dir line, then it gives me this:
<siretart> OK (known_failures=1)
<poolie> lifeless: would you care to forward bug 181855 to cygwin?
<ubotu> Launchpad bug 181855 in bzr "cygwin bzr branch crashes with IOError: [Errno 0] Error" [Medium,Confirmed] https://launchpad.net/bugs/181855
<LarstiQ> poolie: is Bazaar going to participate in GSoC this year?
<barry_wark> [newbie on OS X] Hello, I'm just starting to work with bzr on OS X 10.5. I used the OS X installer to install bzr. When I try to create a branch from a launchpad project (ipython), using "bzr branch http://bazaar.launchpad.net/~ipython/ipython/ipython1-dev", I get an ipython1-dev folder that contains a .bzr folder, but no other contents. I was hoping to get some pointers from some gurus. I will send the output of "bzr branch http://bazaar.launchpad.net/~ipy
<james_w> barry_wark: try to run "bzr checkout ." in the ipython1-dev folder.
<barry_wark> james_w: the result of "bzr checkout ." (from within ipython1-dev) is "bzr: ERROR: File exists: u'/automount/Servers/rieke-server.physiol.washington.edu/Volumes/Data/Users/barry/Desktop/ipython1-dev/.bzr': [Errno 17] File exists: '/automount/Servers/rieke-server.physiol.washington.edu/Volumes/Data/Users/barry/Desktop/ipython1-dev/.bzr'
<barry_wark> "
<barry_wark> There's an error when I called "bzr branch http://bazaar.launchpad.net/~ipython/ipython/ipython1-dev" as well...
<barry_wark> bzr: ERROR: Could not acquire lock "[Errno 45] Operation not supported"
<barry_wark>   warn("lock on %r not released" % self.f)
<barry_wark> Exception exceptions.IOError: (45, 'Operation not supported') in <bound method _fcntl_WriteLock.__del__ of <bzrlib.lock._fcntl_WriteLock object at 0x1c3c3b0>> ignored
<barry_wark>   warn("file group %r was not explicitly unlocked" % self)
<barry_wark> (oops...sorry about all the new-lines)!
 * chadmiller pokes mtaylor.
<james_w> barry_wark: ah, ok, you haven't got the branch at all then.
<barry_wark> yup. sorry for the initial confusion.
<barry_wark> is it possible that OS X doesn't allow the type of file locking that bzr expects?
<lifeless> poolie: not really; lack of a bug tracker is one of the cygwin projects issues, last I looked
<chadmiller> Has anyone tried to download a fresh copy of the bazaar source code lately?  I wanted to avoid the "http" method, so I tried the "rsync" line listed at "Download", and I think it's broken.  "No repository present" on the result.
<james_w> barry_wark: are you on AFS?
<james_w> chadmiller: I haven't tried rsync
<barry_wark> james_w: AFS==Andrew File System? No. If you mean AFP (Apple File Sharing), yes I am.
<barry_wark> james_w: of course... we've run into AFP locking issues before. I will try a branch to a local file system and see if that works.
<james_w> barry_wark: yeah, sorry, AFP
<james_w> https://bugs.launchpad.net/bzr/+bug/114528
<ubotu> Launchpad bug 114528 in bzr "New working tree format broken on AFP network mounts (locking error)" [Undecided,New]
<poolie> LarstiQ: intend to
<barry_wark> james_w: yes, that's it. branching to a local volume works fine. thank you for the help! i'll add a comment to the ref'd bug.
<james_w> barry_wark: thanks. If you have any information about AFP and what sort of locking it supports it might be useful.
<barry_wark> james_w: I will try to dig up that information and get back to you.
<james_w> barry_wark: great, thanks.
<LarstiQ> poolie: when is the deadline for mentoring organizations to enlist?
<leo2007> how can one use bzr in a system that one has no root access?
<chadmiller> leo2007: You mean install?
<poolie> LarstiQ: apparently it has closed
<poolie> LarstiQ: are you interested as a student or mentor?
<LarstiQ> poolie: certainly not as a student, and I don't think mentor is wise atm
<LarstiQ> just general interest
<leo2007> chadmiller: if the repo has been set up in another server, is there a client that's easy to install?
<LarstiQ> poolie: if, however, there is a shortage of mentors, I'm somewhat experienced with pitfalls now
<poolie> tbh i could live without it; there is a fair overhead in dealing with them and it may be better to just do it ourselves directly
 * LarstiQ nods
 * LarstiQ also leans in that direction
<chadmiller> leo2007: You can use "mkdir $HOME/r; python install --prefix=$HOME/r" and set PYTHONPATH appropriately.
<leo2007> that seems quite complicated
<LarstiQ> leo2007: you can also run bzr from source.
<huslu> if i understand correctly, when i branch in shared repo, it checks if parent dir is a repo, but what if i have a directory structure that's higher than parent, ie not /repo/branch1, but /repo/subdir1/branch11
<huslu> is it possible to for a branch11 to use repo ?
<james_w> huslu: yes, that's what will happen.
<bob2> it will look all the way back to /
<huslu> hm, ok but what so from another view, don't put a any shared repo between / and branch if you don't wan't it to be in the shared repo?
<LarstiQ> huslu: correct
<chadmiller> leo2007: Well, you could crack the machine, get root, and install it properly.  Which would be less complicated?
<huslu> ah, thanks. good to know.
<mtaylor> chadmiller: boo
 * chadmiller fights mtaylor.
 * mtaylor stabs chadmiller in the face
<chadmiller> Oif!
 * LarstiQ blinks ath the unruly lot
<poolie> hello chadmiller mtaylor
<poolie> LarstiQ: also, we have many non-US contributors and the holidays don't perfectly line up
<chadmiller> leo2007: Sorry, earlier, I left out "setup.py", "python setup.py install ...."
<LarstiQ> poolie: or not at all for our southern hemisphere ones. So we're not participating then?
<LarstiQ> poolie: but instead offering promising students an alternative via Canonical?
<LarstiQ> the year round? :)
 * LarstiQ thinks it would be good to have Daniel work on PQM for instance
<chadmiller> I have a simple patch for bzr source.  Should I send it to the mailing list?
<mwhudson> yes
<mwhudson> use 'bzr send'
<mtaylor> poolie: hello
<mtaylor> chadmiller: ooh. what's your patch do?
<chadmiller> I'll CC you, mtaylor.
<mtaylor> neet.
<ubotu> New bug: #201613 in bzr-loom "pushing looms does not work properly" [Undecided,New] https://launchpad.net/bugs/201613
<mtaylor> does it solve world hunger?
<mtaylor> hehe
<schierbeck> hi boys
<james_w> jam: stupid me, I never call the recursive function.
<james_w> told you it was untested :)
<mwhudson> hm
<mwhudson> what is 'bzr grep'
<mwhudson> ?
<james_w> mwhudson: it's a plugin that will grep your branch files.
<mwhudson> oh
<james_w> I don't know if it works on revision trees or just working trees.
<mwhudson> i use bzr ls --versioned --null | xargs -0 grep ... for that
<james_w> yeah, I think that is pretty much what the plugin is at this point.
<mwhudson> k
 * Peng notes that hg's grep plugin has a real implementation.
<Peng> OTOH, it's slow and uses tons of RAM. :P
<james_w> jam: I've got a whole bunch of fixes queued up here. It now actually gets the answer right for at least one.
<schierbeck> hey guys -- has anyone looked at a bzr extension for gio?
<schierbeck> it would be cool to be able to use bzr:// url's in nautilus et al.
<poolie> schierbeck: someone talked about that last week, maybe jelmer?
#bzr 2008-03-13
<schierbeck> poolie: it would be extremely awesome, but i think it needs to wait until there are python bindings for gio
<schierbeck> sometimes i wish bzr had a shared library in c
<schierbeck> and perhaps a gobject wrapper
<LeoNerd> Reminds me.. I need to have a play with the Python CPAN module, see if I can use bzrlib from perl
<mtaylor> hey guys - what's the bottom of the revision graph look like?
<mtaylor> like, If I start from the top, getting the tuple of revisions attached to the top revision, and then walking down the tree from there, how do I know I've hit bottom.
<mtaylor> will a revid have an empty tuple?
 * mtaylor answered his own question
<mtaylor> it is, in fact, an empty tuple
<james_w> how do I get a list of versioned files that are not present on the disk?
<james_w> WorkingTree.list_files doesn't list missing ones.
<james_w> tree.changes_from doesn't list them in removed.
<james_w> perhaps I have to use the inventory and work out paths on my own.
<james_w> also, how do I get the root directory of a WorkingTree?
<lifeless> james_w: iter_changes
<lifeless> james_w: wt.abspath('.')
<james_w> thanks.
<james_w> I've got something with inventory, but wt.unversion([ids]) doesn't like it if you give it two ids, one for a directory, and one for a file in that directory.
<james_w> for path, ie in tree.inventory.iter_entries():
<james_w>     file_id = ie.file_id
<james_w>     if file_id == tree.get_root_id():
<james_w>         continue
<james_w>     relpath = tree.id2path(file_id)
<james_w> raises NoSuchId too much for my liking.
<Odd_Bloke> Morning.
<james_w> Morning Odd_Bloke
 * mwhudson thinks people are not sleeping at the approved times of the day!
 * Odd_Bloke has a project due in in around 12 hours.
<Odd_Bloke> Also, I woke up earlier than intended.
<thumper> Odd_Bloke: ooh, what type of project?
<Odd_Bloke> thumper: A stock trading game for Deutsche Bank.
<Odd_Bloke> As part of our "Group Software Development Project".
<thumper> Odd_Bloke: and the rest of your group are working too?
<Odd_Bloke> thumper: Well, I didn't want to do it in Java, so we're using Django.
<Odd_Bloke> Which means that I'm doing the majority of the coding.
<Odd_Bloke> But they get to mess around with all the templating stuff.
<thumper> Odd_Bloke: sounds like you're doing the majority of the work
<Odd_Bloke> thumper: I'm doing the majority of the coding, they're doing the final report.
<Odd_Bloke> So the work load is probably fairly even, but the work I'm doing doesn't become entirely useless to me in around 13 hours. :p
<chadmiller> How does one deprecate a function in bzr src?  I see the decorator and version id.  Is that the current version?
<chadmiller> The to-be-released next version, that is?
<Odd_Bloke> chadmiller: The release in which it was deprecated (which is normally the to-be-released version).
<chadmiller> Thanks.
<bob2> HACKING.txt has some details about it (but not that specific answer)
<james_w> chadmiller: @deprecated_function(one_four) is probably what you want.
<chadmiller> Ah.  Are we too close to one_three, then?
<chadmiller> Guess I'll have to add one_four.
<james_w> oh yeah, it's not frozen yet is it? one_three is probably better then.
<james_w> unless it's going to take a little while, and you will end up having to go with one_four anyway.
<chadmiller> Nope.  This is a simple patch.
<bob2> lifeless: will shallow branches save network traffic, ram and diskspace when branch'ing?
<jml> bob2: not sure about memory, but for network traffic and storage, compared to standalone branches the answer is yes.
<jml> bob2: not sure about branches in a shared repository though.
<bob2> yay
<bob2> trying to branch emacs has taken all my linode's memory for half an hour
<jml> ahh :)
<jml> are you branching directly from a remote server?
<bob2> yeah
<Odd_Bloke> bob2: If you check out the webpage, there is a ready-made repository tarball you can grab.
<Odd_Bloke> bob2: At http://bzr.notengoamigos.org/
<bob2> Odd_Bloke: I know, I wanted to see how annoying actually using bzr with it would be :)
<Odd_Bloke> bob2: How often are you expecting to be branching the full emacs history when developing on emacs? :p
<bob2> hah, more wondering how much complaining emacs developers are about to start doing
<nxvl> Shi
<nxvl> i'm looking for a getting started web
<nxvl> or some development documentation to start
<Odd_Bloke> bob2: As rms has said bzr is the way to go, I'm sure they'll get over it. ;)
<bob2> haha
<Odd_Bloke> nxvl: http://doc.bazaar-vcs.org/latest/ has the latest bzr docs.
<bob2> nxvl: to start developing with bzr, or to start developing bzr itself?
<Peng> Apparently emacs went with bzr. Congrats. :)
<nxvl> bob2: bzr itself
<Odd_Bloke> nxvl: http://doc.bazaar-vcs.org/latest/en/developer-guide/HACKING.html is the main Developer Guide, which is worth having a look at.
<Odd_Bloke> nxvl: What sort of thing are you looking to do?
<Peng> http://lwn.net/Articles/273117/ / http://lwn.net/SubscriberLink/272853/835e7363ca833e6a/
<nxvl> Odd_Bloke: i'm thinkinf on olive right now, but i will be more hapopy with the crypt and communication part
<bob2> ah, it's lwn day again
<bob2> oh no someone made a ssh lib for java called "jaramiko"
<Odd_Bloke> nxvl: Olive is part of the bzr-gtk plugin (https://edge.launchpad.net/bzr-gtk), and jelmer or phanatic (and perhaps beuno?) can probably help you out there.
<Odd_Bloke> nxvl: As to the other stuff, posting to the list with your interests might help you find something to work on (if there isn't already something specific you're thinking of).
<nxvl> Odd_Bloke: i will take a llok at the list, thank you!
<lifeless> bob2: they may reduce peak memory in some cases
<lifeless> bob2: definiately disk space
<lifeless> bob2: definately less network, though obviously if you do 'log' will will have to go to the net for more stuff
<LaserJock> hmm, anybody know what the status on bzr-svn is?
<LaserJock> jelmer said a while ago he'd have new packages up on the PPA but I haven't seen anything yet
<bob2> lifeless: awesome
<Odd_Bloke> LaserJock: He was finalising the release a couple of days ago, I think.
<Odd_Bloke> Though I can't really tell you any more than that. :)
<LaserJock> k
<fullermd> There were a pile of commits in my mailbox from him earlier...
<mlh> lifeless: what sort of state is config-manager in?  Would you recommend it or perhaps something else?
<mlh> your page mentions a python rewrite but no more details
<lifeless> mlh: 'working'
<lifeless> mlh: but nested trees are concptually better
<mlh> I was thinking of something for someone use svn to use instead of svn:external
<mlh> but ta
<ubotu> New bug: #201725 in olive "TypeError on close Olive-gtk" [Undecided,New] https://launchpad.net/bugs/201725
<ubotu> New bug: #201727 in bzr-gtk "gcommit fails when committing to sftp server" [Undecided,New] https://launchpad.net/bugs/201727
<ubotu> New bug: #201733 in bzr-gtk "Tags with underscore in viz" [Undecided,New] https://launchpad.net/bugs/201733
<awilkins> 201733
<awilkins> 201733#201733
<awilkins> 201733#201733#
<awilkins> #201733
<awilkins> Apologies
<fullermd> You missed #201733#201733
<awilkins> I was just trying to provoke ubotu
<lamont> awilkins: for that you want to say: bug 201733
<ubotu> Launchpad bug 201733 in bzr-gtk "Tags with underscore in viz" [Undecided,Confirmed] https://launchpad.net/bugs/201733
<awilkins> TA.
<awilkins> Why hasn't bzr got a "bzr copy" ? (I presume the revision model doesn't allow for files to have history trees, just linear revision history?)
<james_w> awilkins: it is desired to have that, but it is very tough to do with our current model
<lamont> awilkins: I expect that a merge would kinda force a tree, no?
<fullermd> Mostly a combination of nobody having time to get to it, and nobody being willing to fully define the semantics.
 * lamont searches for the equivalent of 'git branch -l' in bzr (list of the branches in the current tree)
<awilkins> git just intrinsically supports this kind of thing because it just versions whole trees, yes? So it would notice if you split a file up or joined two together?
<awilkins> lamont: I don't mean "branch revision tree" I mean "file revision tree"
<fullermd> That's one way of looking at it, I guess.  Another is "git doesn't track anything anyway, so tracking copies as well as anything else comes naturally"
<luks> awilkins: it would notice if you tell it to notice
 * awilkins still isn't comfy with git
<luks> but it's hard to do it "the bzr way", because bzr assigns a file-id to each file
<luks> and you can have two files with the same file-id
<fullermd> There's nothing conceptually difficult about referencing file splits/joins.  It's deciding what the implications of that are that bogs you down.
<awilkins> And the file doesn't have a "parentId"
<awilkins> ?
<luks> parent-id is it's parent directory
<luks> but there is no parent-id in on the history line
<luks> no 3d trees for bzr :)
<lamont> awilkins: ah, as in "bzr cp a b" to make file b a copy of file a?
<awilkins> Yes
<awilkins> Was just an abstract thought, I don't have a real use-case for it ATM
<lamont> and yeah, git does that automatically, since the id of a file is the sha1 of the file
<lamont> or some such
<luks> the id in git is it's name
<lamont> ok
<fullermd> A difficulty is that there are a lot of operations smashed together in that one umbrella.
<luks> sha1 is it's revision id
<fullermd> Splitting a file is one.  Merging isn't covered at all, but would need to be.  And then there's really-copying...
<awilkins> THe revision id of he file, or the tree?
<luks> well, in git it's called "object id" I think
<lamont> awilkins: the revision id of the object.  whatever "object" happens to be.
<awilkins> Ah. /me hasn't studied git
<lamont> (current head, patchset, etc)
<lamont> so did bzr ever grow the ability to have two branches in one .bzr tree, and switch between them?  or is it still "directory-per-branch, have a nice day?"
<awilkins> lamont: shelve is sort-of-there
<luks> it's more "directory-per-branch, have a wonderful day!"
<awilkins> Or you can keep a no-trees repo of branches and use a checkout, and switch that
<luks> in bzr is branch the primary object, unlike git where you work primarily with repositories
<lamont> ok
<lamont> that's going to be a fun paradigm shift to bounce back and forth across
<lamont> luks: about the time I quit using bzr last, there weren't repositories...
<james_w> lamont: yeah, switch and cbranch can approximate it.
<james_w> lamont: or bzr-loom can do it if your branches have a string total ordering.
<lamont> string total ordering?
<james_w> no, your branches are dependent on ones lower
<james_w> think quilt patch series.
<lamont> ok.  (quilt: how to implement a revision control system in the source package.  see also: dpatch)
<james_w> :-)
<lamont> also known as "my revision control system sucks for merging, so we're going to reimplement that to make it less painful"
<lamont> well, on one front, anyway
<lamont> the only other reason for using quilt or dpatch is because you don't want to make would-be contributors learn your VCS-of-choice
<lamont> could someone remind me what the bzr equivalent of 'gitk --all' is?  (or even without the --all...)
<james_w> there is not equivalent to all.
<james_w> --all sorry
<james_w> bzr viz is equivalent to gitk
<lamont> bzr: ERROR: unknown command "viz"
<lamont> what magic piece am I missing, I wonder
<james_w> apt-get install bzr-gtk
<awilkins> You need the gtk plugins
<lamont> bzr-gtk?
<james_w> provides gtk GUI for some things, e.g. viz - history viewing
<lamont> bzr, bzrtools, and bzr-gtk are all installed on the box...
<awilkins> It's "vis" nativelt, it was written by a Brit :-P
<awilkins> (but there is an alias for viz)
<fullermd> Actually, it's "visualize"...
<lamont> bzr: ERROR: unknown command "visualize"
<james_w> lamont: are you running bzr from source?
<awilkins> It's visualise
<luks> `bzr plugins`
<awilkins> not  visualize
<lamont> bzr plugins
<lamont> launchpad
<lamont>     Launchpad.net integration plugin for Bazaar.
<lamont> so obviously something b0rked between the bzr 1.2 and the bzr-gtk 0.93 versions I have...
<james_w> if you are not using the system bzr it won't pick up the system plugins.
<james_w> ah, you need to upgrade bzr-gtk then.
<lamont> that was what I was just thinking...
 * lamont refrains from commenting on the packaging decisions that lead to 5 packages that must all be upgraded together and are built from separate sources
<awilkins> Needs a meta-package that gathers them
<awilkins> apt does that, no?
<lamont> well, given that I have to backport bzr and bzrtools to dapper each release anyway, I'll just add bzr-gtk to the pile, for my happiness
<james_w> we can't do it yet as the bazaar package FTBFS
<lamont> ??
<awilkins> F**ks the basic file system?
<lamont> awilkins: fails to build from source
<james_w> bazaar is the baz package, we want to make it a transitional package for that, and a meta package for bzr, bzrtools, bzr-gtk, etc.
<lamont> james_w: and you mean source package: bazaar?  or some other package?
<james_w> but we can't as it FTBFS, the maintainer is pretty AWOL, and no-one with the skills to debug the failure is that bothered about doing so.
 * lamont notes that bzr-gtk 0.93.0-1 is the current version, sighs
<fullermd> I thought 0.93 worked fine with 1.2.
<lamont> fullermd: well, I do freely admit that I'm running my backport of 1.2, since I had to install that on a bit over 100 systems before it actually built on dapper.
<lamont> in the ppa, that is
<lamont> I'm not sure if the version in the ppa is the result of my patch making it back to someone, or if it's different work
<james_w> lamont: you can check ~/.bzr.log to see why the plugin didn't load.
<lamont> 0.104  encoding stdout as sys.stdout encoding 'UTF-8'
<lamont> 0.105  bzr arguments: [u'viz']
<lamont> 0.106  looking for plugins in /home/lamont/.bazaar/plugins
<lamont> 0.106  looking for plugins in /var/lib/python-support/python2.5/bzrlib/plugins
<lamont> 0.106  Plugin name __init__ already loaded
<lamont> 0.106  Plugin name __init__ already loaded
<lamont> 0.148  Traceback (most recent call last):
<lamont> that?
<lamont> ah.. it's looking in python-support
<lamont> now to figure out why that is
<lamont> beacuse it's a muppet.  that's why.  broken build for me.  yeah!
<lamont> (iz a gutsy build of round 1 of dapper building, which took 2 rounds to get right)
<lamont> thanks
 * lamont didn't know about .bzr.log
<fullermd> 'bzr version' shows a lot of that sort of info too.
<lamont> bzr viz love.
<lamont> thanks
<james_w> lamont: glad it works for you now.
<lamont> re: bazaar ftbfs... given that the answer to _ANY_ question about baz is 'switch to bzr', I expect that a package that hasn't changed in a year could be summarily executed...
<james_w> lamont: except that manoj doesn't want that.
<james_w> though he hasn't stepped forward to maintain the package.
<lamont> and bazaar-vcs.org delivers its own packaging, and could easily introduce an epoch and shoot the debian package in the head.
<lamont> that is, if the user is mixing bazaar-vcs.org and debian repos
<fullermd> Didn't tla absorb pretty much all of the baz changes by the last release?
 * lamont didn't care enough to ever look back at tla
<james_w> I don't know, I've never used either.
<lamont> when I unified all my packages (into git) the issue I had was that I couldn't find a sane way to migrate from baz to git.  and the cvs trees were kinda ugly (don't ask...) so in the end I just committed release tarballs into the git tree so as to have some history, and went from there.
<lamont> that was over a year ago, iirc.
<lamont> since then, I've been encouraged to use bzr...  so I do.
<lamont> OTOH, I don't see myself switching existing bases anytime soon..  at least not until I get a lot more comfortable with bzr
<fullermd> Yeah, switching acids is a lot easier.
<abentley> lamont: The bazaar package is kept around to provide a way of converting Arch/Baz archives to bzr.
<lamont> well, given that (1) I'm comfortable with git and (2) need to use it anyway (kernel stuff), the result is that I get to learn both.
<lamont> abentley: then it needs to get fixed...
<fullermd> Git seems pretty well positioned to turn into "you have to learn it, because something you care about is going to end up using it"
 * lamont plans to don his pedant hat and crusade for the FTBFS since gutsy(?) bazaar 1.4.2-5.3 binary to get removed from hardy+1 
<lamont> fullermd: that's a long winded way of saying it has a significant user base
<fullermd> My way sounds more erudite.
<lamont> mind you, your way is also the base reason for why bzr needs to be taught to interoperate (read and write) with git:// protocol
<lamont> so that users who like the bzr UI, but have encountered said git-using software, can continue to be happy
 * lamont test-builds bazaar in gutsy, just to see if it's ftbfs there, or if it's just finally b0rked in hardy
<fullermd> If that doesn't turn out to be self-defeating...
<lamont> abentley: and if bazaar is ftbfs in lenny, you can bet that it stands a fair chance of being dropped from lenny before release.
<lamont> yep.  ftbfs in gutsy
 * lamont throws it against the feisty wall
<abentley> The issue AIUI is that at least one of the libraries it requires has been received API-incompatible updates.
<lamont> fullermd: the alternative is to make sure that there's enough software in bzr to force the users to learn both.  In which case, the git crowd will write a git UI for bzr.
<james_w> the failure is in the testsuite, so it's not incompatible to the point of failing to compile.
<abentley> lamont: Please no
<lamont> abentley: please no which?
<abentley> No git-like UI for Bazaar.
<lamont> _I_ have no plans to write one
<lamont> if bzr repos ever get significant traction, you can bet that someone in the git community will, though
<abentley> Git has unaccoutably horrid UI.
<lamont> and it wouldn't be a "git-like UI"... it'd be git talking to a bzr repo, just like {git,bzr}-svn do today
<lamont> git has an unaccountably horrid UI that is loved and/or used by many.
<lamont> exposing the index to users has a big advantage for at least one use case that I regularly have
<fullermd> From what I understand of how git-svn works, that will lead to long flames about the bzr CLI startup time...
<lamont> specifically, when I want to require that I type in exactly which files I want in this commit, rather than accidentally committing things that I didn't mean to.
<luks> but how often do you need that and how often do you commit all files?
<lamont> it may be that the best stall tactic would be to implement a bzr repo interface that sits on top of a git repository and plumbing... dunno
<lamont> luks: the use case is specifically /etc, being kept in $VCS for revision history/blame, and multiple users making changes on the box simultaneously.
<lamont> I didn't say it was a common use case... it's one that _I_ regularly bump into
<luks> I personally think that's using the wrong tool for the job
<luks> but that's just me
<fullermd> I certainly don't take issue with the idea of a workflow involving pre-noting the files you want to be dealt with.  It's got any number of use-cases.
<lamont> wasn't my decision
<fullermd> But it being the _default_?  That's another matter....
<lamont> fullermd: then give me the option to do that in bzr..
<lamont> and the ability to set the default on a per-.bzr instance
<luks> I'd really hate if bzr had 'bzr edit', which people were suggesting on the ML, as the default
<fullermd> If I could get my magic wand recharged...
<igc> morning all
 * fullermd waves at igc.
<igc> hi fullermd
<fullermd> Waitaminute.  It's morning _here_.  What are YOU doing saying 'morning'?
<igc> I'm in sunny Chicago at pycon
<abentley> lamont: It would be pretty easy to add an --explicit-files parameter to commit, so that it would fail if no files were specified.  Would that satisfy your use case?
<lamont> abentley: can I make that be the default for some particular .bzr instance?
<lamont> branch/repo/checkout/whatever we call that
<lamont> that is, does .bzr have a file under it that is default args for various commands?
<abentley> No, you could default it using an alias, but that's global.
<abentley> allowing .bzr to specify command parameters would not be safe, because the branch author may not be you.
<lamont> abentley: and for most repos, I'd want to not require --explicit-files
<lamont> ~/.bazaar-defaults allowing me to specify it for a branch would work, I suppose...
<lamont> (or whatever file it wants to be..)
<lamont> that is, I as a user would like to be able to say "when I'm in this tree, require explicit files, everywhere else, don't"
<fullermd> Theoretically, such a thing could be set in locations.conf.  I'm not aware that the file format allows any sort of implicit nesting, though.
<abentley> The format does.
<abentley> Bazaar only looks for aliases in bazaar.conf, though.
<fullermd> Oh, it does?  I didn't know that...   I thought you only got the one level.
<lamont> so does this mean I should file a bug asking for --explicit-files and a way to specify default commit parameters in locations.conf?
<lamont> branch: could not determine source revision from directory: /build/lamont/bazaar-1.4.2/debian/build/baz/tests/workdir/test-1-workdir
<lamont> FTBFS in _FEISTY_.
<lamont> well... feisty + security
<lamont> actually, all the build-deps came from feisty
<james_w> lamont: you could file a bug asking for an explicit-files config option, that is more what you want I think.
<james_w> Unless you want to alias it for all branches.
<abentley> lamont: ideally, you would submit the idea to the mailing list.
 * lamont is seldom ideal.
<lamont> :-(
<lamont> that would involve finding the mailing list, which would take about 15 extra seconds
<abentley> lamont: It's not a bug, it's a feature request.  Bugs don't usually require much discussion.  Feature requests are ususally improved by them.
<lamont> true
 * lamont marks 201823 wishlist
<fullermd> Plus, abentley will hunt you down and drive a spear through you if you file feature requests as bugs   ;)
<Af1> I know you guys don't care much about advocacy, but if you want GNOME to not switch to Git, we're really going to need to find some core GTK and GNOME people to start publicly endorsing Bazaar real soon now, or it's going to be too late.
<awilkins> What are they in now, SVN?
<awilkins> I see that you mirror their repo on Launchpad
<ubotu> New bug: #201823 in bzr "please add an --explict-files config option" [Wishlist,New] https://launchpad.net/bugs/201823
 * awilkins hears abently polishing his stick
<awilkins> s/stick/spear/phallic-euphemism of choice/
<abentley> lamont: If you insist on using launchpad instead of participating in discussion, could you at least use blueprints, not bugs?
<lamont> abentley: I'll see what I can do.
<lamont> I
<AfC> awilkins: the import on Launchpad is unfortunately useless because you can't use bzr-svn with it to push changes back to the origin project.
<lamont> I'm working on overcoming a year plus of dealing with bzr pain by ignoring bzr...
<awilkins> AfC: Yes, that is a bummer ; maybe if there was a plugin that emitted SVN flavoured patches?
<fullermd> Heh.  "bzr made me cry, so I fixed it by using git for a while.  Now I'm much happier with bzr"    :>
<awilkins> AfC: If you attached some properties to it you might even get it to round-trip
<AfC> awilkins: the worst part is that there are already a lot of people using git-svn to do their work; with released bzr-svn taking ~ 1 week to pull GTK down it's really not viable for me to recommend it to people
<lamont> fullermd: it's more "bzr made me cry.  so I use git for development.  and now my job requires me to use bzr for at least some stuff."
<awilkins> AfC: Maybe it would be possible to adapt a svn-fast-export to emit a bzr-svn repo?
<lamont> "so now I drip tears on the floor in #bzr and the bug tracking system"
<AfC> And such comments have to be taken seriously. We cannot tell lamont here that his opinion is wrong. It's his opinion.
<fullermd> Pfft.  Don't be interruptin' my "random IRC commenting to avoid irritating code-shuffling work"'ing with the facts!
<lamont> AfC: sure you can
<AfC> awilkins: that would be awesome if it would work.
<AfC> fullermd: :) :)
<AfC> fullermd: I agree. Facts are overrated.
<lamont> fullermd: I think you mean "Stop introducing facts into the argument" :-)
<awilkins> AfC: I don't know of any reason why it shouldn't ... but I'm not the expert on bzr-svn.
<lamont> or has that argument morphed since Oxford, I wonder...
<AfC> awilkins: it's probably worth a try
 * AfC admits that he doesn't quite understand the difference between the previous generation of import tools and *fast*
<fullermd> YKYAANW: you read that, and your first thought is "Huh?  'o' and 'r' aren't valid hex digits..."
<awilkins> AfC: fast-import takes a sort of lingua-franca of version control from a stream ; the fast-export streams it out
<james_w> I think git-fast-import is fast because you can do it all in one lump, rather than the usual load of forking.
 * awilkins has a shufty at the features that bzr-fast-import tacked onto git-fast-import
<AfC> I would imagine that unless jelmer et al deliberately made bzr-svn compatible with the revisions created by bzr-fast-whaver, then it won't work
<AfC> by accident.
<james_w> there were then fast-export tools written to export the format, and bzr-fast-import written to allow bzr to use the stream format.
<AfC> I could be wrong
<awilkins> I don't know which bot dtermines the revids
<james_w> I don't know enough about bzr-svn to say, but I think you may need more metadata in the stream to do it right.
<james_w> but the question is would that be any faster than bzr-svn?
<awilkins> If the export end determines revid you could "season" an existing svn-fast-export to emit it
<AfC> james_w: if you can't use bzr-svn to return changes back to upstream, then bzr-fast-import won't work.
<AfC> (in the case of the requirement I am articulating)
<AfC> (as I noted yesterday, I probably could have picked an easier case than 19,000 revisions of GTK, but hey, I'm at a GTK hackfest :))
<awilkins> I agree with his use case in a more general sense ; round-tripping with SVN is something that will be a major driver for adoption of any new VCS
<james_w> AfC: I agree, but I'm saying that I'm not sure if there is a reason that fast-import should be any faster than bzr-svn.
<awilkins> Since server infrastructure is often under the control of people who don't care or understand
<AfC> awilkins: well, if we can't get it right in the next 2 weeks or so we will lose GNOME
<awilkins> james_w: I can think of at least one reason
<awilkins> james_w: One thing bzr-svn is use one write-group for each revision
<AfC> Anyone know if jelmer did his next bzr-svn release yet? I know that spiv and jelmer did some great improvements in London
<lamont> the initial import from svn into $VCS doesn't need to be particularly fast, if I can do something in $VCS to fetch anything new, and can push my commits back to the svn server as svn commits
<awilkins> It means the repo is repacked after every revision ; it's good in the "live use" case beacuse it means you can resume a broken pull
<james_w> AfC: I haven't seen it, I checked bazaar-announce earlier today.
<awilkins> But it really slows it down for the "big pull"
<awilkins> There are two ways it could improve markedly ; one, shallow history, two, much faster initial import
<AfC> james_w: (I think it turns out that if shallow branches had existed a while back, and if bzr-svn was able to use them, then we'd be sorted; to use bzr to work with [in this case svn based] GTK I only need the ability to get most recent revision or so)
<awilkins> I agree, I seldom care about much beyond the last few tens of revisions (if that)
<awilkins> AfC: There's a 0.4.8 release on the stove for 1.2
<AfC> stove?
<awilkins> Just a mannerism
<AfC> I know what it means. I just don't know whether you mean that it is released or not\
<awilkins> Well, it's not linked but you can pull from the branch
<awilkins> Tell a lie, the branch is on launchpad now
<kiko> hey
<awilkins> AFAIK spiv/jelmer didn't change the one-write-group-per-revision thing though
<kiko> how do I back out a merged revision?
<AfC> Everytime I ask around here if it is safe to use bzr-svn from VCS the answer I get is "no"; admittedly if he is in the mode of doing a release instantaneously then it cannot be but safe.
<kiko> do I just generate the reverse diff
<kiko> or is there something saner?
<awilkins> kiko: You can do an uncommit
<awilkins> bzr uncommit
<AfC> `bzr uncommit`
<AfC> *unless*
<awilkins> You'll be left with the merge diffs in your tree
<AfC> the revision has propagated,
<AfC> in which case yes, you will have to commit a reverse
<kiko> awilkins, AfC: other stuff has landed after that, though :-(
<kiko> I only want to back out that merge.
<luks> bzr merge -r X..X-1
<AfC> kiko: little choice then. Just create a reverse diff.
<AfC> kiko: what luks said :)
<kiko> ok, cool.
<AfC> kiko: use `bzr diff -r n..n-1` will help you make sure you have what you want
<awilkins> AfC: AFAIK the 0.4.8 branch is stable
<awilkins> AfC: It's been tagged, it's a release
<AfC> awilkins: fair enough.
<AfC> awilkins: thanks for the heads up. Will attempt to pull.
<AfC> ^$#!#@ damn it.
<AfC>  $ bzr branch http://bazaar.launchpad.net/~jelmer/bzr-svn/trunk bzr-svn
<AfC> bzr: ERROR: Repository KnitPackRepository('file:///home/andrew/vcs/launchpad/.bzr/repository/') is not compatible with repository KnitRepository('http://bazaar.launchpad.net/%7Ejelmer/bzr-svn/trunk/.bzr/repository/')
<AfC> Why is Jelmer's repo not packs?
<AfC> and more to the point, why doesn't this just work?
<awilkins> < AfC> Why is Jelmer's repo not packs?
<jelmer> hey folks
 * awilkins waves
<AfC> jelmer: strange thing,
<jelmer> awilkins: One sec, I'll upgrade it
<AfC> I tried to grab your bzr-svn branch, and
<AfC> bzr: ERROR: Repository KnitPackRepository('file:///home/andrew/vcs/launchpad/.bzr/repository/') is not compatible with repository KnitRepository('http://bazaar.launchpad.net/%7Ejelmer/bzr-svn/trunk/.bzr/repository/')
<AfC> Mostly, I'm surprised that this was an error at all. I thought we capable of interoperating and all
<jelmer> AfC: Right, my bzr-svn branch uses a subtree format
<abentley> AfC, diffs are not the only solution.  A reverse merge will do the trick.
<AfC> abentley: right
<awilkins> We were also discussing the possibility of svn-fast-export | bzr-fast-import , whether it would/could be compatible with bzr-svn and whether it would be faster than bzr branch svn+http://
<AfC> abentley: that's what luks said
<AfC> abentley: a very nice feature on Bazaar's part.
<jelmer> awilkins: That's a lot harder than it sounds. fast-export doesn't provide the right information
<abentley> You're welcome :-)
<jelmer> I discussed this a little bit with igc at the sprint
<awilkins> jelmer: But presumably you could take an existing svn-fast-export implementaion and hack it, or decorate it?
<awilkins> Or is fast-import protocol not rich enough?
<jelmer> awilkins: Yes, but there's no reason why that would be any faster than bzr-svn itself could potentially be
<jelmer> awilkins: The fast-import protocol is not rich enough
<AfC> jelmer: Three days later I'm still only 45% through branching GTK with bzr-svn. I'm very much looking forward to trying 0.4.8
<awilkins> AfC wants GNOME and GTK to have an epiphany about bzr
<AfC> jelmer: I remarked earlier that I think that if shallow branches had existed a while back, and if bzr-svn was able to use them, then we'd be sorted. But that's not the case, so {shrug} we deal with what we have.
<AfC> awilkins: well, it's worse than that. If we do not actively convert some key people Real Soon Now, we will lose out to Git.
<kostja_osipov> statik: I sent a note on the bug report
<luks> AfC: is that a bad thing is they prefer to use git?
<AfC> Too many people are already using git-svn to talk to svn.gnome.org. There won't be a central decision, but it's happening on inertia.
<luks> *if
<statik> hi kostja_osipov! great, thank you
 * awilkins just wants a VCS that tracks merges and has a good Eclipse plugin and works well on Windows
<luks> svn 1.5!!!
 * luks hides
<AfC> luks: {shrug} if you believe that Bazaar is a better tool, then yes. I certainly don't want to use Git ever again for anything, so the fact that most of the people around me today are talking about Git (and making me cringe for how crazy it is)
<luks> dunno, I personally couldn't care less what people use if it fits their needs
<kostja_osipov> statik: do you meet physically? would be nice to come over to a) get some training b) point out the missing features c) have no ambiguity as to whether there is or there is no speed problem
<awilkins> luks: I forgot to say "also tracks renames properly"
<luks> oh, then svn 1.5 is out :)
<awilkins> Besides, the Eclipse support will be AGES
<statik> kostja_osipov: in moscow? probably not, but I'm sure we can work something out in realtime. maybe even video conference
<awilkins> ATM I have rudimentary Eclipse and Java support through the client library in bzr-svn
<kostja_osipov> not in moscow, :)
<awilkins> ATM I have rudimentary Eclipse and Java support through the client library in bzr-eclipse
<abentley> luks: It is nice when people can work together instead of each doing their own thing.
<AfC> It was a pleasure to work Verterok last week on the bzr-eclipse plugin. It's coming along really nicely.
<jelmer> AfC: Sorry, PCI hardware bug hang my laptop again
<abentley> And it can hurt cooperation if people are using different tools that don't work well together.
<luks> abentley: people will always use different tools, though. no matter how hard you try
<lamont> git prior to 1.5 had an abysmal UI.  git 1.5 is at least usable.
<AfC> jelmer: that's ok. The network here is shit (and overloaded) too
<luks> and git is definitely not going away anytime soon
<jelmer> AfC, awilkins: Basically, the main thing that is making bzr-svn slow at the moment is the fact that it has to generate consistent deterministic revision and file ids
<awilkins> jelmer: What's the algorithm for that?
<AfC> jelmer: understood
<lamont> luks: and given that, making tools interoperate is a good goal.
<luks> sure
<jelmer> awilkins: It's described by the mapping.txt file in bzr-svn
<AfC> jelmer: [please don't forget to fix your repo if you get a chance... I would like to pull your code if I can]
<awilkins> jelmer: Is it one of those things that might benefit from a pure C module?
<awilkins> Not that my C is any good :-)
<jelmer> awilkins: I think we can gain a lot simply by improving the logic behind the current Python code
<awilkins> Is it all in mapping.py?
<jelmer> awilkins: I've started factoring out the mapping code so this is easier to do
<jelmer> awilkins: Yes, mostly
<jelmer> I'm looking into using pyrex for the python bindings for subversion btw
<jelmer> it's much easier than I thought, and I regret not having looked into this earlier
<awilkins> Would that fix memory leaks much?
<awilkins> Would it avoid SWIG :-)
<jelmer> yes, both :-)
 * awilkins applauds
<fullermd> AfC: It can't be 'fixed' so you can pull it into that repo...  you'd have to put it standalone somewhere.
<awilkins> AfC: Pull it somewhere outside of your big repo, then move the folder into the plugins folder
<awilkins> (an ignore-repo switch for bzr branch would be useful here)
<fullermd> You could probably do that via init'ing it with the -subtree format; I think that'll create a standalone in that place, since the repo isn't compatible.
<AfC> awilkins: yeah. It seems pretty whacked the way it is now.
<fullermd> (then pull'ing)
<AfC> fullermd: interesting
<fullermd> (I haven't tried, of course, but It Stands To Reason(tm))
<AfC> yup
<james_w> that should work, yep
<awilkins> It seems to still keep it's revisions in the parent repo though
<jelmer> AfC: I've upgraded it to pack-0.92-subtree
<AfC> Um... there's no 0.4.8 tag in that branch.
<AfC> awilkins: where did you see such a tag?
<AfC> jelmer: sweet
<awilkins> AfC: In the 0.4.8 branch
<awilkins> http://people.samba.org/bzr/jelmer/bzr-svn/0.4.8/
<awilkins> (also on launchpad)
<awilkins> ls
<AfC> Ok. Unusual that trunk wouldn't contain that, but whatever.
<awilkins> 0.4.8 contains at least one cherrypick there...
<jelmer> AfC: 0.4.8 isn't released yet and is being stabilized
 * awilkins presumed the tag meant stable, sorry
<AfC> jelmer: ah. Others were saying otherwise. Thanks.
<awilkins> It still works well for me :-)
<awilkins> That reminds me, must have another try at converting my Big Fat Repo
<awilkins> It wouldn't be faster over file:// would it? It seems to be CPU limited whenever I try it
<jelmer> hmm, the pyrex stuff actually appears to be faster than the swig bindings, too
<dato> jelmer: these pyrex bindings would substitute the existing ones upstream?
<jelmer> dato: no, they'd be included with bzr-svn
<dato> ok
<awilkins> Are they API compatible with the existing ones?
<luks> not that surprising, swig generates quite awful bindings
<jelmer> dato: subversion generates bindings for a large range of languages and they have to maintain API compatibility
<Stavros> hell
<Stavros> hello, rather
<Stavros> can i merge multiple commits into one?
<awilkins> Are they at the tip of the branch?
<Stavros> it's a theoretical question at this stage, so let's assume both ways :P
<awilkins> If they are, you can uncommit them and then recommit the changes as a single revision
<Stavros> oh
<Stavros> isn't there a command to do that?
<Stavros> i'm guessing no
<awilkins> bzr uncommit
<Stavros> no, i mean merge them
<Stavros> anywhere in the history
<awilkins> No idea
<luks> bzr usually doesn't commands for automatic destroying of history :)
<Stavros> hmm, i thought there was one
<Stavros> maybe it's in git?
<luks> very likely
<Stavros> hmm
<fullermd> You can make a new rev containing those two revs in various ways.  But you'll have to recreate every rev after that point too, so you generally don't want to do that.
<awilkins> Is this "rebase" or some other abomination?
<Stavros> awilkins: no idea, i have never used git
<fullermd> I think it's a 'feature' of git's rebase.
<awilkins> Ah
<dato> yes; of git rebase --interactive, in particular.
<awilkins> You could { bzr branch tree newtree -r n-1 ; cd newtree ; bzr merge tree -r n-1..n+1 ; bzr commit ; bzr merge tree -r n+3 } ?
<Stavros> awilkins: true, but it's not worth it, i was just wondering if there was a command
<luks> Stavros: what's the use case for this?
<luks> I mean, in git people use it because they use almost-plain patches to send changes around
<Stavros> luks: committing not-quite-finished code so you can sync/run-test it, and then convert them all into one when done
<fullermd> I've occasionally speculated about a full "history rewriting language", where you can define a spec of how you want to mutate history, and hand that off to an interpreter that goes off and does it.
<fullermd> Interesting way to mentally occupy a couple hours.
<luks> Stavros: why not just normal merge?
<awilkins> Stavros: Do that sort of thing on a feature branch, and merge it when tested
<jelmer> fullermd: that's actually what git rebase -i does
<jelmer> to some degree
<Stavros> the "unclean" commits remain unclean, though
<fullermd> Well, only if you wrap expect around it or something   :p
<awilkins> Stavros: That way it becomes a single "merge" revision in the target branch (listing the full history from the merged branch)
<luks> Stavros: they are part of the history
<luks> maybe one year later you will wonder what it's done that way and those unclean commits will help you
<awilkins> Stavros: You'll have no unclean commit on the main line, just in the subhistory of the top revision
<luks> *why
<Stavros> aha
<fullermd> I don't think it can do all the mutations you'd want, either.
<Stavros> so it'll be one revision number?
<luks> one mainline revision, yes
<awilkins> Stavros: Yes, it's one revision number, with a list of branch revisions inside it's history
<Stavros> good, that should do then
<fullermd> Frex, the nuclear * problems.
<Stavros> it's just that my OCD flares up when I check in nonworking code
<awilkins> You must write a lot of unit tests :-)
<Stavros> i try :(
<jelmer> man, I really should've looked at pyrex earlier
<jelmer> almost done wrapping the core ra functions in just 2.5 hours
<Stavros> what's ra?
<jelmer> Stavros: Subversion Remote Access API
<Stavros> ah
<Stavros> can bzr push to subversion yet?
<jelmer> Stavros: Has been able to do so for more than a year
<Stavros> oh
<Stavros> why have i been using svn then? :(
<Stavros> are there any caveats?
<schierbeck> hi jelmer
 * awilkins is up for building/testing the pyrex bindings on win32
<jelmer> Stavros: Speed is the main thing at the moment
<jelmer> schierbeck: hey
<Stavros> ah, i don't mind
<jelmer> awilkins: cool
<Stavros> i have to do svn copy from time to time to copy revisions to the release folder, can i do that with bzr-svn?
<schierbeck> jelmer: i'm looking at fixing bug #93652 regarding lock handling ui
<ubotu> Launchpad bug 93652 in bzr-gtk "Lock handling" [Low,Confirmed] https://launchpad.net/bugs/93652
<schierbeck> you're talking about complaining if there's a write lock on the branch being viewed by the viz?
<awilkins> Stavros: I think you can push new branches into svn with bzr-svn (jelmer?)
<awilkins> Not tried that feature yet :-)
<jelmer> schierbeck: one sec
<jelmer> Stavros: yep
<Stavros> hmm
<Stavros> jelmer: how do i do it exactly, do you know?
<jelmer> Stavros: bzr svn-push
<Stavros> ah, thanks
<jelmer> schierbeck: Yep, that's about write locks
<jelmer> schierbeck: I think currently it writes an error message about the lock to the terminal
<schierbeck> jelmer: is there a way i can safely put a branch in a write-locked state?
<schierbeck> (for a longer duration)
<jelmer> schierbeck: Branch.open("foo").lock_write(); sleep(2000)
<schierbeck> okay
<Stavros> hmm, i installed the bzr-svn windows installer but it can't find either the svn plugin or the svn bindings
<awilkins> Stavros: What I do it install the plugin by branching it inside my %appdata%/bazaar/2.0/plugins folder and the binding by unpacking libsvn and svn folders into c:/python25/lib/site-packages
<Stavros> oh, that should work, thanks
<Stavros> don't i need patched bindings though?
<awilkins> Yes, get them from http://d5190871.u44.websitesource.net/bzr/
<schierbeck> jelmer: hmm, it doesn't seem that Branch.is_locked() and Repository.is_locked() do what i had thought
<jelmer> schierbeck: You may want to have a look at the implementation of the break-lock command in bzr core
<Stavros> awilkins: ah, that worked, thanks
<Stavros> getting "bzr: ERROR: Permission denied: ".": Can't get password" now
<Stavros> do i need bzr co or bzr branch?
<schierbeck> jelmer: yeah, probably
<jelmer> Stavros: non-ssh authentication doesn't work on Windows unless you have Subversion 1.5
<schierbeck> jelmer: for an initial implementation, with just a decent error message, couldn't i just catch LockNotHeld?
<jelmer> schierbeck: Not sure I understand what you mean - the bug is about hooking into the bzrlib code that errors about existing write locks
<awilkins> Stavros: Do something that needs auth (like grab a lock) using the svn client and cache your password
<schierbeck> yeah, but i'm trying to get an incremental understanding of this: a LockNotHeld exception is raised when trying to unlock a branch with a write lock on it
<awilkins> Stavros: And you want to bzr branch svn+http://
<Stavros> awilkins: it's svn://
<schierbeck> the sequence in which the viz operates is unlock lock_write unlock lock_read
<awilkins> Stavros: That should be fine
<schierbeck> i would expect an exception to be thrown when read-locking a write-locked branch, but nothing happens
<jelmer> schierbeck: Yes, and that shouldn't change. We should hook into the code in bzrlib that currently prints to the terminal
<awilkins> Stavros: You might want to init a rich-root-pack branch and pull into it, it's more recoverable if there is a problem (like memory issue which crop up on large repos)
<Stavros> aha, let me do that
<schierbeck> jelmer: hmm, okay
<Stavros> done, but there's still the auth issue to counter
<schierbeck> ideally, i could just check if there is a write-lock on the branch, and err out
<james_w> AfC: ask and you shall receive :) -> http://planet.bazaar-vcs.org/
<awilkins> Stavros: Do an svn lock svn://project/trunk/randomfile and svn will cache your password
<Stavros> awilkins: i did a commit to the server using tortoisesvn, do i need to do it in the folder i want to pull in?
<Stavros> oh, let me try with the client
<schierbeck> ahh, Branch.peek_lock_mode()
<awilkins> Unlock the file afterwards :-)
<Stavros> it was already cached, apparently
<Stavros> still nothing, though :/
<awilkins> Hmmph, I had some issues with this.
<AfC> james_w: oh, good show. Well done.
<Stavros> james_w: what was that in response to/
<james_w> Stavros: Myself and jam were having a discussion at the sprint, and AfC suggested that one of us write up the discussion to show the thought that goes in to the design decisions, and where some tradeoffs are made.
<james_w> Stavros: and also partly due to the last two links.
<Stavros> ah, thanks
<james_w> Anyone know if there is a good general algorithm to take a set of actions and their weight and pick the set of actions with the highest weight?
<james_w> where you can't just take them all I mean.
<james_w> or maybe not a general algorithm, but a set of principles or something?
<Stavros> awilkins: i have the bzr-server conversation if you want
<schierbeck> for the love of god, a little documentation in bzrlib would make my life a whole lot easier... Branch.get_physical_lock_status()
<james_w> or at least what the class of problem is called so that I can google for myself.
<Stavros> does anyone have an idea why i can't pull with svn-bzr? maybe i need the svn client in the PATH?
<james_w> Stavros: you shouldn't. What's the error message you get?
<Stavros> bzr: ERROR: Permission denied: ".": Can't get password
<Stavros> i sniffed the packets, if anyone speaks svn
<jelmer> Stavros: non-ssh authentication doesn't work on Windows unless you have Subversion 1.5
<james_w> Stavros: http://bazaar-vcs.org/BzrForeignBranches/Subversion/FAQ
<Stavros> o
<Stavros> i thought you meant for http
<james_w> Stavros: the second question might apply.
<Stavros> james_w: it probably does, let me get 1.5
<Stavros> any idea where the 1.5 binaries are? :/
<nir> How can I have a generated file that is not under version control, but bzr export will export it?
<nir> e.g version info file, used in a makefile to compile build number into a product
<james_w> Stavros: 1.5 isn't released yet :)
<Stavros> not even prerelease binaries?
<Stavros> you built me up just to tear me down, didn't you!
<james_w> Stavros: they might be available, I'm not sure.
<james_w> nir: I don't think that is possible.
<Stavros> james_w: can't find anything on the site, so i don't think so
<schierbeck> jelmer: okay, i've done some initial ui
<schierbeck> i'll work more on it later, got an appointment now
<schierbeck> adios!
<awilkins> Hey, someone with wiki admin rights unlock editing FortuneCookies, I want to put "bzr push does not update the remote tree!!!!!!" in it.
<nir> Looks like I need to edit the exported tar.gz
<awilkins> Stavros: You can find builds of 1.5, but I'm not sure about the 1.5 python bindings
<jelmer> Stavros: I doubt there are any available for Windows yet
<awilkins> http://merge-tracking.open.collab.net/servlets/ProjectProcess?tab=4
<awilkins> There are windows binaries there, but not the Python bindings (which need building AFAIK)
<Stavros> it's ok, i'll wait then :/
<awilkins> At the speed Jelmer is going, we could have spanky new pyrex bindings by the end of the day....
<james_w> nir: you can export to a directory.
<ubotu> New bug: #93652 in bzr-gtk "Lock handling" [Low,In progress] https://launchpad.net/bugs/93652
<statik> awilkins: you want the push_and_update plugin
<statik> it's very nice
<awilkins> statik: No, I don't have a need for it, but it has to be the most FAQ in here
<awilkins> Perhaps having it as a page cookie would increase awareness as a kind of background noise :-)
<luks> I don't think even having it on the homepage would :)
<fullermd> I wouldn't think it would.  I mean, bzr _tells_ you every time you push...
<awilkins> Maybe it should print it in flashing red.
<fullermd> Pop up a little speech balloon, with a trumpet flourish sound effect.
<awilkins> Add a switch --i-understand to bzr push that has to be used to make it work.....
<fullermd> "I, fullermd, by running this command, do assert and warrant that I am of sound mind and body, and have been apprised of and reviewed the document BZR-E-238634.7, entitled 'Push does not update remote working trees', and further affirm [...]"
<awilkins> Make the user sign the "allowed-to-use-push" file with a GPG key that corresponds to their current whoami.
<jelmer> any pyrex experts awake?
<jelmer> hmm, I guess that means no :-)
<fullermd> I think jam does, but he's doesn't seem to even be nominally here today...
<ubotu> New bug: #201934 in bzr-webserve "Inventory of files, get latest version" [Undecided,New] https://launchpad.net/bugs/201934
<ubotu> New bug: #201935 in bzr "Improve performance of bash completion (caching) (dup-of: 84822)" [Undecided,Invalid] https://launchpad.net/bugs/201935
<announcer> Rev 3272: (bialix) Significantly reducing execution time and network traffic bialix@ukr.net
<statik> poolie: ^ there you go
<mwhudson> hey, cool
<statik> mwhudson: until it blows up
<mwhudson> statik: ever the optimist
<mwhudson> the first line of that commit message is more exciting than the whole thing
<announcer> Rev 3272: (bialix) Significantly reducing execution time and network traffic bialix@ukr.net
<statik> ok, announcer, we know that one already
<statik> that one was my fault
<statik> it should be all set now.
<orospakr> http://blog.orebokech.com/2008/03/emacs-in-bzr-initial-impressions.html
<mwhudson> wow, revision-info could do with some common-case speeding up
<mwhudson> b.get_revision_id_to_revno_map() ?
<mwhudson> oh, and revision_history()
<ubotu> New bug: #201956 in bzr-gtk "Document bzr-gtk keybindings" [Undecided,New] https://launchpad.net/bugs/201956
<announcer> Rev 3273: (jam) Fix moving directories to root nodes. john@arbash
<announcer> Rev 3273: (jam) Fix moving directories to root nodes. john@arbash
<announcer> Rev 3273: (jam) Fix moving directories to root nodes. john@arbash
<mwhudson> announcer: shut it
<announcer> Rev 3273: (jam) Fix moving directories to root nodes. john@arbash
<jelmer> mwhudson: Do you have any idea who owns announcer ?
<mwhudson> jelmer: statik
<yacc> mwhudson: announcer has just a bad memory and has to repeat a number of times so he doesn't forget this gem of information ;)
 * jelmer wonders what the benefits of announcer over cia are
<yacc> jelmer: well, it's not torturing you by mistake ;)
<yacc> jelmer: I meant interogate firmly ;)
<jelmer> heh
<announcer> Rev 3273: (jam) Fix moving directories to root nodes. john@arbash
<jelmer> hmm, is this going to continue every 5 minutes?
<jelmer> s/continue/repeat/
<yacc> nor does it kidnap you and throw you in an unmarked plane to fly you to some idyllic tourismus hotspot
<yacc> jelmer: well, most IRC clients have support for ignoring ;)
<jelmer> statik: ping
<jelmer> statik: That's mainly useful for stuff you'd like to ignore but can still be interesting for other people
<jelmer> I don't think that's the case here
<jelmer> anybody with pyrex karma around?
<announcer> Rev 3273: (jam) Fix moving directories to root nodes. john@arbash
<mwhudson> jelmer: i think pyrex is bad for the soul, but i know a bit about it
<jelmer> mwhudson: If you think pyrex is bad for the soul, you should try swig ;-)
<jelmer> mwhudson: I'm trying to create a class from some pyrex code but need to set two C members in it
<mwhudson> jelmer: well yes, swig is worse
<mwhudson> i don't see what the problem is with just writing c, to be honest
<jelmer> and I can't figure out a way to do it. There's no way to create an __init__ that takes C pointers
<jelmer> mwhudson: Too much work
<mwhudson> oh, ok, that goes beyond my pyrex knowledge already
<jelmer> mwhudson: ah, ok
 * jelmer just redid most of the python subversion bindings in ~5 hours using pyrex
<jelmer> It's just this last bloody thing that's I can't seem to get right
<announcer> Rev 3273: (jam) Fix moving directories to root nodes. john@arbash
 * TFKyle stabs announcer
<mwhudson> where is igc
<mwhudson> he's sending email but not on irc?
<jelmer> yeah, same thing for John
<james_w> I think they are at/on the way to PyCon
<announcer> Rev 3273: (jam) Fix moving directories to root nodes. john@arbash
<mwhudson> ooh
<mwhudson> right
<mwhudson> bzr revision-history in the emacs import takes ~8 seconds :/
<dato> mwhudson: but not with your patch :-P
<dato> ah
<mwhudson> dato: no, i only did revision-info
<announcer> Rev 3273: (jam) Fix moving directories to root nodes. john@arbash
<dato> statik: is announcer yours?
<dato> statik: it's misbehaving
<announcer> Rev 3273: (jam) Fix moving directories to root nodes. john@arbash
<announcer> Rev 3273: (jam) Fix moving directories to root nodes. john@arbash
<announcer> Rev 3273: (jam) Fix moving directories to root nodes. john@arbash
<poolie> hello
<announcer> Rev 3273: (jam) Fix moving directories to root nodes. john@arbash
<mwhudson> hi poolie
<jelmer> hey Martin
<announcer> Rev 3273: (jam) Fix moving directories to root nodes. john@arbash
<announcer> Rev 3273: (jam) Fix moving directories to root nodes. john@arbash
<announcer> Rev 3273: (jam) Fix moving directories to root nodes. john@arbash
<announcer> Rev 3273: (jam) Fix moving directories to root nodes. john@arbash
<announcer> Rev 3273: (jam) Fix moving directories to root nodes. john@arbash
<schierbeck> hi jelmer
<announcer> Rev 3273: (jam) Fix moving directories to root nodes. john@arbash
<jelmer> hey Daniel
<schierbeck> jelmer: i'm playing a bit with launchpad edge, and i'm pretty impressed. do you think we at one point would be able to switch to using it to handle merge requests?
<jelmer> schierbeck: Can it deal with merge requests by email yet?
<schierbeck> i'm not sure, i'm playing around with a toy project to get a sense of the features
<schierbeck> if not, i'll add it to the lp bug tracker
<announcer> Rev 3273: (jam) Fix moving directories to root nodes. john@arbash
 * arjenAU hears an echo
<mwhudson> can someone kick announcer please?
<jelmer> poolie and lifeless are the only people with op rights
<jelmer> poolie: ping
<announcer> Rev 3273: (jam) Fix moving directories to root nodes. john@arbash
<jelmer_> crap, that's the 4th time today
<jelmer_> my PCI BUS is being crappy
<awilkins> That's one sick computer
<jelmer> yeah :-(
<awilkins> I remember sitting with a diagram of motherboard interrupt lines trying to work out which slot to stick my Audigy in
<awilkins> Creative cards really hate sharing interrupts
<announcer> Rev 3273: (jam) Fix moving directories to root nodes. john@arbash
<awilkins> Hmph, apparently, announcer does not respond to polite hints like "/msg announcer FUCK OFF"
<awilkins> jelmer: What's your bindings problem.... I'm not familiar with pyrex but I do have experience writing horrible P/Invoke calls from VB6 :-)
<jelmer> heh
<awilkins> Cheers, lifeless
<jelmer> lifeless: our hero
<lifeless> np
<lifeless> brb
<jelmer> awilkins: see my description a bit earlier
<jelmer> awilkins: I'm trying to pass C variables rather than python objects to a class constructor somehow
<awilkins> Callback?
<jelmer> no, not that
<announcer> Rev 3273: (jam) Fix moving directories to root nodes. john@arbash
<jelmer> argh
<announcer> Rev 3274: (Neil Martinsen-Burrell) Explain version-info --custom in the User ian.clatworthy@canonical.com
<awilkins> Seems to be unstuck, at least
<jelmer> I don't think so. That's the revision that was just merged by pqm
<jelmer> it's probably just announcing the tip of bzr.dev constatntly
<awilkins> It was stuck on 3273 before
<awilkins> Seems to be 5 minute intervals
<awilkins> jelmer: Would extension types solve your problem?
<jelmer> awilkins: not sure what you mean?
<awilkins> "wrap arbitrary C data structures and provide a Python-like interface to them"
<jelmer> it's a very pyrex-specific problem
<awilkins> What's the constructor you're trying to call?
<jelmer> I can't create a constructor with c types as arguments
<announcer> Rev 3273: (jam) Fix moving directories to root nodes. john@arbash
<announcer> Rev 3274: (Neil Martinsen-Burrell) Explain version-info --custom in the User ian.clatworthy@canonical.com
<awilkins> jelmer: So have a constructor with extension types as arguments and define extension types to pass to it
<awilkins> http://www.cosc.canterbury.ac.nz/greg.ewing/python/Pyrex/version/Doc/Manual/extension_types.html  ?
<announcer> Rev 3273: (jam) Fix moving directories to root nodes. john@arbash
<announcer> Rev 3274: (Neil Martinsen-Burrell) Explain version-info --custom in the User ian.clatworthy@canonical.com
#bzr 2008-03-14
<awilkins> lifeless: CAn you BAN announcer? Pretty please?
<announcer> Rev 3273: (jam) Fix moving directories to root nodes. john@arbash
<announcer> Rev 3274: (Neil Martinsen-Burrell) Explain version-info --custom in the User ian.clatworthy@canonical.com
<lifeless> its saying channel not synced
<lifeless> when I try to ban
 * awilkins is not familiar enough with IRC to know what this means
<lifeless> neither am I
<lifeless> I am hoping someone else where will be ;)
<elmo> lifeless: op me
<frsk> It's because there's a netsplit going on, I think
 * awilkins has a cunning plan.... /ignore announcer
<lifeless> elmo: what was the issue ?
<elmo> lifeless: no idea; it was a WAG that it'd work for me
<elmo> I'm spethial ;-)
<lifeless> heh. thanks
<announcer> Rev 3273: (jam) Fix moving directories to root nodes. john@arbash
<announcer> Rev 3274: (Neil Martinsen-Burrell) Explain version-info --custom in the User ian.clatworthy@canonical.com
<lifeless> elmo: it would be nice if it had worked for you :)
<mwhudson> i knew the ban syntax was funky, but that's really strange
<jelmer> awilkins: I don't see anything there about allowing c variables as arguments to extension type constructors
<awilkins> jelmer: The bit that caught my eye was "So you can use extension types to wrap arbitrary C data structures and provide a Python-like interface to them."
<awilkins> I was thinking that meant you could pass a c-struct to a parameter that demanded an extension type based on that c-struct ?
<jelmer> awilkins: probably, but I'm trying to work out how :-)
<awilkins> What are the types?
<jelmer> not really relevant, but svn_ra_reporter2_t, apr_pool_t, void *
<awilkins> void *? One of the dreaded "batons"?
<jelmer> yup
<jelmer> that's not really relevant here though
<jelmer> I just need to pass pointers, no need for interpretation
<jelmer> by pyrex
<lifeless> anyone know who is running announcer?
<awilkins> Well, a pointer is a platform-sized integer
<lifeless> jelmer: you can't allow C ariables directly because extension types are constructable by python
<lifeless> jelmer: the constructor has to follow python ABI, which means getting python objects and unpacking appropriately
<jelmer> lifeless: statik is running announcer apparently
<awilkins> jelmer: Is this relevant? http://www.obviousobscurity.org/?page_id=13
<jelmer> lifeless: Ah, crap
<lifeless> statik: ping
<awilkins> Just under "Example 1" "wherever you can pass a void * you can pass a python object"
<lifeless> jelmer: care to give me a quick snapshot on your problem
<jelmer> lifeless: It's possible in SWIG, it just makes the class impossible to construct from python itself
<lifeless> jelmer: that means it has no constructor :)
<jelmer> it has a constructor, but no python users can ever construct the arguments to call that constructor properly :-)
<lifeless> jelmer: one way you could meaningfully do this is to have a no-args constructor, then a C initialisation interface
<lifeless> jelmer: swig has issues though ;)
<jelmer> lifeless: Basically, I have a pyrex function which calls out to a C function that returns 2 pointers
<jelmer> I would like to return a Python object from my pyrex function that uses those two pointers
<lifeless> lol searching for 'pyrex wrap' on google is not sfw
 * awilkins isn't at work *click*
<jelmer> :-)
<jelmer> lifeless: yeah, pyrex owns swig big time if you only need Python bindings
<jelmer> The next release of bzr-svn will likely no longer use python-subversion but its own pyrex code
<lifeless> jelmer: you can define __new__ with C args I think
<lifeless> http://ldots.org/pyrex-guide/5-python-wrapper.html#class
<lifeless> e.g. def __new__(self, reporter, pool)
<lifeless> oh hmm
<lifeless> no
<lifeless> jelmer: the easiest and cleanest way
<jelmer> it'll complain that it's not possible to use cdef for special methods
<lifeless> would be a trivial type wrap (e.g. an incomplete type definition)
<jelmer> and without cdef it's not possible to have c type arguments
<lifeless> what are the types of the two pointers
<jelmer> one is a typedeffed struct and the other is a void pointer
<lifeless> so
<lifeless> ctypedef typedeffedstruct
<lifeless> ctypedef ctypedef baton void *
<lifeless> cdef class foo:
<lifeless>     def __init__(self, struct, baton):
<lifeless>         self.struct = struct
<lifeless>         self.baton = baton
<lifeless>     cdef typedeffedstruct struct
<lifeless>     cdef baton baton
<lifeless> obviously reorder but roughly that should work I think
<jelmer> that breaks
<lifeless> pastebin it?
<jelmer> because it complains in the __init__ that struct is being converted from a Python object to a ctypedeffedstruct
<lifeless> thunk it
<lifeless> def __init__..
<jelmer> thunk it?
<lifeless>     cdef typedeffedstruct c_struct
<lifeless>     self.struct = c_struct
<lifeless> emr
<lifeless>         c_struct = passed_in_struct
<lifeless> totally unclear I know. 3 lines; a typed variable, assignment to that
<lifeless> then local assignment
<lifeless> if that doesn't work, give me a second
 * awilkins thinks 00:21 < jelmer> lifeless: Basically, I have a pyrex function which calls out to a C function that returns 2 pointers
<awilkins> 00:21 < jelmer> I would like to return a Python object from my pyrex function that uses those two pointers
<awilkins> oops
<awilkins> sorry
<jelmer> lifeless: nope, I don't seem to be able to fool it that way either :-(
<jml> jelmer: hi
<jelmer> jml: Hey
<awilkins> Did you look at http://www.obviousobscurity.org/?page_id=13 , because I thought that looked promising
<jml> jelmer: I was looking at your subunit patches: https://bugs.edge.launchpad.net/subunit/+bug/178362 and https://bugs.edge.launchpad.net/subunit/+bug/178361
<ubotu> Launchpad bug 178361 in subunit "[MERGE] Split by newline rather than by any whitespace character." [Low,Fix committed]
<jml> jelmer: but I couldn't find the actual patches.
<jelmer> I think I originally sent them to robert and later forwarded them to launchpad before it had support for attachments
<jelmer> I'll see if I still have them somewhere
<lifeless> jelmer: can you pastebin your experiment ?
<awilkins> Or just post a branch of it :-)
<lifeless> well
<lifeless> right now, fastest to pastebin ;)
<awilkins> I presume it's svn_ra_do_diff ?
<jml> jelmer: anyway, if you post them on LP, I'll try to review them
<awilkins> Poor jelmer, being pulled three ways
<jelmer> lifeless: The branch is at http://people.samba.org/bzr/jelmer/bzr-svn/pyrex
<lifeless> meh
<lifeless> ok
<jelmer> I'll see if I can trim it down to something that's easier to test and play with
<jelmer> jml: sure, I'll have a look
<jelmer> jml: Hmm, it's not possible yet to create a branch in launchpad yet using "bzr push lp:..." ?
<jelmer> ah, only if I specify a homedir explicitly
<awilkins> Yup, no squiggless
<jml> jelmer: huh what?
<jelmer> "bzr push lp:subunit/cparent" complains about "invalid series"
<jelmer> but "bzr push lp:~jelmer/subunit/cparent" works ok
<jml> oh
<jml> what would you rather it do?
<jelmer> Tell me new branches can only be created if I specify an explicit owner, perhaps
<jelmer> it's a minor thing though
<jelmer> I tend to only use launchpad for mirrorring my branches rather than hosting them
<milian> hey is it somehow possible to ignore a file which is under version control? let me explain why I need this:
<jml> jelmer: error messages are pretty important
<milian> whe have a website in bzr, a forum - its in its untouched status so everybody can install it
<milian> but the changes that occur by installing it dont neccessarily need to be submitted
<milian> thus I'd like to ignore some of those files - is this possible?
<lifeless> jelmer: please file a bug
<lifeless> jelmer: also, bzr register-branch --product subunit, now uses the public location so just-works
<jelmer> lifeless: yes, but this is really a minor thing compared to "bzr register-branch" which gives a traceback for pretty much everything
<jelmer> (branch already registered, invalid product, authentication, ..)
<awilkins> milian: bzr help ignore
<lifeless> jelmer: file bugs on all of those :)
<lifeless> jelmer: feedback -> improvements
<lifeless> awilkins: I don't htink that will do what milian wants
<lifeless> milian: you basically want a file which noone can edit
<awilkins> lifeless: I'm not sure what milian wants
<lifeless> milian: I don't see how you could edit it yourself subsequent to doing this
<lifeless> milian: what I suggest you do, is have the file called something like 'filename.example'
<jelmer> lifeless: I know :-) I've already filed bugs on some of them earlier
<lifeless> milian: then folk can copy it to filename, to get an unversioned local copy
<awilkins> milian: How about template files which you copy to "install" the thing?
<awilkins> milian: You could even write a small script that does the copying
<awilkins> Darn, lifeless got there first
<milian> hmmm complicated
<milian> but well, lets see what I can come up with
<milian> thank you guys
<lifeless> milian: or you could just 'bzr revert filename' after merging from someone to ignore any changes they made
<awilkins> The template idea coupled with an ignore list for the real config files has the advantage of not requiring constant vigilance
<milian> ah blast it - now I've accidently commited some files I dont want - how do I revert that commit without losing my changes? backing up my files and reverting?
<milian> I haven't pushed yet - so the commit should be local
<milian> or is bzr revert --forget-merges what I want?
<lifeless> bzr uncommit
<awilkins> bzr uncommit
<milian> oh darn - so simple :D great
<milian> thank you again
<poolie> hello again
<lifeless> poolie: hi
<lifeless> poolie: did you see leslies 'register now urgent urgent' mail ?
<lifeless> just checking my gmail now so just saw it
<lifeless> statik: ping, announcer banned, it wouldn't shutup
<poolie> lifeless: not yet, will look
<poolie> lifeless: i just saw that hardy went into beta freeze
<poolie> i would really like to get the baz rename done before it's too late
<poolie> was it beuno looking after it?
<lifeless> yes, was getting the patch up
<lifeless> some serious headache though
<lifeless> baz fails to build
<lifeless> api changes in libneon
<lifeless> poolie: oh, so unless you applied for bzr to be an organisation, we've missed soc.
<lifeless> I didn't put us in.
<poolie> i have not
<lifeless> right, that makes deciding on soc projects easy
<poolie> right
<poolie> tbh i don't think it gives a good return on the amount of time it requires, compared to helping people in the project directly
<poolie> we can sponsor people directly if they'd like to do similar things
<lifeless> I don't htink there is much soc specific overhead myself
<beuno> poolie, baz doesn't build in either lenny or feisty >
<lifeless> the questionaires etc are pretty quick to do
<beuno> so the work is done for the transition
<beuno> but since we can't get it to build, we can't upload
<poolie> beuno: so the old binary can stay in the archive? how is that allowed?
<poolie> lifeless: there's time in applying, dealing with student applications, reporting to them
<poolie> it's non-trivial
<beuno> poolie, it won't in Debian, and, in Ubuntu, it's been passed on in binary. I have _no_ idea how/why
<jelmer> jml: Still there?
<jml> jelmer: always
<beuno> it will get removed from Debian if it's not fixed, as it's a release critical bug
<jelmer> jml: The changes for those bugs are in the branches I just registed on launchpad
<jml> jelmer: ok.
<jelmer> jml: My trunk branch contains the SubunitTestRunner change
<jelmer> and the "jelmer" branch contains a bunch of other changes
<lifeless> poolie: there is, I'm comparing that time to the time to get contributions directly; we still have to decide whats good, work with folk contributing code, assess how they are going if we are doing a bounty
<lifeless> poolie: I don't think the /incremental/ overhead is significant
<lifeless> poolie: anyhow, its all moot
<poolie> it is moot
<poolie> approximately zero of the students last year committed long-term improvements
<poolie> that doesn't mean there's no prospect of doing better
<poolie> the main advantage i think is if it brings people in who would not previously have thought of working on it, and who do actually get right into it
<poolie> the potential is there...
<jelmer> phanatic got into bazaar through the SoC
<jelmer> Samba got one committer because of the SoC
<jelmer> I know wine has similar results
<jelmer> all 1 in 6 students actually staying around
<lifeless> poolie: I think we should do bounties for the folk that were interested from the sprint
<lifeless> poolie: if we can get funding for that
<poolie> that's true
<poolie> we can
<beuno> poolie, and you already have the topics to choose from organized in: http://bazaar-vcs.org/SprintLondonMarch08/Brainstorms   :)
<poolie> so we can fund jelmer, phanatik, guillermo,
<lifeless> cool
<beuno> so, poolie, lifeless, what do you want to do about baz?
<poolie> excuse my ignorance, but if it ftbfs how can it go into a new distribution release?
<beuno> well, I don't know how Ubuntu is doing it. They seem to just pass on the binary
<poolie> beuno: you're still in london?+
<beuno> Debian will remove it before relase
<beuno> poolie, no, Madrid. My flight was cheaper if I returned the 20th, so I'm waiting here until then
<poolie> beuno: i want to not have hardy release with 'install bazaar' not giving you baz
<poolie> i mean, bzr
<beuno> poolie, even at the expense of removing baz?
<beuno> neither me or james_w could get it to build in debian or ubuntu, so we can't upload the changed binary name for transitioning
<jelmer> is there any reasoning as to what options are retrieved using their own function on BranchConfig or using get_user_option() ?
<lifeless> http://weblog.latte.ca/blake/tech/bzr/Looms - nice :)
<lifeless> jelmer: get_user_option has a basic lookup
<lifeless> jelmer: custom methods are used for things that don't fit into that
<james_w> lifeless: nice.
<james_w> lifeless: also http://thread.gmane.org/gmane.comp.package-management.vcs-pkg/11
<jelmer> lifeless: thanks
<lifeless> james_w: great post'
<lifeless> james_w: now how about a patch to make merge actually merge the looms :)
<james_w> lifeless: erm, yeah...
<james_w> I might do some looms tomorrow.
<james_w> I've got my own little bzr sprint going on.
<james_w> Going to work is for people who never want to get anything done :)
<lifeless> james_w: :>
 * beuno points to http://blog.orebokech.com/2008/03/emacs-in-bzr-initial-impressions.html
<poolie> hello yacc
<yacc> poolie: hi.
<poolie> beuno: so it really looks like log in the main problem atm; mwh has a patch to speed it up for very long history
<mwhudson> (when he's not busy killing x)
<beuno> poolie, ah, cool. We should really make an effort to make sure "bzr is painfully slow" doesn't get stuck in people's heads
<poolie> indeed
<poolie> jml: could you followup about that, if you haven't done so already?
 * beuno is off to bed
<james_w> anyone know how to stop vim from forcing you to the first column when you type # to start a comment?
<poolie> james_w: hm, yes, somehow
<jelmer> poolie/lifeless: Any chance one of you could set "child_submit_to = bazaar@lists.canonical.com" in bzr.dev's .bzr/branch/branch.conf ?
 * poolie looks
<poolie> jelmer: i think only lifeless can write there
<poolie> james_w: i remember hitting that myself
<poolie> maybe 'filetype indent on' ?
<piedoggie> I screwed up a merge.  commit from one machine is the mainline is at rev 40.  changes from second are recorded as rev 38.1.1.  how do I merge rev 40 and 38.1.1 into a new revsion?
<poolie> or set nosmartindent nocindent, probably in an autocmd for python files
<poolie> piedoggie: are those numbers from the same branch?
<piedoggie> y
<poolie> hm
<poolie> actually, can you explain more? it sounds like you've already merged them
<poolie> you don't like the way you merged it?
<piedoggie> all the changes (38.1.1)  have not made it to head.
<poolie> because they conflicted and you rejected them?
<piedoggie> it is like I created a branch
<piedoggie> the changes should have been in conflict but I never got the merge message
<james_w> poolie: it seems like :set cindent might be it.
<poolie> rather nocin
<piedoggie> er.. conflict message
<poolie> piedoggie:
<lifeless> poolie: hmm, permissions
<poolie> possibly easiest is to do 'merge -c 38.1.1', which will redo all those changes, then you can pick what you want
<poolie> lifeless: ?
<poolie> on that branch
<piedoggie> k let me try that
<piedoggie> -c not -r?
<poolie> yes
<lifeless> poolie: rsync/bzr/bzr.dev$ chmod g+w .bzr/branch/*
<lifeless> poolie: you should be able to edit
<lifeless> poolie: sorry about wrong permissions
<poolie> if the changes you want are not in that particular revision, but rather something it merged, then you might need to pick out the particular one and use -c on that
<james_w> poolie: thanks for the pointers.
<poolie> you're welcome
<lifeless> *yawn*
<lifeless> 5am is the wrong time to wake
<piedoggie> how can I show all the diffs?  diff -c 38.1.1??
<poolie> yes
<lifeless> bbiab
<piedoggie> this may not be a good thing :-) but bzr works in a way that feels natural to my mind
<poolie> :)
 * yacc wonders if bzr is not a better client for svn repos than svn even now, ...
 * RAOF has found it to be so.
<RAOF> But that's because I don't use svn properly (ie: I try to do branch-merge, which is almost exactly half supported by svn :P)
<Potato-[CE]> i have a question: can i use bzr for multiple projects which are in multiple directories (not all under one obvious parent directory)?
<gotgenes> Potato-[CE]: Sure, you could but you have to examine whether there's advantage in keeping each project under the same repository.
<gotgenes> As long as you house all projects within some central directory, though, then yes, you can keep all of them in a single repository.
<Potato-[CE]> well, i think i need to start over with my directory layout. I have one project just started, i don't mind erasing the data...what's the best way to change the repository directory?
<Potato-[CE]> just delete .bzr?
<gotgenes> Potato-[CE]: That would do it.
<Potato-[CE]> okay, i see that here too "If you accidently put the wrong tree under version control, simply delete the .bzr directory."
<Potato-[CE]> thanks for the information, i appreciate it. :-)
<NfNitLoop> So I'm trying to check out a svn repo with bzr-svn, and I can't tell if it's in a loop or not.
<NfNitLoop> I've got the message:
<NfNitLoop> using experimental bzr-svn mappings; output may change between revisions
<jml> So, I think I've mentioned this before, but did you know that the ssh process started by Bazaar hangs around doing things if the Bazaar process is SIGINTed?
<NfNitLoop> and a progress bar keeps filling up.
<NfNitLoop> oops, nevermind, there it goes.
<NfNitLoop> I guess it just had tons of branches to check out.
<NfNitLoop> *heart* bzr-svn.
<jml> jam; ping
<ubotu> New bug: #202063 in bzr-gtk "gannotate display of uncommitted lines is unobvious" [Undecided,New] https://launchpad.net/bugs/202063
<jml> does Bazaar use Twisted Conch as its ssh client in Windows?
<lifeless> jml: not as far as I Know
<jml> lifeless: it's just that there's some things that say "Twisted" on the Bazaar / Launchpad showmedo video
<lifeless> interesting
<poolie> lifeless: hi, want a brief call?
<Peng> ubotu: ping?
<ubotu> Sorry, I don't know anything about ping? - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi
<Peng> Well, that's a good enough response.
<ubotu> New bug: #202079 in trac-bzr ""Invalid url supplied to transport" in sub directories" [Undecided,New] https://launchpad.net/bugs/202079
<RAOF> I've got some strange behaviour with Hardy's bzr:  I'm branching Do (with lp:do, so bzr+ssh), and when I do this into a directory which *isn't* a shared repository, "bzr info" in the branch directory gives Standalone tree (format: dirstate).
<RAOF> When I branch it into a directory under a default-format (pack-0.92) repository, and then run bzr info in the branch directory I get: Repository tree (format: unnamed)
<Peng_> Yeah.
<Peng_> The name like "pack-0.92" refers to the repository type, branch type, and working tree type.
<RAOF> When I branch it into a repository with rich-root format, the branch errors out with: http://www.paste2.org/p/15882
<Peng_> When you branch it into the repo, it's using pack-0.92's repo type but dirstate's branch type, so bzr doesn't know what to call it.
<RAOF> Right.  So that should probably be handled by printing both repo & branch type.
<Peng_> Indeed.
<Peng_> info -v will show all of them.
<RAOF> Ah, right.
<RAOF> Is there already a bug for this?
<Peng_> Shrug.
<Peng_> Wait, a bug about what?
<Peng_> That information or the error you pasted?
<RAOF> That information.
<Peng_> Oh.
<Peng_> Shrug.
<RAOF> Heh.  It's a small problem, but it'd be nice if it displayed both :)
<RAOF> Any ideas about the error?+
<RAOF> Eh
<Peng> I dunno.
<RAOF> Heh
<Peng> But, rich-roots and non-rich-roots don't really go together.
<Peng> Huh.
<Peng> I'm surprised you didn't get a compatibility error. Maybe bzr's smarter than that.
<awilkins> jml: plink appears to be the best choice for bzr+ssh:// on windows
<Peng> What's wrong with paramiko?
<awilkins> Had a chap in here a couple of days ago that couldn't get it to work, but plink worked fine for him
<awilkins> I suppose I could upload a key to LP and try both
<Peng> What problem was he having?
<Peng> Password prompt?
<awilkins> I thin it was dropping the stream in the middle of establishment
<awilkins> He was using an agent
 * awilkins uploads a key
<Peng> Oh, huh.
<awilkins> DId you buy your network card from the same guy that sold jelmer his :-)
<Peng_> Hahaha.
<Peng_> Actually, the Ethernet port on my 2-year-old motherboard failed, so I'm using my 5-year-old NIC...
<Peng_> But I'm tinkering with a new IRC client.
<awilkins> I'm quite happy with irssi running on my router atm.
<Peng_> Goodbye Konversation.
<fullermd> I'm due for another bout of screwing with irssi to try and resolve annoyances...
<Peng_> Heh.
<Peng_> I've used irssi a little, but I'll stick with my GUI clients..
<fullermd> The part where it (sometimes) eats part of wrapped lines is especially bothersome.
<awilkins> Running irssi on the router has the advantage that my office IT services can't block it.
<asabil> Peng_: weechat
<fullermd> The big problem with GUI clients is that they don't work well inside screen   :p
<Peng_> asabil: ?
<asabil> weechat is a quite nice client
<Peng_> Ah.
<Peng> Oh, non-GUI.
<asabil> still very usable
<Peng_> Connection reset by peer? What the hell? I hit the quit button!
<awilkins> Well that's a pile of crap then
<ubotu> New bug: #202083 in bzr "bzr info confusing when branch format does not match repository format" [Undecided,New] https://launchpad.net/bugs/202083
<awilkins> So once you upload an SSH key to launchpad, is there a way to test it's working without creating branches?
<Peng> If you have to create one, there's staging and junk.
<awilkins> Meh?
<Peng> Branches pushed to lp://staging/ or something are deleted daily. You can also register random branches to the +junk project.
<awilkins> Aha
<Peng> Wait, if you're using bzr+ssh, any operation would require a password or SSH key.. You could just "bzr info" something.
<awilkins> Mmkay
<awilkins> So, just replace the http with bzr+ssh ?
<Peng> Yeah.
<Peng> And add your username
<Peng> After running bzr launchpad-login, lp: URLs will automatically use bzr+ssh too.
<awilkins> so my username would be adrian-wilkins (that's what it says in my key edit window after the "~")
<awilkins> Ooh, doesn't work well from powershell
<awilkins> Ok, does the same thing from cmd.exe tooo
<awilkins> THe SSH stuff works with plink though.. now for paramiko
<awilkins> bzr: ERROR: Unrecognised value for BZR_SSH environment variable: paramiko
<awilkins> Dumb-ass question : do you need to install pycrypto and paramiko for python 2.5 on windows?
 * awilkins is finding it hard to locate a pycrypto binary for py2.5 on win32
<Peng> They're both still necessary with 2.5, but they're likely provided with the bzr installer.
<awilkins> THe standalone one or the python one?
 * awilkins is using the python one
<awilkins> Aha
 * awilkins intalls the damn dependencies
<Peng> http://bazaar-vcs.org/BzrWin32Installer#bzr-dependencies ?
<awilkins> Yeees
<Peng> That might not be the Python-based installer.
<Peng> I have no idea how it all works.
<awilkins> I've always used putty/plink
<awilkins> THe Python flavoured one has none of the extra deps in it
<Peng> Ah.
<awilkins> Paramiko seems to work better than plink
<awilkins> Plink gives you this "unable to read from standard input" error after it finishes
<awilkins> It's happy enough using Pageant for keys though (puttys ssh-agent)
<awilkins> Yay
<fullermd> Man, progress bars have gotten unprogressive with packs   :|
<awilkins> I always just _love_ seeing progress bars that clearly have no idea of how long things take :-|
<LeoNerd> Even better are the ones that go backwards
<awilkins> I'd much rather see a spinner, or an "estimate bar"
<awilkins> Maybe make the progress bar out of "?" instead of "="
<awilkins> Or "~"
<awilkins> "Approximate progress bar"
<fullermd> Don't even much see the spinner spinning; it spends so much time blocking in downloads that it's halfway done before it starts spinning.
<Odd_Bloke> Morning.
<Odd_Bloke> (And it actually is!)
<awilkins> Odd_Bloke: Afternoon
<awilkins> Gah, MinGW can't find files on other drives.... nice one, that should be at the top of the sodding install page for it
<awilkins> "Oh by the way, windows path support is fundamentally broken in"
 * awilkins rubs sore patch from beating head on wall
<luris> If you've uncommited and reverted, are the changes lost, or is there a trick to it?
<luris> :)
<awilkins> luris: revert will backup changes to ~1~ files
<Peng> luris: Also, the revision is still in the repo. You can find it if you wrote down the revid or with the "bzr heads" plugin.
 * awilkins didn't know that
<Peng> Not sure how you'd get it back into the branch though.. Maybe pull would do it?
<fullermd> It will.
<luris> Peng: pull like how?
<fullermd> pull -rwhatever .
<luris> bzr pull -r 1423?
<awilkins> bzr pull . -r revid:mytrashedrevid  ?
<luris> thanks :)
<statik> lifeless: sorry about that
<statik> everyone, sorry about the announcer malfunction yesterday
<statik> won't happen again
<fullermd> "Those responsible have been sacked."
<Peng> Announcer malfunction?
<fullermd> It wasn't a _malfunction_ per se...   it was just sorta "enthusiastic"...
<xif> does bzr have anything similar to SVN:externals?
<lamont> so... if I have a branch, and I want to make it an orphan (by forgetting all about it's parent), is it sufficient to just thwack .bzr/branch/branch.conf?
<fullermd> lamont: I guess so...   depends on what you're trying to accomplish by "orphaning" it.
<Peng> lamont: branch.conf includes the push location and other things too. I'd say edit it, don't just blindly delete it.
<lamont> fullermd: I'm trying to make the branch of the cvsps-import-created bzr tree forget that it had a former life as a cvs tree.
<lamont> Only in .bzr: checkout
<lamont> Only in .bzr: repository
<lamont> is the only diff other than the parent_location in branch.conf
<fullermd> Oh, you're out of luck on that.  Once you've been in CVS, you NEVER forget.
<lamont> ROTFL
<fullermd> It's like Vietnam for source code.
<lamont> Peng: this the new root-of-all-branches for the item in question
<lamont> fullermd: and RCS is what?  WW I?
<fullermd> I was thinking "Battle of Carthage".
<lamont> or the Korean Conflict, since that wasn't even worthy to be called a war
<lamont> so for the stupid question of the day (just to make sure I'm not a total idiot)... if I have a branch that I created with bzr branch $SOURCE, I bring it current with 'bzr up'?
<lamont> as in bzr preserves that bit of cvs insanity?
<Peng> lamont: Use "bzr pull". up is for checkouts.
<Peng> lamont: (pull automatically updates the working tree too.)
<lamont> ah.  which means I really want that to be a checkout - it's not a branch
<Peng> Meh.
<Peng> I always use branches even when I could really just use a checkout.
<Peng> That way I don't have to learn how checkouts work.
<lamont> (this is the "gimme a copy of _that_ branch so I can work on it locally and compile it" automatic processing thing)
<lamont> where "work on it locally" == "compile it"
<james_w> lamont: a lightweight checkout may be sufficient for you then, if all you want is the working tree.
<lamont> james_w: that is all I want.
<lamont> so yeah.
<lamont> thanks
<fullermd> Yeah, y'know, I was just thinking, "Gee, it's neat that some project is trying out bzr.  We should totally take that opportunity to rererehash a bunch of bzr-vs-git emails."
<Odd_Bloke> james_w: GJ on the Emacs thread BTW. :)
<james_w> Odd_Bloke: thanks.
<james_w> fullermd: me too. :)
<awilkins> Oh *spit*
<awilkins> Anyone know how to get "ld" to look in other folders on MinGW ?
<awilkins> (anyone who says "Add -L arguments" will be shot)
<LeoNerd> Is -R in that category also?
<fullermd> Hack the code?   :>
<awilkins> I'm trying to build things in Pyre
<awilkins> x
<awilkins> Nnnnnyuurg, this is horrible
<Odd_Bloke> Is there a test convenience function to create a branch that uses a shared repository if it finds one?  make_branch creates its own repo.
<chadmiller> Hi abentley.  I submitted a patch to the list under the wrong address, and then followed it with the same thing from the correct address.  The correct address' patch got one level of approval.  Then the list moderator approved the second posting, which 1) clobbered the prev status and 2) has the wrong address on it.  Can you roll the latest one back, or should I spam the list again?
<abentley> I think I can fix it.
<chadmiller> 'Kay.
<abentley> chadmiller: don
<abentley> done
<chadmiller> Thank you, sir.
<abentley> You're welcome.
 * awilkins is suffering PAIN
<awilkins> Getting the build kit for Python is a real pain unless you have an MSDN sub
<james_w> heh, I like the way gmane doesn't have emacs.devel under gmane.comp.editors, it's just gmane.emacs.devel
<awilkins> The group was probably founded before there were any other editors except vi
<awilkins> Or poking-the-motherboard-with-a-paperclip-wired-to-ground
<fullermd> I'm pretty sure emacs pre-dates vi...
<fullermd> (dunno if GNU-emacs does, but...)
<awilkins> emacs is clearly OUTMODED compared to vi :-P
 * awilkins raises shields
<fullermd> Well, vi is certainly enmoded, so...
<blueyed> Is there a shortcut to "bzr diff -r ancestor:FULLURL" (leaving FULLURL out and using the parent branch instead)?
<awilkins> blueyed: Since your branch contains all the revisions from the parnet branch, just determine the tip revision of the parent branch and diff against that
<awilkins> blueyed: Of course, to get the revno of the parent branch you need it's url :-(
<fullermd> ancestor: doesn't use the tip, it uses the ancestor...
<james_w> blueyed: does -r ancestor:submit: do it?
<blueyed> james_w: -r submit:..ancestor: does it. Thanks. didn't know about "submit:" yet.
<james_w> blueyed: I think it's quite new.
<james_w> blueyed: I don't really understand it yet, but it was worth a shot.
<blueyed> james_w: at least for my use case "-r submit:" is enough even.
 * awilkins requires tea
<ubotu> New bug: #202222 in bzr-loom "up-thread interacts poorly with remerge" [Undecided,New] https://launchpad.net/bugs/202222
<mxpxpod> is bzr-svn able to get subversion tags?
<jelmer> mxpxpod: it can fetch subversion tags as branches in bzr; it won't set bzr tags yet
<LeoNerd> There's no "easy" way to tell a subversion tag as a tag
<LeoNerd> In bzr, a tag is really a tag... it's a symbolic name for "just some point in history"...
<LeoNerd> (same as CVS)
<mxpxpod> I'm trying to check out openwrt's kamikaze 7.09 and I'm getting this:
<LeoNerd> Whereas svn doesn't really have such a concept. All it has is a cheap copy, that happens to live in a directory called "tags"
<mxpxpod> bzr branch https://svn.openwrt.org/openwrt/tags/kamikaze_7.09/ openwrt
<mxpxpod> bzr: ERROR: Not a branch: "https://svn.openwrt.org/openwrt/tags/kamikaze_7.09/".
<jelmer> mxpxpod: Do you have a subversion library that has been built with https support?
<jelmer> mxpxpod: Try "svn ls https://svn.openwrt.org/openwrt/tags/kamikaze_7.09"
<mxpxpod> jelmer: works fine
<mxpxpod> ah, I see
<mxpxpod> once I did that and accepted the certificate permanently, I'm able to branch
<Odd_Bloke> Could someone reject http://bundlebuggy.aaronbentley.com/request/%3C20080226155240.1f2f0145@lapbert.oxbridgetech%3E for me?  It's been superseded, but by a divergent branch.
<beuno> james_w, your post about bzr revno's rocks!  I suspect it's going to be widely pointed at  :)
<trondn_> hi... I am probably doing something seriously wrong.. I downloaded and installed the development tree of bazaar on my test system, and tried just a simple command such as bzr log -v on the source tree.. it used 13 _minutes_ to complete and used 94% of the cpu.. This is on Solaris with python 2.5... any ideas what I should do differently?
<asabil> jelmer: is there a way to handle google code svn with bzr-svn and launchpad ?
<jelmer> asabil: Not sure what you mean - it is certainly possible to pull code fomr google code svn and upload it to launchpad
<Peng> trondn_: Does your repo perhaps include the entire history of the universe?
<asabil> jelmer: last time I tried It was broken, and launchpad fails to import google code sometimes
<Peng> trondn_: You should install Pyrex and run "make". Bzr has some optional C bits to speed things up.
<trondn_> Peng: I used the command listed on the "installation" web-page to branch the repository...
<trondn_> Peng: I will try :)
<jelmer> asabil: bzr-svn and launchpad imports are a completely different thing
<asabil> yes I know, anyway I will wait for a new bzr-svn to test (one that is 1.2 compatible)
<jelmer> asabil: what exactly was broken then ?
<asabil> not able to find some special/inexistant files/properties containing a !
<asabil> I am not really sure about the exact problem
<asabil> I am unable to use bzr-svn (using bzr 1.2), but basically http://waf.googlecode.com/svn/trunk/ fails
<asabil> last time I tried
<james_w> beuno: thanks :)
<james_w> trondn_: that is far too long. I've not heard of anyone running on solaris before, maybe there is something that bzr is doing wrong on that platform.
<trondn_> james_w: i don't think there is anything wrong with the python-intepreter, because I did a quick test with mercurial, and that used just 2 secs to dump the history.. I will install the pyrex-library as suggested and retry the operation :)
<asabil> trondn_: truss  -a  -e  -f  -rall  -wall bzr log ?
<fullermd> Well, it's "too long", but I dunno if it's really unexpectedly long...
<asabil> (never used solaris, but truss seems to be the equivalent of strace)
<asabil> because 13 minutes is really very long
<Peng> Huh. I just got 14 seconds on Linux. I didn't expect it would be that fast.
<trondn_> asabil: it is using 98% CPU and all in user-space....
<fullermd> Yes, but log -v is slower than a dead snail tied to a 3 meter cube of depleted uranium.
<fullermd> I'm over 6 minutes of CPU time on running it here so far.
 * Peng wanders off.
<Peng> Wait, that's right.
<Peng> I can't read time.
<Peng> 14 *minutes*.
<Peng> So Slowlaris is faster!
<asabil> lol
 * Peng wanders off.
<asabil> fullermd: running it on the bzr sources itself ?
<fullermd> Yeah.
<fullermd> Over 8 minutes now...
<asabil> :/ maybe bzr log really needs some love
<fullermd> Well, yeah.  log -v and log $FILE have needed love since, like, ever.
<james_w> ah, I missed the -v
<trondn_> but why on earth is it so slow?
<fullermd> log isn't bad.  But as soon as it gets within whiffing distance of the inventory, it might as well be running on an 8086.
<trondn_> so there is nothing I can do to make it faster?
<trondn_> (without hacking the source...)
<fullermd> Heck, that's half the base complaint in the emacs thread; log $FILE.  That's not "slow with packs", that's always been *SLOW*.
<fullermd> Crud.  I'm over 12 minutes.  Hurry up and finish!  My ego couldn't take being behind Solaris...   :(
<fullermd> Well, either "hack the source", or "don't use log -v".
<beuno> fullermd, just pop in 3 more CPUs, and 4 gigs of ram
<beuno> that should put solaris in it's place
<LarstiQ> heh
<beuno> maybe a 15.000 rpm disk
 * LarstiQ is actually get a Sun machine RSN
<beuno> but that maybe abuse
<fullermd> Well, I certainly needs new disks.  And they will be 15k'ers.  But that's a few months off.
<trondn_> beuno: I also got a T5220 with 32 cores and 32GB ram I could try ;)
<Odd_Bloke> Because bzrlib and CPython are clearly able to use several cores. ;)
<beuno> trondn_, ah crap. Canonical will have to put sown some hard cash to beat that  :p
<beuno> we should finally open a bug for "bzr is too slow, send ram and CPUs to users on request"
<Odd_Bloke> +
<Odd_Bloke> Ack, +1
<Peng> Sign me up!
 * LarstiQ sends Peng a spare 6510
<Peng> Back in my day, a 2-core, 2 GHz CPU with 2 GB of RAM was good...
<fullermd> New drives will probably speed bzr up more on common ops for me than CPU upgrade...
<Peng> Well, the CPU is nice, but I keep chewing all my RAM with Firefox and whatnot.
<fullermd> My drives have done real nice by me, but they're getting a little long in the tooth.
<trondn_> fullermd: so what was the result of your command?
<fullermd> Dunno.  It's over 18 minutes now.
<trondn_> :O
<fullermd> Sad.  It took less than 9 to branch the whole history down across the network, more than twice that (and still running) to look at the logs.
<LarstiQ> fullermd: what branch would that be?
<fullermd> bzr.dev
<beuno> I suppose some noise should be made in bug 172975
<ubotu> Launchpad bug 172975 in bzr "bzr log slower with packs" [Medium,Triaged] https://launchpad.net/bugs/172975
<fullermd> I doubt that bug has much relation to this issue.
<trondn_> there must be something seriously wrong with the algorithm, because 98% of the time is spent in the userspace, and when I try to use truss to look at the the process it use extremely few system calls.....
<beuno> than a new one should be opened
<trondn_> (none in 30 secs..)
<fullermd> What's wrong with it is "building inventories is motherfarking expensive".
<beuno> fullermd, sounds like a good bug title
<AfC> I like it
<LarstiQ> on a plane?
<fullermd> Well, there's nothing particularly newsworthy about it.  It's been a known issue since...  I dunno.  0.6.2 at least.
<scode> What is the intended method of applying a merge directive with a minimum of fuss?
<scode> (one generated with bzr send)
<fullermd> Ah!  It finished.
<fullermd> scode: `bzr merge $FILE`
<fullermd> % time dbzr log -v >> /dev/null
<fullermd> 1592.597u 4.563s 27:09.30 98.0% 106+137k 912+0io 0pf+0w
<scode> fullermd: Thanks!
<fullermd> Less than a half hour at least.
<scode> Am I blind or should I submit a patch to have this documented? I don't see it mentioned in the merge cmd help, nor mentioned in the send help.
<LarstiQ> $HOME/bin/bzr log > alog  16.79s user 1.14s system 69% cpu 25.974 total
<Peng> 13 minutes 43 seconds! My computer rox!
<LarstiQ> fullermd: and mine is a puny laptop
<fullermd> I thought it was mentioned in an article in the main docs somewhere, but I'm not sure.  IF it's not, it certainly should be.
<fullermd> LarstiQ: Now try it with -v   :P
<Peng> LarstiQ: Not only log, but log -v.
<LarstiQ> oh oh :)
<Odd_Bloke> real	11m55.461s
 * LarstiQ started it and goes out for a bit
<fullermd> % time dbzr log >> /dev/null
<fullermd> 18.459u 0.321s 0:19.03 98.6%    103+133k 0+0io 0pf+0w
<Peng> Odd_Bloke: Damn.
<fullermd> And it didn't even break 130 meg of core that time.
<Odd_Bloke> Mine's a laptop too. :)
<Odd_Bloke> Anyhow, party tiem! :)
<Peng> Odd_Bloke: Running log isn't a party?!
<spiv> Heh, I'm in a talk  at PyCon that mentions bloom filters.
<fullermd> log -v is more like the hangover...
<trondn_> well, I started a bzr log -v on a pretty big repository earlier today, and guess for how long its been running ;)
<trondn_> 8:21:00 ;)
<trondn_> and still not done ;)
<LarstiQ> spiv: hihi
<spiv> LarstiQ: hello
<spiv> LarstiQ: if I go quiet, it's probably because the network here hates me.
<LarstiQ> spiv: I know that feeling. I got my wifi card yesterday, tried to use it in the office, and then realized it doesn't support WPA.
<spiv> LarstiQ: ouch.
<spiv> LarstiQ: the problem here isn't so much my hardware as the other 900 people trying to use the network at the same time.
<LarstiQ> spiv: ah yes
<LarstiQ> spiv: how is PyCon going so far?
<spiv> Good.  Busy!
<LarstiQ> spiv: have you met Mark Hammond yet?
<spiv> I have!
<LarstiQ> yay!
<Stavros> how can i see a list of the versioned files?
<spiv> Stavros: bzr inventory
<fullermd> Stavros: Check 'bzr ls' and its options.
<Stavros> oh right, thanks
<salgado> hey guys, why should I "bzr record" in a loomified branch? and what happens if I don't?
<salgado> lifeless, you awake already? (^)
<spiv> salgado: it records teh state of the lom
<spiv> er, loom
<spiv> salgado: as in, what the current revision of each thread is.
<spiv> salgado: so if you want someone else to be able to branch your loom and have all the current revisions and see all the threads you've added and what your current thread is, you should use "bzr record"
<fullermd> From skimming the docs, I think of it as sorta a 'meta-tag'.
<salgado> spiv, right, that's what I imagined, but nobody can see the threads of my loomified branches once I push them to devpad. is that expected?
<salgado> (I did record them)
<fullermd> I think that's a different problem, that push doesn't push looms right...
<salgado> could be
<spiv> salgado: https://bugs.edge.launchpad.net/bzr-loom/+bug/201613 and https://bugs.edge.launchpad.net/bzr-loom/+bug/201409 might be affecting you
<ubotu> Launchpad bug 201409 in bzr-loom "pulling a loom resets to last-recorded state" [Undecided,New]
<salgado> a ha. /me subscribes
<salgado> thanks spiv!
<awilkins> jelmer: Any luck with those pyrex bindings?
<awilkins> jelmer: I'm having _lots_ of fun trying to get them to build on win32
<scode> I know I read somewhere about a setting that would allow me to have a branch of an upstream repo, which I in turn branch (down to my workstation for making actual modifications), yet have 'bzr send' and such use the original upstream as the target branch rather than the intermediare staging branch. Rings a bell?
<blueyed> scode: rebase?
<beuno> scode, you can just do bzr push parent_repo_location
<beuno> don't need to jump through the branched branch
<fullermd> Er.  Send, not push.
<fullermd> And you can specify the target branch on the 'send' commandline.
<beuno> send?
<fullermd> And use --remember to mark it permanently.
<scode> beuno: I am branching the bzr.dev upstream repo to which I have no access.
<scode> beuno: This branc I keep on my central server. But then I want to branch *that* to work on.
<scode> But I want "bzr send" to generate bundles as if I had had the bzr.dev as the direct upstream.
<beuno> aaah, right
<beuno> well, I have that exact workflow
<LarstiQ> fullermd: $HOME/bin/bzr log -v > vlog  988.73s user 36.39s system 90% cpu 18:52.94 total
<beuno> and send works fine when specifying upstream (and add --remember, as fullermd said)
<scode> Yeah, just looking into that. Thanks!
<fullermd> LarstiQ: Pfft.  You losers and your up-to-date systems   :p
<beuno> scode, welcome
<LarstiQ> fullermd: well, sort of :)
<fullermd> I've got a spare drive somewhere I could toss in the PPro, and see how long that runs...    I remember those 45 minute 2-rev 'bzr pull's...
<ubotu> New bug: #202331 in bzr "log should be able to show diffs as well" [Undecided,New] https://launchpad.net/bugs/202331
<benzo> hi
<jelmer> awilkins: Hi
<jelmer> awilkins, still there?
<benzo> yes - again
<benzo> you too?
<Odd_Bloke> Evening.
<benzo> i've some basic questions
<Odd_Bloke> benzo: Don't ask to ask. :)
<benzo> always
<benzo> as far I understand is bazaar a distr. scm
<benzo> but there are also centralized scenarios
<Odd_Bloke> benzo: Yep.
<benzo> so you have basically:
<benzo> - a server and - a client
<benzo> could someone explain me how to start in such a scenario?
<Odd_Bloke> benzo: You don't need a client/server in a distributed SCM.
<Odd_Bloke> benzo: You _can_ do it that way, but it's not the only way. :)
<fullermd> I think terminologically "server" and "client" are misleading in this connection...
<benzo> there is a term "lock-step"
<fullermd> It's really best viewed as a continuum.
<benzo> yeah but I like to stick with client/server model for a moment - ok?
 * fullermd shrugs.
<fullermd> I don't think it's helpful.  Distributed work is all client-server too.
<fullermd> The distinguishing feature is branch relations, not "client" or "server".
<LarstiQ> benzo: often, the 'server' is just another client you decide to think differently of.
<huslu> is there something that can track owndership and permission info of files in bzr?
<benzo> ok here is what I mean: server=mainline
<LarstiQ> huslu: unix permissions? Not in the core
<LarstiQ> benzo: ok
<huslu> LarstiQ: anywhere else? i'm trying to track /etc
 * fullermd should write something up someday.
<benzo> how do I have to setup that?
<benzo> how do I start?
<benzo> I'd like to have the following scenario for starters:
<LarstiQ> huslu: a quick look at BzrPlugins doesn't show any, but I know people use bzr for /etc. You might also want to look at the tool 'etckeeper'
<benzo> 1. a central repository on a webserver
<LarstiQ> benzo: well, you could just push/pull to one machine
<benzo> 2. a client who can checkout/commit
<benzo> 3. the possibility the read the sources via web browser
<benzo> on the server, i went through the 5-min tut: http://doc.bazaar-vcs.org/latest/en/mini-tutorial/index.html
<benzo> to the step: Viewing the revision log
<benzo> but know I'm not sure if I startet the wrong way
<LarstiQ> benzo: http://bazaar-vcs.org/Workflows may be of help
<benzo> do I have to start on the 'client' and then push the branch to the server?
<LarstiQ> benzo: no, you can make available what you did and go from there
<benzo> yes I know these - thanks
<benzo> but again - do I have to start on the 'client' and then push the branch to the server?
<benzo> in a centralized scenario?
<LarstiQ> benzo: no, the server is nothing special, it's a client too
<LarstiQ> benzo: so there's nothing really wrong with what you did
<benzo> is it ok then when I started on the server (sorry ...)
<LarstiQ> benzo: yes, it is.
<LarstiQ> no worries :)
<benzo> and how can this no requested per url?
<benzo> for viewing it in a web browser
<LarstiQ> benzo: multiple different ways. For write access you'd either have bzr+ssh:// or sftp:// or possibly bzr:// if you run bzr serve
<LarstiQ> benzo: ah, that's a different question
<LarstiQ> benzo: do you want the raw content, or something like loggerhead?
<benzo> i think i start with raw content
<benzo> its easier i guess
<LarstiQ> http://bazaar.launchpad.net/~bzr/bzr/trunk/files is an example of loggerhead btw
<benzo> nice! but step-by-step
<LarstiQ> benzo: well, then you'd need to have a webserver running, and somewhere under it's docroot you'de have a checkout of the branch you want to browse
<benzo> ah ok - thats the mistake ive done
<benzo> what if i'm not on the server
<LarstiQ> what do you mean?
<LarstiQ> Surely you're not physically sitting on it :)
<benzo> can the checkout be done remotely
<benzo> :-)
<LarstiQ> benzo: making a checkout on the server needs to have access to it somehow
<benzo> otherwise the content on the web is not updated
<benzo> do you know svn
<benzo> ?
<LarstiQ> I do.
<benzo> you can setup apache that he reads the repository
<LarstiQ> benzo: yeah, so as an equivalent to that I'd probably suggest running loggerhead.
<benzo> but loggerhead is 'just' the webfrontend no
<benzo> ?
<benzo> sorry i alway miss the ?
<LarstiQ> 'a' webfrontend, yes
<benzo> but consider the following workflow
<benzo> a.) I work on my machine and commit to the central repo
<benzo> b.) then I have to make a checkout on the server, so that I can view the changes on the web?
<LarstiQ> that doesn't seem like a workflow?
<LarstiQ> benzo: what are you trying to accomplish with viewing it on the web?
<benzo> viewing the sources
<LarstiQ> you can do that by other means of course, but then why not use loggerhead for that purpose?
<benzo> c) an other person would checkout then
<LarstiQ> making a checkout is no different for them than for you?
<benzo> its an example
<benzo> and why do I have to checkout?
<LarstiQ> maybe it's because it's almost 01:00
<LarstiQ> but I don't understand what your problems are
<benzo> a picture says more then thousand words: http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/images/workflows_centralized.png
<LarstiQ> benzo: if you had just a basic httpd, and wanted to show the file contents, you would make use of it's filesystem backed method of showing files. In order to get the files you want to view from a branch, you make a checkout.
<LarstiQ> benzo: I understand the picture, I don't see how it explains your questions.
<LarstiQ> maybe an example helps
<benzo> but you had it almost: "benzo: yeah, so as an equivalent to that I'd probably suggest running loggerhead."
<LarstiQ> 'client'> cd work; bzr push sftp://server/srv/bzr/work; ssh server bzr co /srv/bzr/work /var/www/viewable-work ; links http://server/viewable-work
<LarstiQ> and then you'd see the files in your browser
<LarstiQ> benzo: if you use loggerhead, you wouldn't create a checkout on your server
<LarstiQ> benzo: since in that case you have a webapp doing the work for you, instead of using a dumb http that is only showing files it has on disk.
<LarstiQ> httpd even
<benzo> client'> cd wo.... THIS IS WHAT I WANTED TO KNOW
<LarstiQ> note in my command line exaple above, you would only do the 'bzr co /srv..' once
<benzo> ;-)
<LarstiQ> benzo: you didn't make that clear to me
<LarstiQ> and now I'm going to bed
<LarstiQ> ciao
#bzr 2008-03-15
<benzo> bye and thanks for your patiente
<benzo> patience
<benzo> LarstiQ, are you still there?
<benzo> one last question
<benzo> I made already a repository on the server but at the wrong place.
<benzo> can I simply move the folder?
<LarstiQ> how did you create it?
<benzo> on the server: $bzr whoami
<LarstiQ> ie, did you make a standalone branch and are you calling that a repository, or did you actually create a shared repository with branches underneath?
<LarstiQ> since you seem to come from svn you might be conflating some terms there
<benzo> seems so
<LarstiQ> benzo: was all you did 'bzr init foo'?
<benzo>  i went to the 5-min tut http://doc.bazaar-vcs.org/latest/en/mini-tutorial/index.html#viewing-the-revision-log
<LarstiQ> or have you done a 'bzr init-repo bla' too?
<benzo> just $ bzr init
<benzo> then $ bzr add
<LarstiQ> ok, you can just mv that around as you wish
<LarstiQ> if you had branches in a repository, you would need to move around the entire repository
<benzo> ok thanks - and good night now
<LarstiQ> since branches store their actual revisions there, and if you move them out of their repository they won't be able to find any
<LarstiQ> ok, thanks
 * LarstiQ detaches
<ubotu> New bug: #202374 in bzr "pull and update should accept --show-base" [Undecided,New] https://launchpad.net/bugs/202374
<benzo> i try to checkout, but it dont work
<benzo> something is wrong with my auth. config.
<benzo> ... i guess ...
<nekohayo> hey there folks, is there a way for me to know if one of my folders is a "branch" vs a "checkout"?
<Peng> bzr info?
<Peng> If it's a checkout, "bzr pull" would probably fail.
<nekohayo> Peng: I think that's it! thank you :)
<nekohayo> so Standalone tree (format: dirstate) means it's a branch, and that it's independent right?
<dsargeant> hi, I'm using bzr 1.2 candidate 1 from Hardy. A file was renamed outside of bzr during a refacgtoring. How do I tell bzr that a file was renamed, not removed and another added?  In previous versions of bzr I could use bzr mv, but now that fails.
<schierbeck> dsargeant: have you made changes to the file?
<schierbeck> it should figure it out by itself...
<Peng> nekohayo: I dunno. I think so.
<dsargeant> schierbeck: yes, some variables in the file were renamed
<spiv> nekohayo: right
<schierbeck> try moving it back manually, then redo the move with bzr mv
<Peng> dsargeant: Well, bzr mv isn't supposed to fail. Got a testcase?
<spiv> dsargeant: try "bzr mv --after ..."?
<schierbeck> Peng: i think it's because the source of the move doesn't exist any more
<Peng> schierbeck: That's the point of "bzr mv --after"...
<schierbeck> spiv: oh, didn't know that one! cool!
<schierbeck> awesome
<Peng> Oh, ok.
<schierbeck> well, you learn new stuff every day, huh?
<Peng> :)
<dsargeant> Peng: the reason it fails is that it says the source of the mv is unversioned.  When I do a bzr st, the src is listed as removed.
<dsargeant> spiv: --after produced the same result
<Peng> Testcase?
<james_w> hi jam. Hows the conference?
<spiv> dsargeant: can you pastebin the error?
<dsargeant> Peng: what's the best way of giving you a test case?
<spiv> james_w: the connectivity seems better today.
<james_w> ah, you're there as well :)
 * spiv -> snacks
<dsargeant> spiv: the error is: bzr: ERROR: Could not rename Graph.java => TouchGraph.java: src/main/java/Graph.java is not versioned.
<james_w> dsargeant: are you trying this in src/main/java?
<james_w> dsargeant: if so try it in the root and use the full paths.
<james_w> dsargeant: I don't know if it will help, but it is worth a try.
<dsargeant> james_w: I'm trying it from the root of the project that contains .bzr
<dsargeant> james_w: Very sorry, I rechecked my paths and was missing a directory. src/main/java/Graph.java, should have been src/main/java/graph/Graph.java.  Thanks for your help guys.
<nekohayo> hm, is there a way to merge things properly when two branches have no common ancestor? well actually they do codewise, but the 2nd is lacking the history of the 1st one and I'm trying to fix that x_x
<james_w> dsargeant: no problem.
<james_w> nekohayo: yes, bzr merge -r0..-1 ../other-branch
<james_w> nekohayo: however it will give you lots of conflicts, and may not be very useful at all.
<nekohayo> james_w: I still get an "ERROR: Revision {('wout@wout-laptop-20071012201326-65ijzopxe5uj94tq',)} not present in "<bzrlib.knit.KnitGraphIndex object at 0x8c6cbcc>".
<nekohayo> any idea what that means?
<nekohayo> this happens whether I use  -r0..-1 or not
<james_w> oooh, interesting.
<james_w> nekohayo: hmm, works on a quick test that I did.
<james_w> nekohayo: what version of bzr are you using?
<nekohayo> james_w: 1.2.0.candidate.1
<james_w> nekohayo: I'm not sure then.
<nekohayo> james_w: would you like me to provide the two branches that I'm trying to merge as a sample for you?
<james_w> nekohayo: can you try to run with -Derror and paste the traceback?
<nekohayo> sure
<james_w> nekohayo: that may be necessary, but we'll try this first.
<nekohayo> james_w: http://pastebin.ca/943767
<james_w> nekohayo: and you get the exact same error with -r0..-1?
<nekohayo> yes
<nekohayo> james_w: need the debug output for that one too?
<james_w> nekohayo: sorry, went to grab some lunch
<james_w> nekohayo: I don't need to output if it is the same.
<james_w> nekohayo: so, let's look a bit deeper.
<james_w> are these branches sharing a shared repository?
<nekohayo> how do I know?
<nekohayo> both are Standalone tree (format: dirstate)
<james_w> ls .bzr/repository in one of them.
<nekohayo> format		inventory.knit	lock		revisions.knit	 signatures.knit inventory.kndx	knits		revisions.kndx	signatures.kndx
<james_w> ok, so there's no shared repo involved
<nekohayo> the other branch has only "format  indices  lock  obsolete_packs  pack-names  packs  upload"
<spiv> (bzr info output is a good way to determine that too)
<james_w> spiv: yeah, I'm not always sure how to interpret that now.
<james_w> nekohayo: so that means one is packs and one is knits, that may be significant.
<james_w> nekohayo: which one was which in the above output (i.e. was it the first or second that you ran the merge command in)?
<nekohayo>  "format  indices  lock  obsolete_packs  pack-names  packs  upload" comes from "specto-jeff-new", which is the branch that contains the older history, into which I am trying to merge specto-jeff which contains newer stuff but no backwards history
<james_w> nekohayo: cool, let me try that
<nekohayo> james_w: you need my samples?
<james_w> nekohayo: ok. so without -r0..-1 you should get "bzr: ERROR: Branches have no common ancestor, and no merge base revision was specified."
<james_w> so something seems to be broken in the branch "specto-jeff-new".
<nekohayo> james_w: nay, when I do it without -r0..-1 I get the same errer
<james_w> can you try "bzr log -r revid:wout@wout-laptop-20071012201326-65ijzopxe5uj94tq" in that branch.
<nekohayo> that is ERROR: Revision {('wout@wout-laptop-20071012201326-65ijzopxe5uj94tq',)} not present in "<bzrlib.knit.KnitGraphIndex object at 0x8c3eb8c>"
<spiv> Maybe also worth trying "bzr check"?
<james_w> nekohayo: I understand that you do, but you should get the above more sane error, and as you don't it indicates that something is a bit broken.
<james_w> also what spiv suggests make sense.
<nekohayo> james_w: bzr log works in specto-jeff (obviously not in specto-jeff-new)
<spiv> Although it seems fairly likely that that branch is referring to a revision that doesn't exist in its repository.
<james_w> nekohayo: why doesn't it work in -new?
<nekohayo> james_w: because -new contains older code (remember, I'm trying to merge specto-jeff into it :)
<spiv> Which would mean specto-jeff-new is broken.  I'd be interested to know how that happened.
<nekohayo> spiv: the whole affair is that specto-jeff was started without the version history
<nekohayo> and I'm trying to rectify that
<nekohayo> spiv, james_w: http://pastebin.ca/943780
<nekohayo> also, see: ecchi.ca:8000/1.png
<james_w> nekohayo: I'm a bit lost now.
<nekohayo> that screenshot *might* help you
<nekohayo> on the left is the "full history" specto-jeff-new
<nekohayo> on the right is the newer but broken specto-jeff from which I'm trying to merge
<james_w> and 'wout@wout-laptop-20071012201326-65ijzopxe5uj94tq' is the last revision in that branch?
<james_w> -jeff I mean?
<nekohayo> hmm, I doubt so
<james_w> I guess not, it's not the first is it?
<james_w> I'm just wondering why it is that revision in particular that it is choking on.
<nekohayo> it's not the first either
<james_w> nekohayo: ah, ok, that is a random revision from a set() of missing.
<james_w> Can you please run the command again with BZR_PDB=1 set?
<james_w> that will drop you in to a debugger as the error is raised.
<james_w> you can then "p missing"
<james_w> I am guessing it will print a large number of revisions.
<nekohayo> "bzr merge ../specto-jeff BZR_PDB=1" ?
<james_w> BZR_PDB=1 at the start please.
<james_w> It's an environment variable, so it goes before the command, in this case "bzr"
<nekohayo> (Pdb) p missing
<nekohayo> set([])
<nekohayo> and I'm back at the debugger prompt
<james_w> weird, so it is just that one revision.
<spiv> That revision does exist, but not in -new.
<spiv> It's odd wcurious that it's apparently trying to find it in -new.
<nekohayo> need my branches :) ?
<james_w> nekohayo: can you type "up" in the debugger 12 times please?
<nekohayo> ok
<james_w> then "p source"
<james_w> "p self"
<nekohayo> that's all?
<spiv> Hmm, I wish looms had a "rename-thread" command.
<nekohayo> james_w: http://pastebin.ca/943795
<james_w> spiv: you can probably edit something.
<james_w> spiv: though I don't know if would be handled by merging.
<james_w> I think eventually it will be supported though.
<james_w> nekohayo: thanks, can you also "p inter" please?
<nekohayo> james_w: <bzrlib.repository.InterModel1and2 object at 0x8750e2c>
<james_w> nekohayo: thanks, one minute
<nekohayo> it fascinates me that some humans can understand that one line of letters and numbers :) awesome
<james_w> nekohayo: ok, I think I'll need the branches.
<james_w> My current guesses are that it there is discrepancy between what it thinks it needs to fetch and what it then requires to be fetched.
<james_w> Or there is corruption that is not being detected by check.
<nekohayo> james_w: you should be able to pull them from ecchi.ca:8000/trunks/ normally
<nekohayo> oops, doesn't work
<nekohayo> ah ok, yeah branching works
<nekohayo> james_w: were you able to branch from there correctly?=
<james_w> nekohayo: yep, thanks I can reproduce the error, so I'll look in to it.
<nekohayo> ok, so should hang around in this channel today I guess :)
<james_w> nekohayo: try it, you might like it :)
<james_w> nekohayo: sorry, I'm not familiar enough with the code that it is having trouble with to debug it.
<james_w> nekohayo: would you like to post to the list about it?
<james_w> nekohayo: or I can do it if you like.
<nekohayo> james_w: if you could do it for me, it would be very nice :)
<james_w> nekohayo: sure, want a cc?
<nekohayo> especially because I think you know better than me what needs to be asked and what info needs be provided
<nekohayo> yes, nekohayo at gmail
<james_w> well I don't know much more.
<james_w> nekohayo: are those branches going to stay there, or should I mirror them?
<nekohayo> james_w: that's on my desktop computer which is on pretty often, but not 100%, so you might want to mirror them, or tarball+attach them?
<james_w> nekohayo: I'll mirror them, it's no trouble.
<nekohayo> I'll leave IRC on, but I have to go out for a few hours today so I may not reply fast
<james_w> nekohayo: sure.
<james_w> nekohayo: if you ever hit such an ugly error message again it's a bug, even if you think that you may be doing something silly.
<james_w> nekohayo: so please feel free to report them anyway.
<nekohayo> well I the hexadecimal stuff made me think so, that's why I came here immediately :)
<james_w> :)
<james_w> nekohayo: aha, just found something more. It appears as though there is corruption in specto-jeff.
<mamato> hi, how can i completely remove files from bzr? i used 'remove' but my .bzr is still huge...
<james_w> mamato: it's not currently possible to remove files from the history.
<james_w> mamato: if you were to do that you would have to rewrite history anyway.
<mamato> wow!
<james_w> well, rewrite the history of your branch at least. You might be able to leave the rest of the universe alone.
<mamato> that sounds crazy to me... basically i should just throw away my .bzr and restart one...
<mamato> sounds like i might as well seriously consider remplacing it with different versionning soft then... :S
<james_w> mamato: if you are allowed to change the contents of a previous revision then any distributed system will break.
<james_w> mamato: you can remove old stuff in all of them by rewriting their histories, but you then break any branches that you have made from the one that you rewrite.
<mamato> i dont really care about braking other branches, i'm the only one using my branch
<mamato> what does rewriting history entail?
<james_w> for each revision in your branch removing the stuff that you don't want, and then recording the revision again.
<mamato> can i delete revisions?
<mamato> nevermind
<mamato> how can i how can i commit that modified old revision to its old revision number and not to new one?
<mamato> james_w?
<james_w> mamato: you need to do something like rebase.
<james_w> I don't know a tool already written to do what you want.
<mamato> i have no rebase command
<mamato> found plugin
<mamato> hmm, looks complicated
<alexreg> hi... is there any way to change log messages of previous commits?
<Peng> No.
<LeoNerd> Not really... You could uncommit then recommit it.. but that'll only work for the most recent commit
<LeoNerd> (I've done that occasionally, to fix up typoes or files I didn't mean to commit)
<alexreg> ahh...that's what i was thinking
<Peng> Yeah, you can do that.
<Peng> But if you've already pushed the revision and other people have pulled it, it wouldn't work so well.
<LeoNerd> Failing that, you could take a new branch, then somehow do some clever merging and rebasing.. but I wouldn't like to suggest chances of success
<alexreg> yeah. it works fine for most of the time, but if you realise one of you're log messages before that is bad...
<LeoNerd> Don't Rewrite History, is my advice
<alexreg> fair enough
<Peng> There are lots of typos in bzr.dev's history. :)
<LeoNerd> A little fudging of something you did two minutes ago is fair enough if nobody's noticed.. Two months is just asking for trouble
<alexreg> possibly. but just correcting typos or an inaccurate log message couldn't really hurt ?
<Peng> It would be difficult to manage.
<alexreg> are there any plans to add log message editting in a future release?
<Peng> I doubt it.
<LeoNerd> In theory, just changing the log message shouldn't be a problem.... there's no real data change, no possibility of conflicts with future patches
<alexreg> that's what i thought
<LeoNerd> However, in practice it doesn't work like that. The log message is part of the commit
<alexreg> i see...
<LeoNerd> The entire commit gets MD5ed or whatever, and becomes part of its hash.. its ID
<LeoNerd> Changing the log would change the MD5sum, and thus change the identity of the commit
<alexreg> interesting...why is the log message used to compute the hash?
<LeoNerd> So anything built on top if it would need changing.. which changes its own hash. all the way down
<alexreg> it need to be used, i'd think...
<Peng> (Bzr uses pseudorandom revision IDs...)
<LeoNerd> The hash is used to avoid sequencing problems a.la. tla
<LeoNerd> One of tla's problems is that within a branch, the only identity of a patch is its sequence number.. 1, 2, 3,...
<alexreg> yeah: but shouldn't a hash of the file contents (or even modified date/time) suffice?
<LeoNerd> This means you can't split offline, and work independently, to merge again later. You'll both take 4
<alexreg> right
<alexreg> ah, maybe i misunderstood "sequencing problems"...
<alexreg> thanks for the explanations LeoNerd  and Peng
<alexreg> perhaps i'll submit this as a feature request, but it's not a straight-forward matter
<Peng> Even if bzr wasn't so strict about history being immutable, mutable log messages would be a pain.
<Peng> What if you pull, and a message has changed. What should it do? Silently overwrite your copy of the message? Prompt you, showing a diff or whatever?
<alexreg> i don't see any problems if it just overwrites and notifies you
<Peng> What if someone malicious changes it?
<alexreg> malicious people wouldn't change things. if they have access to the repo anyway, they can include bad commits
<Peng> alexreg: Yeah, but they couldn't silently change history.
<alexreg> true...
<alexreg> what if only the original commiter could edit their log messages? using their PGP key, that could be verified.
<alexreg> admittedly, this is turning into a slightly complicated process, but i would still appreciate it existing.
<Peng> That's an idea.
<alexreg> so that could be worthwhile request for me to submit. i will need to write out the specifics, of course
<alexreg> i appreciate the discussion...
<alexreg> got to go now. bye
<Peng> alexreg: Bye. :)
<ubotu> New bug: #202613 in bzr "'bzr update' probes the master branch >=3 times" [Medium,Triaged] https://launchpad.net/bugs/202613
<spiv> jelmer: your 0.4.8 branch needs this patch to make initial branching work: http://rafb.net/p/f4Qt8T85.html
<jelmer> spiv: Any chance you can "bzr send" it?
<AfC> If you haven't seen it yet today, Elijah has written another missive.
<AfC> http://blogs.gnome.org/newren/2008/03/15/how-not-to-write-newbie-friendly-documentation/
<AfC> While it's mostly a rant against Git, I'd encourage the Bazaar hackers to consider these points in relation to their own documentation.
<spiv> jelmer: sure.  what's the preferred forum for that? bazaar@?
<spiv> jelmer: or just direct to you?
<spiv> AfC: yeah, I read that earlier today.  It's a good post.  He compliments bzr's documentation briefly, which is nice :)
<jelmer> spiv: Either would be fine. "bzr send" defaults to me
<spiv> Oh, nice.
<spiv> ("bzr info" really ought to report that...)
<AfC> I should probably note that despite all this Elijah seems to be strongly leaning towards sticking with Git.
<AfC> Which is largely due to his having become enamoured of capabilities that Bazaar does not, unfortunately, accomodate.
<jelmer> spiv: Thanks
<jelmer> AfC: What sort of capabilities?
<jelmer> AfC: The usual (speed, easier to switch branches, group copying) or other things as well?
<jelmer> s/switch/switch in place/
<AfC> jelmer: {shrug} the usual list, I'm sure. I can't remember his specific ones, but they were all on the board in London
<ubotu> New bug: #91931 in bzr-gtk "Should support showing signatures" [Wishlist,Confirmed] https://launchpad.net/bugs/91931
<jelmer> schierbeck: Hi
<schierbeck> hi jelmer
<schierbeck> jelmer: i'm having another look at the signature ui bits
<schierbeck> hmm, can't seem to push to launchpad right now...
<schierbeck> oh, there we go
<schierbeck> jelmer: if i want to install icons, should i add them to $(prefix)/share/bzr-gtk/icons ?
<schierbeck> currently we only add the olive icons to share/olive/icons
<chewy> when's the BoF for pycon?
<nekohayo> james_w: corruption? in my branch? LIES!!
<nekohayo> now, how come? :)
<nekohayo> how can corruption happen?
<schierbeck> nekohayo: lack of government control?
<nekohayo> hahaha
<nekohayo> schierbeck: any other explanation why corruption could happen in a bzr branch though?
<schierbeck> nope :)
<james_w> nekohayo: I'm not sure, maybe it's not corruption, but bzr confusing itself.
<james_w> something sure is funky though.
<nekohayo> james_w: as you can guess, code.launchpad.net/~specto is an ugly mess and I'm trying to merge the old history with the new one :|
<NfNitLoop> Hmm.   I'm using bzr-svn to check out a rather large svn repo, and the memory seems to be steadily climbing.   I've run into this problem before, but now I'm running Ubuntu 7.10 which supposed has patches that fix the python-subversion binding memory leak.
<NfNitLoop> supposedly*
<NfNitLoop> is this a new issue?  Something related?
<NfNitLoop> And, in the meantime, is there a good workaround?  (maybe a way to incrementally pull in a few separate runs instead of trying to do it all at once?)
<james_w> NfNitLoop: that's the workaround yes.
<NfNitLoop> how do I do that?
<NfNitLoop> I tried interrupting the process...
<NfNitLoop> but if I try to resume, it seems to start all over again.
<james_w> I don't know if gutsy has the patches, I think it does, but I think that it can still have memory issues on large repos.
<james_w> you need to use -r
<james_w> bzr init trunk
<james_w> cd trunk
<james_w> bzr pull -r 1000 url
<james_w> bzr pull -r 2000
<NfNitLoop> aah.
<james_w> I think that's it.
<james_w> you can obviously script it.
<NfNitLoop> *nod*
<NfNitLoop> thanks.
<james_w> no problem.
<NfNitLoop> Hmm... does bzr-svn not work with bzr 1.2?
<NfNitLoop> TypeError: create_workingtree() got an unexpected keyword argument 'hardlink'
<jelmer> NfNitLoop: it should work with 1.2
<jelmer> the hardlink stuff was introduced in 1.3 I think
<jelmer> spiv just sent me a patch to fix that but I haven't gotten round to applying it yet
<NfNitLoop> so I need to upgrade to bzr 1.3?
<james_w> hi jelmer
<jelmer> NfNitLoop: you're already on 1.3 I think
<NfNitLoop> Bazaar (bzr) 1.2.0
<NfNitLoop> bzrsvn 0.4.9dev0
<jelmer> NfNitLoop: ah, you either need to use the 0.4.8 branch (which is compatible with 1.2) or use bzr 1.3
<NfNitLoop> aaah, ok.  I'll get 0.4.8
<NfNitLoop> I just grabbed the 0.4 branch, I guess that's not always in-sync w/ bzr stable?
<jelmer> NfNitLoop: the 0.4 branch is in sync with bzr.dev
<NfNitLoop> gotcha.
<NfNitLoop> thanks.
<jelmer> NfNitLoop: Ubuntu 7.10 does not have the memory leak fixes, btw
<jelmer> only 8.04 has
<NfNitLoop> That would explain the memory leak, then.
<NfNitLoop> I thought the wiki said they had been applied to previous ubuntu releases.
<NfNitLoop> so I assumed they were in 7.10 too.
<jelmer> nope, those are other fixes (the fixes required to run bzr-svn at all)
<james_w> woo, sort-of-log emitting the first revision in about 5 seconds on emacs.
<jelmer> james_w: nice! Any consequences for the overall performance of log?
<james_w> jelmer: well it's about 10 seconds quicker to do the whole thing.
<jelmer> I remember some of the other fixes that were posted to the list made a full "bzr log" run slower
<jelmer> ah, nice
<james_w> however it's not doing bzr log, it's doing git log.
<james_w> but if you limit it to less than the 87000 revisions then it's pretty damn quick, e.g. 5s to emit 10000 revs
<james_w> I know it's doing something different, but having a topo-sorted log option would help on this big projects.
<james_w> it seems like around 5s is the minimum on the full history just due to extracting all the necessary data from the repo to topo-sort it.
<jelmer> ahh, ok
<jelmer> well, having that as an option would certainly not be a bad thing
<james_w> yeah, speeding up the others is obviously important, but I wanted to see what the costs were of other things we were doing, so I just stripped it down to the minimum.
<james_w> it took me a long while to beat the default log on overall time though, even though I quickly beat it too emit the first revision.
<AfC> Been really interesting sitting with Carl Worth, Behdad Esfahbod, Rob Taylor, etc this week. They're all using Git (ie for Cairo) but Carl in particular is really open minded.
<james_w> I missed on the batching of revision fetching it was doing.
<james_w> One thing i noticed is that we seem to grab every revision twice, which might be something to look at.
<AfC> ... and walking him through using Bazaar to do a few things on projects of mine that he was bringing up was a positive experience leading to much sharing of state.
<james_w> AfC: yeah, Carl spent a long time in here some time ago talking to us about the similarities and differences between the two. He took a while to see the reasons behind some of the differences, but he definitely seemed open minded.
<james_w> I can't remember if that was the trigger for the bzr/git thread or the result of it.
<james_w> and I know he is one of the main reasons that the git UI has improved so much.
<james_w> AfC: is the hackfest over now?
<AfC> I was reflecting that as we are working on "git features" (ie, in-place-switching [which is very close to being sorted], managing-a-collection-of-branches and/or multiple-heads, etc) that it would be really useful to demonstrate [as he just did for me] his usage patterns and the things that are useful to him.
<AfC> james_w: getting there. 50% are on their way home now, and most of the rest are out tomorrow.
<james_w> AfC: was it successful?
<AfC> Fantastic
<james_w> I think there is plenty we can bring in from git, I do think it is a good system.
<AfC> I actually plan to write a blog about the Bazaar sprint and the GTK hackfest (compare and contrast, as your year 8 English teacher would have told you to do)
<james_w> AfC: are you sticking around Europe for a while, or are you jetting off elsewhere?
<james_w> AfC: :-). That would be pretty cool actually.
<AfC> james_w: nah, time to be on my way. I'm here until Monday morning, then Toronto next. We *really* need some new business.
<james_w> I was just wondering why there was a naming difference, and whether this had any effect on the content or atmosphere.
<AfC> james_w: I have a theory :)
<james_w> AfC: too much time hacking I guess.
<AfC> james_w: which I related to the crowd here. It was funny, because half of them had been in hacking mode, and half of them had been in what you would relate to as sprinting mode
<AfC> and the two halves were looking at each other funny when I related my explanation of the difference
<james_w> I thought sprints were more about hacking, is it just the bzr one that is more discussion, or is that pretty standard?
#bzr 2008-03-16
<AfC> There are a bunch of people here running "Hardy" who have bzr-1.2-candidate.1 as their Bazaar version.
<james_w> the package name, or as reported by --version?
<james_w> if it's the latter I think that is expected. I think there were no code changes between the rc and release, so dato didn't bother making a no change upload to fix the version number.
<Odd_Bloke> Evening.
<rodge> evenin urself :)
<james_w> hi Odd_Bloke. Glad to see you back to having your times of day the wrong way round.
 * Odd_Bloke is going to bed as soon as his pizza arrives (and is NOM NOM NOM'd).
<poolie> hello
<james_w> hi poolie
<rodge> hey, quick question. if i wanna publish a branch to a server with ssh, does it have to have bzr installed?
<james_w> rodge: no, but it is more efficient if it is.
<james_w> if it isn't use sftp:// urls, if it is use bzr+ssh:// urls
<rodge> ok, thanks heh. i would install it there if i could, but, school server =P
<james_w> rodge: you can install it by downloading it if it's just a question of permissions.
<james_w> use BZR_REMOTE_PATH if you do that.
<james_w> obviously don't if just downloading it will get you in trouble :)
<rodge> heheh, nah, and they have python 2.4 at least, so i'll try that
<rodge> thanks alot
<james_w> no problem
<ubotu> New bug: #202710 in bzr "bzr-svn crashes with traceback when cloning a local svn file repo" [Undecided,New] https://launchpad.net/bugs/202710
<nekohayo> james_w: any news/insight on what might have happened with the weirdness in specto-jeff yet?
<poolie> thanks for your post about log,james_w
<james_w> nekohayo: no, sorry, I haven't tried again, and the best people probably wont be around over the weekend.
<james_w> poolie: thanks, which one?
<james_w> nekohayo: I'm just guessing, but I don't think it's corruption in terms of disk problems or anything, as it seems too specific for that.
<nekohayo> james_w: a bug in the merge logic?
<james_w> It's something like the wrong revision was recorded in a knit or something.
<james_w> nekohayo: I don't think so, as upgrade fails as well
<james_w> but only for -subtree, not just packs.
<nekohayo> james_w: well the tree history data is corrupt though, right?
<nekohayo> not corruption in terms of "the hard drive is dying" but..
<james_w> I think check should be catching the problem anyway.
<nekohayo> is there a chance of fixing this?
<nekohayo> is such a merge "expected" to work to begin with?
<james_w> yeah, I think that's right, but as I said it's in an area of the code that I first looked at while debugging your issue, so I have no idea what is going wrong.
<nekohayo> (as I'm very much a bzr beginner)
<james_w> I think it should definitely be fixable, it may require a little bit of surgery.
<james_w> well, it is expected to work. It won't work with no arguments to stop people from doing such a thing by accident.
<nekohayo> you mean it should work with -r0..-1 but not without that, right?
<james_w> however if you specify a "merge base", i.e. a revision to use as the common ancestor, which is what you are doing with -r0..1 then it will do what you want.
<awmcclain> Hi all. I'm trying to debug bzr email notification. Anyone have experience with it? I've set an environment variable POST_COMMIT_TO for every user on the system. Are there any debug logs?
<james_w> but as I said the resulting merge could well be quite suboptimal, as the file-ids are different.
<james_w> awmcclain: I've never used it I'm afraid.
 * awmcclain cries
<james_w> awmcclain: bzr-hookless-email may be useful to you, it's a slightly different approach, and it's a bit experimental, but it suits some projects better than having everyone set up bzr-email.
<james_w> awmcclain: ~/.bzr.log is the best bet for a log.
<awmcclain> mmm, gotcah
<awmcclain> We have a small team, really I'm just looking for global notification on commits.
<james_w> awmcclain: if there is anything that looks relevant stick it in a pastebin and I'll take a gander.
<james_w> the hookless thing monitors a central repo and emails when that repo is changed, by pushing or whatever.
<awmcclain> oooh, sounds promising
<james_w> but, as I said, it's a bit fragile, as it runs outside of bzr.
<awmcclain> mm
<awmcclain> does it live in launchpad?
<james_w> we use it on one project I'm a member of, and sometimes it needs a poke if you notice that you didn't receive an email after a push.
<james_w> I tink so
<james_w> https://launchpad.net/bzr-hookless-email
<james_w> http://bazaar.launchpad.net/~adeodato/bzr-hookless-email/main/annotate/dato%40net.com.org.es-20080214183337-9x3fk8kcstcv8suv?file_id=readme-20070621185945-37182pltao9vro6u-1
<awmcclain> From the bzr-email help: To have bzr send an email you need to configure an address to send mail
<awmcclain> to for that branch. To do this set the configuration option ``post_commit_to``
<awmcclain> What does "set the configuration option" mean?
<awmcclain> Perhaps an ENV var isn't cutting it
<james_w> ah, no, env var is wrong.
<awmcclain> well, there you go.
<james_w> it means a bzr configuration variable.
<awmcclain> ah
<awmcclain> is there a way to globally set those across all branches?
<james_w> if you want it user wide then ~/.bazaar/bazaar.conf
<awmcclain> I want across all branches and users
<james_w> or ~/.bazaar/locations.conf can be used to set it for all branches under a specific path
<awmcclain> hrm...
<james_w> there's no /etc/bazaar.conf unfortunately,
<awmcclain> :(
<awmcclain> ok, so for each user, i need to set that up
<nekohayo> james_w: file-ids? delicious?
<james_w> yeah, sorry.
<james_w> nekohayo: sorry?
<nekohayo> what is that file id thing? :)
<james_w> awmcclain: you could send a message to list about supporting /etc/bazaar.conf if you like.
<nekohayo> why would they be diffrent?
<awmcclain> And I'm guessing that if I didn't set it for a specific user, then when that user commited, it wouldn't email.
<james_w> nekohayo: bzr uses file-ids to identify paths, rather than paths.
<james_w> nekohayo: so when you do bzr mv it keeps the file id. This is how renames are tracked.
<nekohayo> ew
<awmcclain> Are there any conf files stored by branch, rather than user?
<nekohayo> that sounds like it will breakalot, no?
<james_w> nekohayo: however they are generated anew on add without any more specific action.
<james_w> awmcclain: .bzr/branch/branch.conf, but I doubt that setting is propogated.
<awmcclain> how do you mean "propogated"?
<james_w> awmcclain: i.e. it is not copied across when branching, which is obviously not what you want.
<awmcclain> Ah.
<james_w> awmcclain: you could have a quick test to be sure.
<james_w> nekohayo: it has its downsides, yes.
<awmcclain> Well, not a huge problem, since I'm only doing this for our mainline
<awmcclain> Ok, great. Thank you!
<james_w> nekohayo: it should possible to write a plugin to do what you want and merge based on path.
<nekohayo> james_w: does that mean surgery ?
<james_w> awmcclain: no problem.
<james_w> nekohayo: what do you mean.
<nekohayo> yeah, I doubt I could write such a plugin though :)
<nekohayo> well does that mean that it will refuse to merge, conflict everywhere and/or duplicate files/eat files?
<james_w> awmcclain: if you find yourself doing something suboptimal please email the list to ask for something that would suit you better.
<awmcclain> james_w: Will do.
<james_w> awmcclain: I think we have a few downsides to out config file handling, shown by your use case.
<awmcclain> S'ok.
<awmcclain> I <3 bzr
<james_w> nekohayo: conflict everywhere at a guess, so that is obviously the worst outcome in your case.
<james_w> as it doesn't really help you merge the contents of the files.
<awmcclain> As shown by http://www.fluther.com/disc/7307/can-i-import-my-git-repository-into-subversion/
<james_w> awmcclain: nice :)
<nekohayo> so I will have to wait a few work days and see if the mailing list folks have an idea what happened
<james_w> awmcclain: when you write that blog post please swing by here and drop us a pointer.
<james_w> it's always good to read about people's experiences and the features that they like the best.
<awmcclain> Sure thing!
<james_w> nekohayo: I'm afraid so, as I said it's way over my head.
<james_w> nekohayo: unfortunately some of the team is at pycon, so that may slow things down a bit in the next week.
<nekohayo> no problem, your comments were quite insightful :)
<james_w> nekohayo: I'm glad you thought so :)
<AfC> Hey, I just did `bzr commit --fixes 459940` and it bailed with
<AfC> bzr: ERROR: Invalid bug 459940. Must be in the form of 'tag:id'. Commit refused.
<nekohayo> that makes me think... can commit --fixes have multiple numbers? (multiple bugs fixed)?
<AfC> What does that mean?
<james_w> AfC: In which bug tracker is the bug filed?
<james_w> nekohayo: you can give --fixes multiple times.
<AfC> {shrug} GNOME, although I don't see how that's any affair of Bazaar's
<james_w> AfC: you have to tell it the URL and give it a tag, then it would be bzr commit --fixes gnome:459940
<AfC> james_w: bzr: ERROR: Unrecognized bug gnome:459940. Commit refused.
<james_w> AfC: yeah, you have to set it up first.
 * AfC is befuddled
<james_w> AfC: see bzr help bugs.
<AfC> james_w: ok
<james_w> AfC: I'm not a fan of the --fixes implementation.
<james_w> AfC: If you want to tell me the settings you use for gnome I'll submit a patch to make it available by default.
<james_w> AfC: and I'll send one now to link that error message to the help topic.
<AfC> james_w: Will do
<AfC> james_w: where does that fixes information get used? Anywhere in Bazaar itself? (ie, I was about to give you the URL I used, except that I wanted to check it first)
<AfC> james_w: anyway, I used
<AfC> bugzilla_gnome_url = http://bugzilla.gnome.org/
<AfC> {shrug}
<james_w> AfC: no it is just recorded in a revision property.
<AfC> caveat emptor, baby
<james_w> it's not going to start sending mails to anywhere or anything.
<AfC> james_w: I was thinking as I was reading that, by the way, that rather than bugzilla_gnome_url = URL
<AfC> Maybe it could be in a section of its own,
<AfC> perhaps
<AfC> [bugs]
<AfC> gnome = http://bugzilla.gnome.org/
<AfC> Anyway, it being 03:08 I should be abed
<schierbeck> jelmer: ping
<LeoNerd> I think I'll have to write my Ã¼ber-revisioncontrolsystem program sometime
<LeoNerd> One that just looks at -d CVS or -d .bzr or -d .svn or -d {arch} or .... and reruns the command I typed with the right tool
<LeoNerd> I'm forver trying to cvs di in bzr checkouts, or vice versa
<LeoNerd> Hmm.. On second thoughts... bzr mv foo bar   in a CVS checkout might go horribly wrong :)
<unenough> how is darcs next to bzr?
<poolie> unenough: well, the ui is somewhat similar; bzr keeps a record of history whereas darcs does not; bzr typically scales better
<unenough> is there something that admittedly darcs does better?
<poolie> yes, darcs is better at letting you arbitrarily combine patches in different orders
<poolie> though with the caveat that it tends to give confusing merge conflicts, sometimes surprisingly so
<poolie> understand that i have used darcs but am not an expert
<davi> Are the bzr developers already getting the feedback exposed at the emacs email list?
<poolie> yes, though i have not read all of the messages from the weekend yet
<davi> great
<poolie> anything in particular, or just checking?
<davi> "Speed of bzr, how to use it, etc."
<davi> RMS was asking for somebody "to volunteer to work with the Bzr developers"
<poolie> that'd be welcome
<unenough> RMS?
<poolie> the report about log has already got a couple of patches from someone
<davi> RMS:   http://lists.gnu.org/archive/html/emacs-devel/2008-03/msg01761.html
<davi> It is great how bzr is improving
<poolie> yeah
<unenough> what's the M for?
<unenough> whoa his royal majesty stallman himself...
<poolie> 'matthew', fwiw
<poolie> iirc
<davi> yep, Richard Matthew Stallman, http://en.wikipedia.org/wiki/Richard_Stallman
<unenough> i didn't know he is so actively involved in specific projects...that's good to see
<davi> I had to look for it. Wikipedia rocks.
<davi> unenough, He is trying to reduce his involvement in the emacs project. He is overloaded.
<davi> I have read some of the emacs-devel email list. I can be mistaken, but it seems he has designed two emacs maintainers.
<unenough> designed maintainers? :)
<unenough> designated?
<davi> Chong Yidong and Stefan Monnier
<RAOF> No, designed.  He also builds humanoid robots to infiltrate society.
<davi> He is infiltrating our minds. That is very dangerous.
<davi>   (ironic)
* poolie changed the topic of #bzr to: http://bazaar-vcs.org/ | Bazaar 1.3rc1 available for testing | https://edge.launchpad.net/bzr/1.3/1.3rc1
<ubotu> New bug: #202778 in bzr "false test failure when run in a directory containing the version name" [High,Confirmed] https://launchpad.net/bugs/202778
<Peng> Yay
<Peng> bzr-svn is fun!
<Peng> Uh-oh, bzr-svn is only half done importing this branch, and it's already using 300 MB of RAM.
<davi> Speed of bzr
<Peng> ?
<davi> it needs improvement
<davi> at least that is said by some emacs developers
<Peng> Indeed.
<davi> I do not know myself. Unfortunately I have not tried it yet. I am busy with gnuherds.org
<james_w> davi: we are well aware, and it is being worked on.
<james_w> when you do try it, if you have a particular performance issue then come and talk to us.
<Peng> davi: That's an interesting-looking project.
<davi> It is very good to know james_w.  It is great see how bzr is improving!
<Peng> james_w: Think I should send a patch for a one-character typo in NEWS? :)
<davi> james_w, Sure james_w
<james_w> Peng: go for it.
<Peng> :D
<james_w> Peng: have you submitted a patch before?
<Peng> james_w: Oh, yeah.
<james_w> cool, you know how to do it then.
<Peng> james_w: Nothing major, but never anything quite as trivial as this, I think.
<james_w> Peng: if you put (trivial) in the subject, or maybe [MERGE][trivial] it will get picked up quicker.
<Peng> Yep.
<james_w> ah, you're well on top of it I see
<Peng> 75% through, 500 MB of RAM.
<Peng> I'm getting nervous.
<james_w> Peng: you can do an incremental pull if it doesn't make it.
<james_w> Peng: are you using the python-subversion bindings with the memory leak fixed?
<Peng> james_w: In my experience, "doesn't make it" is "swap to death", so that doesn't help much.
<Peng> james_w: I'm using Ubuntu, so they should have at least some of the leaks fixed.
<james_w> Peng: well it starts again, but it will cap the memory usage.
<james_w> only hardy has the leaks fixed.
<Peng> Oh. Shoot.
<Peng> I'm on Gutsy.
<Peng> Oh. Maybe Gutsy just had those compatibility patches. No memory leak fixes?
<james_w> yeah, it was just patches to make it work in gutsy.
<Peng> Crap.
<Peng> Only 4k revisions on this branch. :\
<Peng> Hey, it's done!
<james_w> \o/
<nekohayo> um, how come when merging foo into bar, 7 conflicts are generated, but when resolving those conflicts (or just comparing the folders in meld) there is stuff that was never merged?
<james_w> nekohayo: can you explain what you mean by never merged?
<nekohayo> james_w: hmm... well... maybe I should screencast it
<ubotu> New bug: #202827 in bzr "bzr deadlock itself on commit" [Undecided,New] https://launchpad.net/bugs/202827
<ubotu> New bug: #202830 in bzr "bzr status slow when pending merges" [Undecided,New] https://launchpad.net/bugs/202830
<nekohayo> james_w: could you take a look? wget http://ecchi.ca:8000/strange%20merge.ogv
<nekohayo> am I doing things wrong?
<james_w> hey, I've never done debugging via screencast before :)
<nekohayo> well it's a first :) but is that behavior normal?
<nekohayo> makes me want to go back to the simplicity of centralized repos
<james_w> still downloading....
<nekohayo> yeah, it's about 5mb in size
<james_w> nekohayo: good question.
<james_w> nekohayo: can you annotate that file in the branch in your right hand window and find out what revision it comes from.
<james_w> Then see if that revision is in your left hand branch before the merge.
<james_w> Have you merged these branches before?
<nekohayo> uhm, I don't quite know how to do that
<nekohayo> yeah, multiple times
<nekohayo> but now, it makes me think that they might *not* have merged properly for this very reason
<james_w> ok bzr gannotate the file in the right window before the merge.
<james_w> and find the line that you want. Then read it's revision id from the window.
<james_w> I mean from the bottom, sorry.
<james_w> Then fire up bzr viz in the right hand window, and find that revision.
<james_w> you could also use bzr graph-ancestry and show me that and the revision id.
<james_w> if that line was introduced in a revision that has already been merged it may affect the resulting merge.
<james_w> The other option is to give me pointers to the branches and let me have a look.
<james_w> I'm just going to grab some lunch.
<nekohayo> james_w: sorry I got lost here... could you try merging http://bazaar.launchpad.net/~woutc/specto/specto-woutc into your +junk/specto-jeff ?
<james_w> sure
<james_w> nekohayo: so, why do you expect those lines to show up in -woutc?
<james_w> it appears as though -jeff added the lines since they diverged, is that right?
<nekohayo> james_w: ?
<nekohayo> not sure about that
<james_w> nekohayo: at the end of your screencast you bring up meld with -woutc on the left and -jeff on the right.
<james_w> what were you expecting to happen to the lines that you highlighted there?
<nekohayo> well normally when merging, after resolving the conflict, there should not have been any difference left I presume
<james_w> you have merged -woutc in to -jeff, which means that -jeff no incorporates the changes made by -woutc since they diverged.
<james_w> However it's not going to go changing the files in the -woutc branch.
<nekohayo> hm, but the thing is I never intentionally diverged from -woutc
<nekohayo> (afaik)
<nekohayo> I think pretty much the only option left is to blow up my branch and start anew since it's so messed up
<Peng> If you do, save a copy.
<james_w> nekohayo: hey, that's interesting, the lines do come from an old version of the -woutc branch.
<nekohayo> yeah
<nekohayo> I'm totally confused
<james_w> ah, I think I see what has happened.
<nekohayo> do tell :)
<james_w> ok, so in -jeff rev 17 you merged -woutc. In that merge you kept the lines in question, when they had been removed in woutc
<james_w> ah, no that's not quite right.
<james_w> In that revision you removed the lines.
<james_w> However in the next merge at 18 they were readded.
<james_w> this means when you merge now bzr thinks that you want them, as you added them.
<nekohayo> log for rev 18: "re-merge wout's changes and all that. Seems I lack competence at merging!"
<nekohayo> this means that at rev 17, these were *unintentionally* removed
<nekohayo> as in, "I never even noticed they were gone and was wondering why I was full of bugs!"
<nekohayo> which might have been caused by something similar to the current situation?
<james_w> well it seems rev 18 merges and earlier revision than 17, so that may well confuse things.
<nekohayo> o_O
<nekohayo> I wonder how I managed to weirden things that much
<james_w> yeah, the second merge is of a revision before the lines were removed, so your resolution to take them was not so strange.
<james_w> However bzr will still take the later one as a merge base, and so consider that you wanted the changes.
<james_w> either because you added them, or you merged an earlier version that still had them. It considers that an intentional act, and so doesn't argue with you.
<james_w> I think that is the correct behaviour.
<nekohayo> ok. so, for some reason, lines were lost between 16 and 17, then I pulled them back from 17 to put them in 18, and now it's using 18 as the base, but it adds them all the time ?_?
<nekohayo> actually now I realize that the history graph is quite bizarre in Olive too.
<nekohayo> ugh, I'll just move that specto-jeff to specto-jeff-borked and start fresh, I only had 2 minor commits by me
<nekohayo>   parent branch: specto-0.3      submit branch: specto-jeff
<nekohayo> what is a "submit branch"?
<nekohayo> I've never seen that term before
<james_w> it's what it assumes you want to submit your changes back to.
<james_w> It is what it will use to compare against for bzr send.
<nekohayo> ew
<james_w> It is probably used elsewhere, but for I can't remember which is which.
<nekohayo> any way to remove that?
<james_w> edit locations.conf I think is the way.
<james_w> that's ~/.bzr/locations.conf
<james_w> .bazaar I mean
<james_w> weird, the emacs repo is smaller in bzr than git, I wonder what they've got in theirs that is different.
<dato> several (smallish) repos of mine are smaller in bzr than in git
<dato> (after `bzr upgrade && pack` and `git gc --prune`)
<james_w> I knew packs were good, but not that they were better than git.
<james_w> I thought they were generally smaller than hg, but larger than git.
<james_w> maybe the sample size is too small though.
<james_w> hi dato
<dato> hello james_w
<jelmer> hey james, dato
<james_w> hi jelmer
<Peng> And a new delta format or whatever would greatly reduce the size of packs...
<luks> not that greatly
<Peng> I don't get how it would be a massive improvement, but that's what's been said.
<ubotu> New bug: #202884 in bzr "can't merge" [Undecided,New] https://launchpad.net/bugs/202884
<nekohayo> yeah, that was me :)
<j1mc> hi all - i have a quick question about bzr resolve.  if i'm working on documentation and have a conflict when merging in some changes, can i do a "bzr resolve --all" and then still commit my "conflicts" as a later revision?
<Peng> Why not resolve them?
<Peng> That makes for kinda sucky history.
<Peng> Also, I'm not sure which file "bzr resolve" would keep. It might not do what you want.
<j1mc> Peng: the conflicts are updates that i've made to my own branch, while someone else has made changes to the repository.
<j1mc> i know that i can copy my changes out to another directory, do a 'bzr revert" on the changes i've made, and then merge things in...
<j1mc> and then re-copy my changes and commit them.
<Peng> j1mc: Wait, have you committed your changes?
<Peng> Err.
<j1mc> no, not yet.
<Peng> You shouldn't merge with uncommitted changes..
<j1mc> if i commit my changes, and then merge... what will happen if their are differences between the repositories and my branch?
<j1mc> (when i go to push my changes back up)
<Peng> D'oh, I just wanted to say something to nekohayo.
<j1mc> Peng: what would you recommend in this situation.  i'm sure others have run into this before.
<Peng> j1mc: I'd recommend committing (or shelving your changes) before merging, and resolving the conflicts immediately. Doing other things would pollute the history.
<j1mc> so - bzr commit -m "whatever"... then bzr merge (which is likely to indicate conflicts)... then bzr resolve... then bzr push?
<spiv> j1mc: you'd need to commit after the merge
<spiv> j1mc: a merge is a change to the tree just like any other, so it isn't recorded until you commit it.
<j1mc> spiv: thanks.  yes.  so in my example above, the second commit would come after i completed the merge (with all conflicts resolved), but before the push.
<spiv> j1mc: so you'd commit your work, then do bzr merge + resolve conflicts (if any) + bzr commit -m "Merged branch X.".
<spiv> Right.
<j1mc> thanks, spiv and Peng
<spiv> So you're keeping your changes in separate revisions to the changes you're merging in.
<j1mc> will pushing back up my changes after doing the above show the previous person's revisions as (1) reverted changes done by me, and then (2) changes committed by me (even though they were the one who made the updates the to the repository?
<spiv> j1mc: pushing will make the remote branch be the same as your local branch
<spiv> j1mc: are you and the other person both pushing to the same branch?
<j1mc> spiv: yes
<spiv> j1mc: it'll probably be less confusing if you both use a checkout of that branch, rather than independent branches that you then push over the top of the central branch.
<spiv> j1mc: you can reconfigure your current branch to be a checkout by using "bzr reconfigure --checkout"
<j1mc> spiv: so do bzr checkout instead of bzr merge?
<spiv> j1mc: then when you do "bzr commit" the new revision will be added directly to the master branch.
<spiv> j1mc: you'd generally then both use "bzr update" + "bzr commit" rather than "bzr merge" + "bzr commit".
<j1mc> ok.  thanks for your help.  i feel a bit like i'm a total noob, but i just don't want to keep making the same mistakes.
<j1mc> ok
<spiv> j1mc: http://doc.bazaar-vcs.org/latest/en/user-guide/index.html#team-collaboration-central-style describes the workflow I'm talking about.
<j1mc> thanks.  i had committed my changes, bringing me from revision 3657 to 3658, and then merged in the updates from the server, but have not yet committed them.
<j1mc> i did a bzr revert, which "unmerged" the merges, and have copied my changes to a different dir.  how can i do a bzr revert to get back to 3657?
<j1mc> i think i got it...
<j1mc> bzr revert -r 3657
<spiv> j1mc: that will give you a copy of the files at 3657, but it doesn't uncommit the last revision
<spiv> j1mc: so e.g. "bzr revno" will still say 3658, and "bzr status" will report that there are changes (because the files in the tree aren't identical to 3658).
<spiv> j1mc: so depending on what you want, you may want to use "bzr uncommit" as well.
<j1mc> spiv: thanks so much.
<spiv> j1mc: not a problem.
<j1mc> doing the bzr reconfigure --checkout was a big help, and will prevent embarrasing "uncommits/recommits" of other people's work going forward.  so thanks for taking the time to understand my problem.  have a good day!
<Odd_Bloke> Morning.
<Odd_Bloke> james_w: _Now_ I'm sleeping and waking at the wrong times. :p
<schierbeck> hi guys
<schierbeck> i've been thinking -- why are bugfix markers revision properties?
<schierbeck> i mean, only one revision can actually fix a bug
<schierbeck> so wouldn't it make sense to have it be a branch property?
<schierbeck> unless you count in regressions...
<nekohayo> Peng: the specto-main branch comes from having branched a svn tree
<nekohayo> is it what made it a  rich-root-pack?
<Odd_Bloke> schierbeck: If only one revision can actually fix a bug, then surely having it as a property of that revision makes sense?
<nekohayo> do I need to fix it in some way?
<lwnjake> anyone know about fast-import errors when trying to convert a git repo?
<Odd_Bloke> If, however, a series of revisions are needed to fix the bug, _then_ I think having it as a branch property would make sense.
<james_w> Odd_Bloke: :-)
<lwnjake> or should i use tailor instead?
<schierbeck> Odd_Bloke: but many revisions can then  mark the same bug as fixed
<Odd_Bloke> Where I take 'need' to mean 'need to pull/merge into your branch to fix the bug'.
<Odd_Bloke> schierbeck: I don't know, I wasn't disagreeing with you per se. :p
<Odd_Bloke> Anyhow, I need to grab some breakfast^Wdinner.
<schierbeck> i was thinking more of a mapping from bug id to revision id in the branch itself
<schierbeck> hehe
<james_w> lwnjake: hi.
<james_w> lwnjake: the importer is still pretty rusty.
<lwnjake> james_w: howdy
<james_w> lwnjake: if you want to paste your error I can see if it's something obvious.
<lwnjake> so is tailor the right way to go?
<lwnjake> bzr: ERROR: Revision {('jake@lwn.net-20080127054407-u8wwscgv6ze5vumc',)} not present in "<bzrlib.knit.KnitGraphIndex object at 0xcaaa42c>".
<james_w> lwnjake: you probably stand more of a chance with tailor.
<james_w> but I've heard it's a bit of a pain.
<lwnjake> heh, thanks! :)
<Odd_Bloke> schierbeck: Well, my thinking is that I often don't fix a bug in one cherry-pickable revision, so setting a bug-fix property on that revision makes the assumption that all of its history comes with it.
<james_w> lwnjake: that's odd. Do you get a traceback?
<lwnjake> nope, just that ...
<Odd_Bloke> Of course, I may simply not understand how cherry-picking revisions works. :)
<james_w> lwnjake: did it take a long time to get there?
<lwnjake> no, it is a pretty small repo and it did put out: 10:57:47 1000 commits processed (:3937)
<lwnjake> before failing
<lwnjake> less than a minute for sure
<lwnjake> i tried exporting --all from git and just master from git with more or less the same results
<james_w> ok, would you mind running again under "bzr -Derror" so that we get some more information? I can file a bug from that then.
<james_w> or if the project is public could we just have the dump file?
<lwnjake> should rm .bzr and reinit?
<lwnjake> unfortunately not public
<james_w> ok.
<james_w> you should just be able to run again.
<dato> james_w: tailor will work just fine if there are no merges
<james_w> lwnjake: you can use --checkpoint to make it save state more often, it will then resume from their next time.
<lwnjake> what repo on earth has no merges?
<james_w> though it's not much use if you're just going to use tailor.
<james_w> dato: ah, thanks.
<lwnjake> git-fast-export master | bzr -Derror -fast-import -bzr: ERROR: bzrlib.errors.BzrCommandError: unknown command "-fast-import"\
<lwnjake> does the -Derror need to be somewhere else on the command line?
<james_w> "bzr -Derror fast-import"
<lwnjake> oh, duh!  thanks
<james_w> we have a set of global debugging flags all named -Dsomething.
<james_w> -Derror just ensures you get a traceback from all exceptions.
<james_w> we inhibit exceptions for things that are user errors.
<lwnjake> want me to email it to you?  it is rather long ...
<james_w> However I don't think this one should be classed as a user error.
<james_w> lwnjake: yeah, that's fine.
<james_w> jw+debian@jameswestby.net
<lwnjake> on its way ...
<ubotu> New bug: #202928 in bzr "bzr diff slow against ancestor" [Undecided,New] https://launchpad.net/bugs/202928
<james_w> lwnjake: thanks.
<lwnjake> james_w: no prob, now i'll try tailor and see how that goes ... thanks!
<james_w> nekohayo: it looks like your issue may be reproducible against bzr.dev itself. That should certainly speed things up if it is the same bug.
<james_w> lwnjake: no problem. Pop back if tailor doesn't do the job, and we can try and fix up fast-import
<nekohayo> james_w: great!
<james_w> lwnjake: oh, and there is also some support in bzr-git for pulling, so we could try that too.
<nekohayo> james_w: so does that thing boil down to having dirstate not working with format rich-root-pack?
<james_w> Peng: (of course) <- :-)
<james_w> nekohayo: I have no idea I'm afraid.
<james_w> nekohayo: though they do work together.
<james_w> nekohayo: dirstate here refers to a knit based repo format. dirstate itself is the fast working tree format that was introduced a few releases ago, and hence gave it's name to the whole format.
<james_w> It appears something is wrong with some knit based repos where the data is inconsistent.
<nekohayo> oh
<Peng> Wait, two people with missing indexes thanks to conversions?
<Peng> Err, missing revisions in knit indexes, or whatever.
<james_w> lwnjake: I can't immediately see what's wrong I'm afraid.
<lwnjake> james_w: too bad, tailor seems to be annoying ... so far i haven't got it to work, but i am off on other things now
<james_w> lwnjake: fair enough. Give us a shout if you have another go.
<spiv> Ian will probably be finished lunch shortly.
<spiv> He might be alble to help.
<RyanRyan52> is there an apache module for bazaar like there is for subversion?
<Peng> RyanRyan52: No.
<RyanRyan52> Is there any way to do something like that?
<Peng> RyanRyan52: You can serve over regular dumb HTTP, or use the faster smart server with CGI, FastCGI, mod_wsgi or something like that.
<RyanRyan52> but then you still have to have bzr to use it, right?
<Peng> RyanRyan52: What? Oh, that's what you want?
<Peng> RyanRyan52: Well, you could set up a web viewer. Loggerhead, bzr-webserve, bzrweb..
<RyanRyan52> I want to also be able to look at my code through a web browser
<RyanRyan52> thanks
<Peng> RyanRyan52: If you have your branch hosted or mirrored on Launchpad, it has a Loggerhead installation.
<RyanRyan52> I can't do that...
<RyanRyan52> Its not my project. I have to host it on the owners server.
<RyanRyan52> but he will let me switch it to bzr if I get all of the things working as well or better as they did with subversion
<jelmer> hey Ian
<jelmer> How's Pycon?
<radix> good
<radix> >:)
<Peng> There's a couple messages in comp.lang.python saying it sucks. That it went all commercialized.
<jelmer> radix: :)
<jelmer> spiv: It's a pity the pyrex stuff wasn't ready before pycon, it really rocks
<Peng> What Pyrex stuff?
<jelmer> Peng: bzr-svn using pyrex
<Peng> Oh, cool.
<Peng> Significant benefit?
<Peng> Wait, would you use svn's C API then?
<jelmer> yes, pyrex around svn's C API
<Peng> Interesting.
<jelmer> instead of the SWIG-generated bindings by the subversion folks
<jelmer> all memory usage problems have gone away
<jelmer> cloning samba4 now gives me a bzr process that uses less than 30Mb of RAM
<jelmer> where it would previously be at least 300
<Peng> Wow.
<jelmer> I haven't completed a clone successfully yet though, but it's looking very good
<Peng> Y'know, there's Cython now...
<jelmer> cython generates larger files than pyrex unfortunately
<Peng> It's supposed to be Better and Faster and Stronger though, right?
<Peng> Hmph, bzr-svn causes constant repacking.
<jelmer> Peng: yeah, hopefully that'll change when RevisionLoader from bzr-fastimport gets merged into core
<spiv> jelmer: should I try using your pyrex branch here?
<spiv> jelmer: or is it still too raw? :)
<igc> jelmer: I'd suggest including revisionloader.py in bzr-svn rather than waiting for it to merge into core
<igc> at least we can speed up bzr-svn a fair amount that way
<spiv> jelmer: nice
<spiv> jelmer: I really like the sound of your pyrex stuff
<igc> james_w: I started tracking down that 'unknown revision' bug in fastimport
<james_w> igc: the one that lwnjake was having?
<igc> I think so
<igc> there's a bug registered already for ...
<james_w> cool, do you have an idea what it is yet?
<igc> imports from hg-fast-import
<igc> the bug looks generic though
<igc> it's related to per-file-graph tracking
<igc> line 111 of revisionloader.py
<igc> I'm yet to get some uninterrupted time to really think it though
<james_w> igc: I was looking at that, but it looked pretty sane to me.
<james_w> It seemed as if you would only pass parents that you had already generated.
<igc> james_w: abentley explained what the code does in London
<james_w> I'm sure I will have missed something.
<igc> he did find a buglet but ...
<igc> this problem is something different
<igc> probably
<james_w> lwnjake: https://bugs.launchpad.net/bzr-fastimport/+bug/201116 and https://bugs.launchpad.net/bzr-fastimport/+bug/197755 might be of interest if you want to track progress
<ubotu> Launchpad bug 201116 in bzr-fastimport "ERROR: revision not present" [Undecided,New]
<james_w> igc: is pycon over with?
<igc> in the last set of lightning talks
<igc> there the sprint tutorials kick off
<james_w> ok.
<igc> jam is doing the sprint leaders roundtable real soon now
<igc> spiv and I will do the tutorials after that
<james_w> As there is an export stream in the later of those two bugs I can have a look some time this week if you don't get to it first.
<igc> it's reproducable using libmemcached's export
<james_w> cool.
<Peng> jelmer: You said Pyrex bzr-svn really improved memory usage, but what about speed?
<james_w> Peng: the revisionloader should improve that for initial import and subsequent pulls.
<awmcclain> Ug... this is so frustrating. What's the easiest way to see all the diffs in a particular revision?
<awmcclain> s/revision/changeset
<dato> awmcclain: as in `bzr diff -c $revspec` ?
<awmcclain> yay! yes.
<Peng> Huh. I'm running bzr-svn, with the constant repacking, and it seems one is kept just about every half hour.
<lifeless> moin
<thumper> lifeless: morning
<thumper> what's the quickest way to get the set of revision ids in a branch's ancestry?
<thumper> in bzrlib (obviously)
<dato> thumper: mainline or all?
<thumper> dato: all
<thumper> well, even an iterable would probably do
<dato> then I don't know :)
<thumper> I'm thinking of an optimisation for 'missing --mine-only' that I use a lot
<thumper> basically I want to know if my branch has been merged fully or not
<thumper> dato: branch.repository.get_ancestry(rev_id)
<thumper> but I'm not sure if that is the fastest
<mwhudson> i guess branch.repository.get_revision_graph(rev_id).keys() might be faster
<mwhudson> as it doesn't order the results
<mwhudson> oh er get_ancestry(rev_id, toposorted=False)
<mxpxpod> I noticed that bzr-svn 0.4.8 came out... are there any plans to package it for gutsy?
 * eikeon having hard time getting bzr split to work using bzr 1.2.0. I'm trying to split off a subtree into its own branch. I'd love it if someone could point me in the right direction?
<james_w> mxpxpod: hopefully we will
<AfC> jelmer: tinsy bug report: when you have the bzr-svn plugin misnamed in ~/.bazaar/plugins,
<AfC> `bzr plugins` says something about "try renaming it to bzr_svn"
<AfC> whereas the correct name appears to be "svn"
<mxpxpod> james_w: thanks
<poolie> good morning
<james_w> AfC: that's bzr's fault
<james_w> hi poolie
<james_w> AfC: the problem is that if it is misnamed the plugin gets no say in what its name should be.
<AfC> Delightful
<james_w> perhaps splitting "bzr_" would be sane
<james_w> s/splitting/stripping/
<AfC> yeah
<poolie> jml: are you coming here today?
<AfC> seems a pretty common misconfiguration
<james_w> AfC: indeed especially if you bzr branch lp:bzr-svn
<jml> poolie: yep
<jml> poolie: I'm getting a haircut first
<AfC> james_w: I'm about to drop off for a bit. If you think it worthy, can you file something?
<james_w> AfC: a patch is probably easiest, so I might go with that. I'll take care of it though.
<AfC> james_w: you rock
<james_w> rarely, I prefer a nice sit down and a cup of tea.
<poolie> jml, ok, great
 * eikeon wonders what format I should have my repo and branch in such that I can use bzr split?
 * eikeon currently trying rich-root
<james_w> eikeon: rich-root might work. subtree definitely will.
<james_w> However split is still experimental, so it may not even work for you.
<eikeon> Ah... good to know. /me doesn't see subtree listed in bzr help formats
<james_w> bzr upgrade --pack-with-subtree might be it.
<james_w> it's hidden as having your repo as subtree can enable behaviour that can be entirely the wrong thing for some people.
<james_w> rich-root stores the data needed, but without giving the extra functionality.
<eikeon> I'm ultimately trying to break up one branch I've been working on into two. In svn land I used to like putting several projects under a common root. So started doing that in bzr land before I realized the difference :|
<lifeless> thumper: getting the entire set is a bad idea; its extremely likely to be a pessimisation
<Odd_Bloke> eikeon: In the cases where that's been the case for me, I've explicitly removed one project from two branches.  They did start as related, however.
<thumper> lifeless: how would I get an interable then?
<eikeon> Odd_Bloke: That might work well for me too. Thank you. /me thinks how to shuffle things around to get rid of extra level of directory in that case.
<lifeless> thumper: repository.get_graph()._make_breadth_first_searcher([branch.last_revision()])
<lifeless> thumper: which I think missing already does
<lifeless> in .dev
<thumper> lifeless: ok
<lifeless> thumper: My suggestion is as a first step to file a bug tagged performance
<thumper> lifeless: I was also curious for my own playing with bzrlib
<Odd_Bloke> Does anyone know what the status of getting either the 1.2 release or 1.3rc1 into unstable is?
<dato> debian?
<Odd_Bloke> Yeah.
<dato> I'm planning on uploading 1.3rc1 tomorrow morning
<Odd_Bloke> OK, cool. :)
<lifeless> thumper: oh sure
<lifeless> thumper: and I'm happy to keep answering questions
<poolie> good morning lifeless
<lifeless> hi poolie
<mxpxpod> is there a way to get a bzr log with svn revision numbers using bzr-svn?
<kkubasik_> afternoon all :)
<poolie> mxpxpod: i don't know, ask on the list
<poolie> hello pycon
<jelmer> mxpxpod: not yet
<jelmer> mxpxpod: there's an open bug about it
<mxpxpod> jelmer: ok, thanks
<Peng> You could tag every single revision. How well does bzr do with 60,000 tags?
<poolie> probably ok, but it's not a great solution
<moebius_> hello, I have a weird error using bzr 1.2
<moebius_> AttributeError: 'HttpTransport_urllib' object has no attribute '_remote_is_at_least_1_2'
<poolie> hello lamont, moebius
<lifeless> poolie: I don't think we'd do well on 60K tags
<lifeless> poolie: because we'd download the entire tags file on push and pull; its not versions and does not have an incremental transfer format
<poolie> hm
<poolie> true
<cavanaug> anybody know where i can find a bzr-svn for cygwin??   I tried last night to compile everything but failed miserably...
<moebius_> hello
<moebius_> I have a weird error with bzr 1.2
<moebius_>   File "/home/acastro/Desktop/bzr-1.2/bzrlib/remote.py", line 821, in _get_parent_map
<moebius_>     if not medium._remote_is_at_least_1_2:
<moebius_> AttributeError: 'HttpTransport_urllib' object has no attribute '_remote_is_at_least_1_2'
<moebius_> is this known? i haven't seen any bug reports on this
#bzr 2009-03-09
<Kobaz> https://bugs.launchpad.net/bzr/+bug/197426
<ubottu> Ubuntu bug 197426 in bzr "bzr diff message when some files are not versioned is unhelpful" [Medium,Confirmed]
<Kobaz> there's the bug
<lifeless> jam: any comments?
<lifeless> mwhudson: so, its good you're looking
<lifeless> mwhudson: break out the profiler.
<lifeless> jam: the Collapsed 1 keys into 1 requests w/ 1 file_ids w/ sizes: [306]
<lifeless> jam: is a little noisy
<jam> lifeless: take it out
<jam> BB:approve
<jelmer> lifeless, cool, I'll try it out this week (re subunit)
<jelmer> jfroy, pong
<jfroy> jelmer: I made a checkout of a very small svn repository (< 10 revisions) that had never been used with bzr-svn today, and when I tried to commit back, I got a "Could not determine revno for <...> because its ancestry shows a ghost at <...>" error.
<jfroy> I can send you the repo if you want, it's pretty easy to reproduce.
<jfroy> Both bzr and bzr-svn dev.
<jelmer> jfroy, If you have an easy way to reproduce it, please file a bug against bzr-svn
<jfroy> OK
<jfroy> I'll just attach the repository in the bug.
<jfroy> https://bugs.launchpad.net/bzr-svn/+bug/339749
<ubottu> Ubuntu bug 339749 in bzr-svn ""Could not determine revno because of ghost in ancestry" error on commit to bound branch" [Undecided,New]
<jfroy> added repro steps
<jelmer> jfroy, works fine here
<jfroy> does it?
<jfroy> mmmm
<jfroy> let me update bzr and bzr-svn
<jelmer> jfroy, it works with 0.5.2 as well
<jelmer> ah
<jelmer> I can now
<jelmer> it looks like a regression in bzr
<jelmer> 1.12 works fine, bzr.dev breaks
<spiv> jelmer: hmm!
<jfroy> mm, I still get the error here
<jfroy> jelmer: ahh, sorry didn't read your message before that last one
<jfroy> OK
<jelmer> ah, hmm
<jelmer> might be a bug in bzr-svn after all
<jelmer> but indeed a regression
<fbond> Hm, anyone know why bzr-loom has replaced bzr stat?  I'm not a fan of the changes.
<lifeless> fbond: because it tells you about the loom, its been doing it for a while
<lifeless> bbiab
<mwhudson> lifeless: i think this summarizes my loggerhead performance playing http://pastebin.ubuntu.com/128584/
<lifeless> jam: http://pastebin.ubuntu.com/128584/
<LaserJock> can you do the equivalent of svn copy with bzr-svn?
<lifeless> igc: http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C1236512117.31799.2.camel%40lifeless-64%3E - this recasts the fix you did to get profiling data when ctrl-C is hit to not break layering
<lifeless> igc: it will make profiling easier for mwhudson [when things go wrong]
<lifeless> igc: please eyeball :)
<poolie> lifeless:  that looks pretty sweet
<lifeless> poolie: good!
<spiv> lifeless: en_AU.UTF-8
<lifeless> python -Werror ./bzr selftest test_parents.*test_unicode_symlink -v
<poolie> fails with
<poolie> bzr: ERROR: exceptions.DeprecationWarning: the sha module is deprecated; use the hashlib module instead
<poolie> i need to patch it to ignore that
<poolie> there's a jaunty bug open
<igc> for me, 4 errors all the same: Unicode unequal comparison failed to convert both arguments to Unicode - interpreting them as being unequal
<poolie> DBusException: org.freedesktop.DBus.Error.Spawn.ChildExited: Launch helper exited with unknown return code 0
<jam> lifeless: tests fail with 32-bit python 2.5.2 on Hardy
<spiv> FWIW I also get that failure, 32-bit python 2.5.2 intrepid.
<mwhudson> spiv: which test?
<spiv> mwhudson: 17:20 < lifeless> python -Werror ./bzr selftest test_parents.*test_unicode_symlink -v
<mwhudson> ah
<ja1> mwhudson: lifeless just told me that you need to update your brisbane-core branch
<ja1> I did some updates that should make things like "log -v" faster
 * mwhudson gives it a go
<mwhudson> ja1: https://pastebin.canonical.com/14708/
<mwhudson> maybe i need a new groupcompress too?
<mwhudson> mm, only a little faster
<pysquared> Hello again, could someone help me please.  Been using bzr for a few weeks, have a stable branch and several development ones.
<pysquared> I want to add some of the modules created in a dev branch to stable, without creating problems for future merges.  What to do?
<bialix> hi, any English people here?
<bialix> bzr st now shows the message: pending merge tips: (use -v to see all merge revisions)
<bialix> I'm curious why there is "see all merge revisions" but not "see all merged revisions"?
<bialix> anybody?
<pysquared> Seems a bit quiet in here at the moment.  Sorry, I don't know the answer, not seen it myself yet.
<bialix> pysquared: English is foreign language for me. Do you native English speaker?
<Peng_> bialix: Maybe it's to help make it clear that the revisions haven't been committed yet.
<bialix> what's difference? they're anyway mergeD already
<Peng_> Since it says "pending", I guess that's redundant anyway.
<bialix> is not "merge" is a verb?
<bialix> "all merge revisions" sounds odd for me
<Peng_> English is my first language, but I'm kind of terrible at it, so... :P
<bialix> heh
<bialix> bzr.devs travelling now I guess
<Peng_> bialix: I think "merged" would sound more natural, but it doesn't bother me. I think "merge" is sometimes used as a noun.
<bialix> "merge revisions"?
<bialix> in my language it should be "merged revisions"
<bialix> but my language is not English
<Peng_> I guess "merge" would be an adjective describing the revisions?
<bialix> yep, I guess so
<bialix> hence my question
<Peng_> "merge revisions" is used like that throughout bzrlib.
<bialix> actually 12 times, and half of that count related to status output
<bialix> ok, I'm just curious
<Peng_> Oh, sorry. I made a mistake when grepping and through it was used about 30 times.
<Peng_> Err, s/through/thought/
<bialix> does not matter. it's used even for log command
<bialix> and there revisions are definitely "merged"
<bialix> perhaps it's just my shallow knowledge of English
 * SamB wonders why the logs link in the topic doesn't link to this channel's logs
<SamB> oh, I guess it's because the logs are broken down first by year ?
<SamB> what a strange way to organize logs
<Peng_> bialix: I don't have a deep understanding of bzr's internals, so I don't know if the concept of a "merge revision" (a revision that, well, did a merge) makes sense, but I think it does.
<Peng_> bialix: Whether it's a better term than "merged revision" in "bzr status" is another matter.
<bialix> Peng_: I don't understand
<bialix> Peng_: in log.py the "merge revisions" used in the context: "show me merged revisions"
<Peng_> bialix: I think the term "merge revisions" makes sense in some situations, but in others it's a mistake.
<Peng_> bialix: But I could be way off.
<bialix> hi jam
<Peng_> It makes sense *to me*, but might not be right.
<jam> hi bialix
<bialix> I've asked about "merge revisions"
<bialix> bonjour vila
<bialix> jam: why "merge revisions" but not "merged revisions"?
<Peng_> ja1: wb?
<ja1> network here is a bit weak
<ja1> bialix: "merge revisions" where is that?
<Peng_> jam: The output of "bzr status" after "bzr merge", and some other places.
<bialix> jam: bzr st now shows the message: pending merge tips: (use -v to see all merge revisions)
<bialix> ja1: ^
<bialix> ja1: are you in UK at sprint?
<poolie> bialix: hello
<poolie> we're in brisbane, australia
<bialix> hi poolie
<bialix> ah
<poolie> and john's here, though not here right at the moment
<bialix> sorry
<poolie> np at all
<poolie> we might have a sprint at the time of UDS in late May in Spain
<bialix> poolie, I'm curious about "merge revisions" vs. "merged revisions"
<poolie> in case you're interested in coming...
<poolie> ok
<bialix> bzr st now shows the message: pending merge tips: (use -v to see all merge revisions)
<bialix> "merge revisions" sounds odd for Russian mind. Is not "merge" is a verb?
<ja1> bialix: We're in brisbane, but yes
<vila> hi bialix
<bialix> vila too?
<vila> bialix: yup
<bialix> interesting... how do you know that... about Brisbane and Brisbane-core?
<bialix> fantastic
<vila> but I will go to sleep in a few minutes, jetlag is still hard...
<poolie> sleep well
<vila> thanks
<poolie> bialix: 'merge' is a verb, but in this context i guess it can be used as a noun
<poolie> 'commit' is similar
<poolie> so is 'diff' for that matter
<poolie> i think there's a semantic difference that 'merged revisions' are the ones that were merged in
<bialix> poolie: it seems like in the "merge revisions" it's used as adjective
<poolie> but the 'merge revision' is the one that did the merging
<poolie> this might be a bit subtle or potentially confusing though
<poolie> yes, it is an adjective there
<bialix> poolie: in log.py there is some places too, where "merge revisions" used in context of "show me merged revisions"
<poolie> just in comments or parameters, or also for ui?
<bialix> comments/parameters
<bialix> int he log help there is "merged revisions" used
<bialix> in the log help
<poolie> so i haven't checked them, but it'd probably good to change them to 'merged'
<bialix> and also "a nested merge revision"
<bialix> I'm just trying to understand English better
<Peng_> poolie: I agree with you about the semantic difference. Thank you for articulating it well. :)
<bialix> then "merge revisions" == "merged but not committed yet", right?
<poolie> bialix: it might be 'revisions that did a merge'
<poolie> normally we'd say 'pending merge revisions' to mean not committed
<bialix> what it means? 'revisions that did a merge'
<poolie> revisions that have more than one parent
<bialix> ah, ok
 * bialix disappears
<lifeless> abentley: something like:
<thrope> any bzr hosting other than launchpad available yet?
<Odd_Bloke> thrope: Any server providing SSH access can do it. :)  But no other centralised hosting that I'm aware of.
<lifeless> thrope: savannah, alioth, gna, ...
<thrope> anything for private projects?
<lifeless> thrope: I don't know; lp can do private projects though
<thrope> oh i didnt know
<thrope> thanks
<SamB> hmm, how come pybaz doesn't have a launchpad project ...
<jelmer> SamB, I think it's dead upstream
<jelmer> and its source is not in bzr
<SamB> jelmer: which upstream?
<jelmer> SamB, both baz and pybaz
<SamB> pybaz is the Python library for reading baz/tla, isn't it ?
<jelmer> yes, but it wraps around the baz command line I think
<SamB> OH.
<rocky> jelmer: what is the standard way to run the tests on TracBzr, do you know?
<jelmer> I just ran "trial tracbzr" IIRC
<rocky> trial ?
<SamB> EWWW
<rocky> oh trial seems to be a twisted test harness
<SamB> well, twisted uses trial at any rate
 * SamB said EWW because he found out that jelmer was right
<jelmer> rocky, trial isn't really tied to twisted though, it's just a test runner
 * SamB closes the RFP he had started writing
<jelmer> SamB, EWW?
<SamB> jelmer: well, I suppose however you implement something like that has got to be disgusting ...
<jelmer> SamB, well, it's all legacy code, anyway
<rocky> jelmer: i'm trying out nose ... seems to work... but just an fyi i restarted the fix to that _get_weave bug since i know a lot more now and i've done it on a separate branch
<rocky> jelmer: i'll set it up for review today
<rocky> also gonna add tests
<SamB> jelmer: recall that it also does tla
<SamB> baz may be legacy, but unfortunately tla isn't :-(
<SamB> or should I say "did"?
<jelmer> SamB, Are you sure it does tla as well?
<SamB> admittedly some people are still using tla only because they haven't figured out how to escape yet
<SamB> jelmer: well, okay, supposedly it can import Arch branches
<jelmer> SamB, ah, but that's probably because the repo formats from arch and baz are compatible?
<SamB> I was kind of hoping pybaz actually understood the format
<SamB> anyway, my point is, while baz may be legacy, the format is unfortunately not and tools for importing (or foreign-branching) it would still be useful
<SamB> at this point, the easiest way to use an arch repository is probably through git-archimport
<SamB> or is it just git-arch ...
<SamB> well, that also runs a command-line tool ... maybe it would be good to add tla support to pybaz?
<SamB> (that is, git-archimport uses tla internally)
 * SamB accidentally finds the GPL'd TLA FAQ in his googles and contemplates a BSD'd TLA FAQ
<jelmer> SamB, well, baz and pybaz are still there
<jelmer> SamB, and as far as I know they work
<jelmer> so there shouldn't be a particular reason to go through git
<jelmer> awilkins, hi
<jelmer> awilkins, any chance you can file a bug about that branch issue you mentioned yesterday?
<jelmer> I can reproduce it
<awilkins> jelmer: np.
<awilkins> https://bugs.launchpad.net/bzr-svn/+bug/339974
<ubottu> Ubuntu bug 339974 in bzr-svn "AssertionError on branching mythtv.org svn repository" [Undecided,New]
 * mtaylor hates to ask this question...
<mtaylor> anybody know where I can get recent bzr rpms for SuSE 10.3 ?
 * mtaylor cries when people use SuSE
<awilkins> God kills an iguana when people use SuSE
 * awilkins thinks that might have been funnier if he said "chameleon"
<rocky> jelmer: i just proposed my bug branch for merging into trunk for TracBzr
<phinze> ugh, there's nothing that hurts more than a mis-resolved conflict in your history
<mamruoc> hello people, I can't seem to find how to ignore changes on commited files
<mamruoc> ?
<rocky> lifeless: hey... if i have a revid and i know what repo it came from, i should be able to figure out which branches in that repo has that rev applied right?
<rocky> lifeless: which would NOT be the case if i had the revno (and no branch nick)
<Peng_> mamruoc: You can't. You could use "bzr rm --keep whatever.txt" if you want to stop versioning it.
<mamruoc> Peng, shouldn't this been a feature bzr should have?
<NCommander> Is it possible to take a CVS checkout, and then import the versions that are present in that checkout into CVS?
<Peng_> mamruoc: Yes, but it doesn't.
<Peng_> NCommander: There are, um, CVS to bzr converters that can work remotely..
<NCommander> Peng, I'm not being clear
<NCommander> I have a working tree, from abotu six months ago
<NCommander> I want to convert history from that point into bazaar, but nothing from the future
<phinze> hmm i'm having trouble pushing to a new lp branch... bzr: ERROR: File exists: '/srv/bazaar.launchpad.net/push-branches/00/00/97/8a/.bzr'
<phinze> any clues on how to fix this?
<mamruoc> Peng, are the any ongoing work for this?
<phinze> hmm i had registered branch prior to pushing, and deleting the branch in lp and just pushing seems to have worked
<phinze> for the convenience of anyone looking for the code until the server goes back up, and i'm sure for the annoyance of sid3w1nder...
<phinze> https://launchpad.net/bitlbee-snapshot
<phinze> :)
<Peng_> mamruoc: I don't know of any.
<phinze> oh crap
<phinze> wrong channel
<phinze> why do i keep the two "b" channels next to each other
<Peng_> NCommander: Oh. I dunno. Worst case, convert the whole thing, then "bzr uncommit" or "bzr branch" to get rid of it.
<NCommander> Peng, oh yay, uncommitting a year of commits -_-;
<NCommander> Is there a good guide on how I go about doing this? (or should I just let Launchpad's CVS importer work)
<Peng_> NCommander: uncommit can handle multiple revisions at a time.
<Peng_> Sorry, I dunno.
<rocky> hey ... i'm working on code in a branch ... i did a merge from another branch and forgot to commit it ... i since then changed more code and was about to commit when i realized my changes are messed up with the merge  commit ... is there anyway to separate the merge changes and my local changes at this poi8nt?
<Peng_> rocky: You could use "bzr shelve" to temporarily get your new changes out of the way.
<Tak> or unmerge, commit, remerge(, commit)?
<rocky> Tak: ah that's what i was looking for
<rocky> thx
<Peng_> Oh, you had committed the merge? Sorry I misunderstood.
<rocky> no i hadn't committed the merge
<rocky> which means i misunderstood ;)
<Peng_> Oh.
<rocky> does anyone know if branch.revision_history() ever changed such that once it listed individual merge items VS now just returning the revision belonging to the complete merge?
<rockstar> Hm, the last Planet Bazaar post was on March 3.  Surely something is wrong.
<Odd_Bloke> rockstar: "Last updated: March 03, 2009 11:06 AM" <-- looks like it
<jfroy> with all the talks about changing the default branch format, the thought occurred to me: would it be useful to have a configuration variable for the default repository / branch format?
<Peng_> jfroy: I'm not sure it's worth the confusion it could cause. Since DVCSes are all about collaborating with other people, I think it's best for everybody to be in the same default format boat.
<Peng_> jfroy: OTOH, always typing "bzr init-repo --1.9" is getting old... :P
<jfroy> Peng_: well they are changing it to 1.9 :p
<Peng_> ...Good point.
<jfroy> I had in mind my workflow, which involves creating repos with 1.9-rich-root all the time (I interface with subversion repos. a lot)
<Peng_> jfroy: Yeah, but if you set your default to 1.9-rich-root, it's easier to accidentally create rich-root repos for projects that shouldn't have them.
<jfroy> arguably bazaar shouldn't have the rich root thing. It's a screw up from the early days :/
<Peng_> Yep. The problem now is dealing with that mistake.
<jfroy> It should have been dealt with a long time ago...
<jfroy> The longer it stays around, the harder it will be to fix it, IMHO.
<jfroy> Anyways :/
<Peng_> jfroy: The current (tentative?) plan is to do it with the brisbane-core/CHK formats. Upgrading them requires reserializing inventories(?) anyway, so it's a good time to do it.
<Peng_> s/them/to them/
<jfroy> Interesting. brisbane-core will be *yum*. The speed, oh my!
<jfroy> Well, hopefully.
<rocky> so... what's the problem with using --1.9-rich-root on a repo that shouldn't have them?
<Peng_> rocky: If anyone else has a non-rich-root copy, they have to upgrade before they can pull from you.
<Peng_> rocky: Unless the project is willing to upgrade to rich-roots, your branches will be effectively unmergeable.
<jfroy> https://bugs.launchpad.net/bzr/+bug/340108 :/
<ubottu> Ubuntu bug 340108 in bzr ""Ancestry ends with <...>, not null" error while branching lp:ipython" [Undecided,New]
<thrope> I have a bzr-svn question (ping: jelmer) - I have two diverged branches, craeted with bzr with nothing to do with svn... they have a shared history up to revision 24 or so. I would like to push these both into a svn repository... at the moment I just tried svn-push (push caused a traceback) each one to two different dirs, but all the common commits appear twice
<thrope> is there a way to push them while keeping the branch relationship in svn terms (ie have one as a copy of the other)
<jelmer> thrope, if you got a traceback from svn-push, please file a bug
<thrope> jelmer: from normal push, not svn push
<jelmer> thrope, still, please file a bug
<thrope> also: I always get upgrade to subversion 1.5 message although I am using 1.5.5 on both client and server
<jelmer> thrope, that's fixed in bzr-svn trunk
<thrope> the error is:bzr: ERROR: exceptions.NotImplementedError: <bound method SvnBranch.push of SvnBranch('file:///Users/robince/tmp/test/amaripool/analysis_version')>
<rindolf> Hi all.
<jfroy> jelmer: https://bugs.launchpad.net/bzr-svn/+bug/340110
<ubottu> Ubuntu bug 340110 in bzr-svn "Massive memory consumption while fetching a revision with a large file" [Undecided,New]
<rindolf> Where can I find the bzr-svn-0.5 branch? http://bazaar-vcs.org/BzrForeignBranches/Subversion#development seems to be empty.
<jfroy> rindolf: http://people.samba.org/bzr/jelmer/bzr-svn/0.5
<Peng_> rindolf: bzr branch http://people.samba.org/bzr/jelmer/bzr-svn/0.5/
<Peng_> rindolf: It's not actually empty.
<jfroy> it's a branch :p
<rindolf> Peng_: thanks.
<rindolf> Well, it would be useful to make the web-service put some nice information there.
<rindolf> Peng_: with the command you gave me, etc.
<Peng_> rindolf: It's hardly a "web-service". The HTTP server is just serving a bunch of opaque files.
<rindolf> Peng_: then why is it empty?
<Peng_> rindolf: Because the files are in the directory ".bzr", and Apache's directory listings don't show dotfiles by default.
<rindolf> 11464kB - holy shit.
<rindolf> Do you store .iso's there?
<hmeland> rindolf: No, but you now have a local copy of all the 3861 (or so) revisions that make up bzr-svn's history.
<rindolf> hmeland: I see.
<hmeland> If you just want the current code, you can use "bzr checkout --lightweight http://...".
<rindolf> $ ls -l bzr-svn-0.5.2.tar.gz
<rindolf> -rw-r--r-- 1 shlomi shlomi 232794 2009-02-18 10:09 bzr-svn-0.5.2.tar.gz
<Peng_> Though you've already downloaded it, so it would be a bit silly to delete it, unless you really need the disk space...
<vadi2> Hi, I have a question. I need to make a bzr branch that is able to update stuff from a git repository, but ignores the stuff that comes from git for revisioning
<vadi2> I found this: http://bazaar-vcs.org/BzrForeignBranches/Git, which depends on Dulwich, and has a Ubuntu PPA, but the ppa only has 32bit packages
<vadi2> Is Dulwich available for 64bit?
<mwhudson> you can install it from source, it seems to work
<vadi2> Ok
<rocky> rindolf: fwiw, i'm working on ClueBzrServer which will allow for http-based browsing (akin to mod_svn) for current revisions of files from bzr
<rindolf> rocky: ok, thanks.
<mwhudson> (though tests don't pass on 64 bit)
<vadi2> how would I install dulwich? I'm not sure how to make setup.py work
<vadi2> ahh nm
<rindolf> OK, https://bugs.launchpad.net/bzr-svn/+bug/311712 - I was able to build an .rpm out of subvertpy and bzr-svn.
<ubottu> Ubuntu bug 311712 in bzr-svn "bzr-svn-0.5.0~rc1 - python setup.py bdist_rpm fails" [Low,Fix released]
<rindolf> Thanks everybody.
<vadi2> Another question... I have a -lot- of bzr branches from various projects. Is there any tool to check which are outdated?
<mwhudson> vadi2: there is a plugin that can tell you which are merged into some other branch
<vadi2> mm
<mwhudson> vadi2: https://edge.launchpad.net/bzr-removable
<vadi2> I see
<jelmer> mwhudson, tests do pass on 64bit these days
<mwhudson> jelmer: oh right
<mwhudson> jelmer: want to mark https://bugs.edge.launchpad.net/dulwich/+bug/337483 as fixed then?
<ubottu> Ubuntu bug 337483 in dulwich "dulwich.tests.test_pack.TestPackData.test_iterentries fails on a 64-bit system" [Undecided,New]
<jelmer> mwhudson, we need a IRC interface to Launchpad :-)
<mwhudson> indeed
<jelmer> ubottu, bug 337483: status fixreleased
<ubottu> Launchpad bug 337483 in dulwich "dulwich.tests.test_pack.TestPackData.test_iterentries fails on a 64-bit system" [Undecided,New] https://launchpad.net/bugs/337483
<vadi2> I installed bzr-git as the help file says (move to ~/.bazaar/plugins and rename to git), but now it says this: "Unable to load plugin 'git' from '/home/vadi/.bazaar/plugins'"
<luca> excuse me I'm new and I have a question
<Peng_> vadi2: There should be details in ~/.bzr.log
<luca> I created a branch on launchpad, now I made some changes to the code that I can see on bzr diff
<luca> how do I commit the changes to that branch?
<Peng_> luca: "bzr commit". You should read the tutorial.
<Peng_> Or something.
<luca> but if I write commit, is it sure that the change goes to the launchpad branch?
<vadi2> "from bzrlib.foreign import foreign_vcs_registry
<vadi2> ImportError: No module named foreign
<vadi2> "
<Peng_> vadi2: Your bzr is too old.
<Peng_> vadi2: Or it's broken. I dunno.
<vadi2> i'm on ubuntu 8.10
<Peng_> Ok.
<Peng_> vadi2: And your bzr is too old.
<Peng_> vadi2: You could use https://launchpad.net/~bzr/archive/+ppa
<Peng_> (if that's the right link)
<jelmer> vadi2: if you're trying out bzr-git, you'll need bzr.dev
<Peng_> Oh.
<vadi2> where can I obtain that?
<Peng_> bzr branch http://bazaar-vcs.org/bzr/bzr.dev/
<Peng_> (if that's the right link)
<jelmer> Peng_, yes, it is
<vadi2> ' ERROR: Unknown repository format: 'Bazaar RepositoryFormatKnitPack6 (bzr 1.9)\n'
<vadi2> '
<Peng_> Heh, and the recent format upgrade finally hurts someone.
<jelmer> Peng_, I think it's already hurt more people
<jelmer> Peng_, lenny has 1.5
<Peng_> Nice.
<vadi2> okay, bzr.dev installed
<thecookie> I think I just set up something similar to http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#team-collaboration-distributed-style - The server hosting the main branch will also host a web page of the repo. Is there something wrong with using the repo as the document root of a web server, is there a better way to do it?
<vadi2> Sorry... I tried git-import, and get this: "bzr: ERROR: No module named commit
<vadi2> You may need to install this Python library separately.
<vadi2> "
<Peng_> vadi2: I think that's a dulwich bug. jelmer, you deleted dulwich/commit.py but repo.py still imports it.
<jelmer> vadi2, do you have the latest dulwich (from trunk) and bzr-git (from my branch)  ?
<vadi2> I have both latest from their main branches
<vadi2> so maybe not bzr-git from your branch
<Peng_> ...And then it imports object.Commit, overwriting commit.Commit...
<Peng_> Err, objects.Commit. Plural.
<jelmer> Peng_, vadi2: please try again
<vadi2> jelmer: bzr-git from trunk is newer than your branch
<vadi2> try what?
<jelmer> vadi2, with the latest revision from my branch
<jelmer> vadi2, my branch is at http://people.samba.org/bzr/jelmer/dulwich/trunk
<Peng_> jelmer: Oh, perfect.
<Peng_> :)
<vadi2> getting your branch made it crash
<vadi2> http://paste.pocoo.org/show/107143/
<vadi2> oh, hm. But I do have dulwich installed.
<vadi2> what is the proper procedure for installing it? I used ./setup.py build, sudo ./setup.py install
<jelmer> vadi2, for dulwich, that should work
<vadi2> yeah, but I tried getting your branch, and got this: http://paste.pocoo.org/show/107143/
<vadi2> it says I need to install dulwich and then crashed
<jelmer> lifeless, what should I replace multiply_tests_from_modules with?
<vadi2> Is there a command to delete all unversioned files?
<jelmer> vadi2, bzr clean-tree
<vadi2> thank you
<thecookie> Anyone know if the bzrtools package includes the push-and-update plugin?
<Peng_> thecookie: It doesn't.
<Peng_> Last I saw anyway...
<meoblast001> hi
<meoblast001> how do i revert back to a specific revision?
<Peng_> meoblast001: The working tree, or do you want to remove revisions from history as well?
<Peng_> meoblast001: For the former, "bzr revert -r 123".
<CBro2007> how do I install bzr on centos?
<meoblast001> Peng_: 123? you mean the revision number?
<CBro2007> is there a yum install for it?
<Peng_> meoblast001: Yes.
<meoblast001> k thanks
<Peng_> CBro2007: http://bazaar-vcs.org/Download
<lifeless> jelmer: multiply_tests(loader.loadTestsFromModuleNames(modules), scenarios, standard_tests)
<CBro2007> thanks Peng_
<CBro2007> Peng_: had to add that new RPM repository in
<CBro2007> cheers
<thecookie> So, I searched a bit for a feature similar to svn externals.. Seemed to not be there yet, but in the works?
<meoblast001> Peng_: thanks
<Peng_> thecookie: Right, but it's been "in the works" for ages. I think there may have been some progress recently, or there will be soon, or something.
<thecookie> I see
<jelmer> lifeless, thanks
<Kobaz> dude7064: what about #asterisknow?
<Kobaz> er
<Kobaz> wrong chan
<lifeless> jelmer: (looking at any of the __init__'s changed by my patch would probably have shown you that :P)
<lifeless> rocky: yes, revids are guids, revnos are not
 * mwhudson waves towards brisbane
<psynaptic> hey guys
<psynaptic> I'm trying to login to launchpad to start using bzr for a project
<psynaptic> I've used the bzr launchpad-login rich-freestylesystems command but it's throwing an error about ssl: http://pastie.textmate.org/private/nrknbmomsg8czxkqxz9luw
<psynaptic> any ideas?
<Peng_> psynaptic: My guess is that your Python installation doesn't support SSL, or you have a file called socket.py somewhere in your Python path (such as the current directory)
<psynaptic> Peng_: is there a way I can find out for sure if my pyton lacks ssl support?
<psynaptic> maybe I can reinstall pyton or something
<mwhudson> psynaptic: run python and type "from socket import ssl"
<psynaptic> ok, did that
<psynaptic> it returned nothing, still in pyton
<psynaptic> do I need to do something to run it?
<mwhudson> is bzr running with the same python as you just ran?
<mwhudson> if so, maybe Peng is right
<psynaptic> I think so
<mwhudson> bzr 1.1 is ages old mind
<mwhudson> psynaptic: what command were you running when you got that traceback?
<psynaptic> bzr launchpad-login rich-freestylesystems
<psynaptic> I installed the latest bzr about half an hour ago
<Peng_> psynaptic: Whether or not you installed it, what you ran was 1.1, while the current version is 1.12.
<psynaptic> oh
<psynaptic> just doing an update of my packages
<psynaptic> I tried to install bzr again from macports but I get some errors: http://pastie.textmate.org/private/whynuza6yxkvemmxx12vq
<thrope> I have a bzr-svn question  - I have two diverged branches, craeted with bzr with nothing to do with svn... they have a shared history up to revision 24 or so. I would like to push these both into a svn repository... is there a way to push them while keeping the branch relationship in svn terms (ie have one as a copy of the other)
<thrope> i am thinking of somehow pushing up to where they diverge to svn, copying it in svn, then somehow checking out the two copies of this and rebasing the branches onto that so I can push back the diverged changes
<thrope> but I'm having some trouble getting it to work
<thrope> would appreciate any pointers on how to do this
<thrope> do I need to set up an svn layout so it knows where to look for branches?
<lifeless> vila: your desire is granted; see the commits list, give it a spin
<jfroy> vila: FYI I submitted the patch to AuthConfig early last week, quietly sitting in the PQM
<vila> jfroy: You mean sitting in BB, but yes I saw it, it needs a couple of tweaks, I'll review that more formally today
<jfroy> I also have a quick patch which I may submit to fill in a default port number when None is passed, based on the scheme.
<jfroy> Using socket.getservbyname
<psynaptic> thanks anyway guys]
<vila> jfroy: We tried using a default port by scheme in the past but that wasn't worth the effort (and there was hard to address problems trying to do that), why do you want or even need that ?
<jfroy> the keychain store needs an explicit port number
<lifeless> jfroy: adding a port to urls when one wasn't provided is a bad idea
<jfroy> to construct the service string
<jfroy> lifeless: I disagree, protocols have well-established default ports
<vila> jfroy: then do what needs to be done locally in your keychain wrapper
<jfroy> Ideally, the port should be provided by the transport layer
<jfroy> vila: there are issues beyond the keychain provider
<vila> jfroy: may be, but they are also issues trying to make that work in bzrlib and the python modules involved and the libraries involved, pushing the problem there, where it was tried and failed, will not help
<jfroy> for example, specifying port=80 in a auth. config section for an http scheme, then running a command with an http URL without an explicit port number (which is a perfectly valid and expected use case) will yield no section match, because None != 80.
<mwhudson> if bzr started faster, i'd sure use uncommit more :)
<mwhudson> bzr ci -m <some typo>[ret]C-c is quite common for me...
<jfroy> And that is just a very poor, unexpected behavior.
<mwhudson> jfroy: if you manage to change things so that bzr+ssh ignores "Port <num>" directives in my .ssh/config then the masses will rise up with pitchforks &c
<vila> jfroy: ^ see ?
<jfroy> mwhudson: not speaking about that at all :p
<mwhudson> (this was the problem before)
<vila> jfroy: Yes you *are* speaking about that
#bzr 2009-03-10
<jfroy> No. I'm speaking about providing a port number when none was explicitly given in the URL to credential stores and for the authentication section matching process.
<jfroy> using the system's services database is not an ideal solution
<jfroy> allowing the transport handlers to provide it a reliable solution
<jfroy> ultimately, somewhere, something will open a socket to a specific IP address using a specific transport layer on a specific port. That information should always be available.
<vila> jfroy: no, you were talking about making transport convert port=None to the /etc/services one, which mwhudson is referring as *bad* because it will not respect .ssh/config
<jfroy> Now, granted, if the transport layer is an external process, it gets messy.
<vila> and that's only one case, I don't remember the specifics but there were other
<jfroy> vila: I agree with that
<psynaptic> just thought I'd let you guys know.. restarting terminal fixed my problem
<vila> jfroy: look at "bzr log -m 'default port'" for previous attempt and when it was abandoned (with references to bugs that may provides better information than my failing memory :)
<jfroy> vila: yeah I intend to. Pragmatically speaking, I wrote a patch way back when for the http transport handlers to provide a port number.
<jfroy> And since the credential stores are ignored the the ssh transport layer, that may be a pragmatic approach to fix part of the problem.
<jfroy> Or I may just move the fallback to the keychain store and tell people to not specify a port for default port http sections.
<jfroy> *are ignored for the ssh transport layer
<vila> jfroy: http is different from other protocols regarding authentication as it's the only one where the socket is opened *before* authentication is attempted, but for the general case you can as well, use getservbyname in your wrapper when port==None
<jfroy> vila: yes, but it's highly unlikely the keychain store would be useful for anything else than http.
<jfroy> I'm interested in covering the 90% case :p
<vila> jfroy, then better do that without requiring a bzr modification :-P
<jfroy> *grumbles*
<jfroy> I don't disagree there :p
<jfroy> But, if a simple patch can allow other people to benefit, why not?
<jfroy> (assuming it ends up being a simple patch)
<rocky> jelmer: ever seen  a sha1knitcorrupt error ? :(
<jelmer> rocky, yeah
<rocky> jelmer: i'm getting that on one of my branches that came from a bzr-svn branch
<jelmer> rocky, created with lp:bzr-svn ?
<rocky> not sure
<rocky> could have been
<rocky> jelmer: i'm running a script i found that is supposed to clean up some sha1 corrupt issues but it's reporting not being able to find an inventory.kndx ... ever seen that?
<jelmer> rocky, that looks like a bzrlib issue
<rocky> right now i'm just trying to salvage a few important revs but even bzr diff is failing
<jelmer> it sounds like a clean "bzr clone" would fix it
<rocky> so what's the diff between "bzr branch" and "bzr clone" then?
<luks> there is no difference
<rocky> i branched into a new repo and there's still no inventory.kndx ...
<lifeless> rocky: current formats do not use kndx files
<rocky> lifeless: ah
<rocky> jelmer: when i run "bzr check -v" on a repo i get "7 inconsistent parents" is that typical?
<rocky> that repo works fine btw
<rocky> actually i'm getting 1 ghost revision, 1 revision missing parents in ancestry, and 7 inconsistent parents
<rocky> jelmer: this is on a fresh new repo and checking out svn+https://dev.serverzen.com/svn/cluemapper/ClueBzrServer/trunk   :(
<rocky> jelmer: i guess that svn repo has legacy corrupted bzr trunk problems ;(
<jelmer> rocky, the check results you mentioned aren't problems
<rocky> jelmer: bzr reconcile blows up
<jelmer> rocky, how?
<rocky> jelmer: http://paste.plone.org/26841
<lifeless> mwhudson: try bbc again, with updated branches; should be faster still
<jelmer> rocky, you've hit bug 336749
<ubottu> Launchpad bug 336749 in bzr-svn "reconcile raises a KeyError on a fresh branch" [High,Invalid] https://launchpad.net/bugs/336749
<rocky> jelmer: looks related to bug #336749
<rocky> lol yeah
<SamB> jelmer: I would have to build baz myself, I think ... that is, it isn't in Debian anymore.
<SamB> jelmer: anyway, I doubt I have room to do a full arch->git conversion of emacs myself, so I guess the point is moot ;-)
<jfroy> vila: thanks for the review, I can address some of those.
<vila> jfroy: np
<jfroy> I didn't update the netrc plug-in tests because I considered them outside the scope of the patch.
 * SamB wonders how jelmer will deal with bug 340195
<ubottu> Launchpad bug 340195 in bzr-svn "NoSuchRevision: KnitPackRepository('file:///home/naesten/hacking/fbug/.bzr/repository/') has no revision ('svn-v4:e969d3be-0e28-0410-a27f-dd5c76401a8b:branches/readme.txt:249',) during bzr svn-import --incremental --keep http://fbug.googlecode.com/svn/ fbug " [Undecided,Fix released] https://launchpad.net/bugs/340195
<jfroy> I dislike "grab bag" patches that change a bunch of unrelated things.
<jelmer> SamB, already fixed :-)
<SamB> oh
<SamB> what did you decide to do about it?
<jelmer> it was a one-line patch
<SamB> (I assume that readme.txt was being moved into a branch?)
<jelmer> SamB, no, it was just a file appearing in a place where bzr-svn expected a branch
<SamB> oh, was that all ?
<SamB> then why did it fail a few revisions later than 249 ?
 * SamB puzzled
<jelmer> because it was a bug :-)
<jelmer> bzr-svn was only some of those cases
<jelmer> lifeless, what does your latest patch fix?
<SamB> jelmer: oh, when does the tag import happen?
<jelmer> SamB, at the end
<SamB> jelmer: does only svn-import do it ?
<jelmer> SamB, bzr branch / bzr pull too
<lifeless> jelmer: more specifics please
<jelmer> lifeless, exactly
<SamB> jelmer: oh, and I think you don't emphasize enough that `bzr svn-import' creates the same kind of branches as `bzr branch'
<lifeless> jelmer: I don't know what my latest patch is
<jelmer> lifeless, The one with the few details :-)
<jelmer> lifeless, "Tada!"
<SamB> hah
<jelmer> SamB, I'm not sure, branches are branches
<SamB> jelmer: well, you make it sound too much like a static conversion tool, I guess
<jelmer> lifeless, did you see my reply to your comment about default-rich-root
<SamB> might just be the name
<SamB> but, well, the wikipage is so sparse that there isn't much else to gather information from
<lifeless> jelmer: it does what the subject said :)
<lifeless> jelmer: subjects are often displayed by mail clients:)
 * SamB wishes the SVN protocol weren't so danged slow for imports
<lifeless> jelmer: I don't think I saw your comment, no
<jelmer> SamB, which bzr-svn version are you using?
<jelmer> lifeless, I guess I should rephrase
<SamB> jelmer: I pulled it a few minutes ago from lp:bzr-svn
<jelmer> lifeless, what things does it fix?
<SamB> the SVN protocol just wasn't designed for streaming revision history, that's all
<SamB> (well, especially not over HTTP, I guess ...)
<lifeless> jelmer: it makes the flag on the format be accurate
<jelmer> lifeless, it doesn't e.g. help with texts with ghost parents in pack repos?
<lifeless> jelmer: no idea; it was inconsistent, I'm fixing it
<jelmer> lifeless: ah, thanks
<jelmer> lifeless, I was hoping it fixed the text ghost parent issue
 * SamB wonders why bzr tags needs a branch
<spiv> SamB: because tags are stored on a branch
 * SamB wonders why he isn't seeing any tags in his putty import
<lifeless> mwhudson: ping
<mwhudson> lifeless: hi
<mwhudson> lifeless: log -v --short is much quicker in this bzr-gc-chk255 branch now :)_
<mwhudson> lifeless: like maybe twice as fast as --1.9
<mwhudson> mm, a bit less than twice as fast
<mwhudson> but a lot faster :)
<lifeless> mwhudson: so how is loggerhead
<mwhudson> lifeless: i haven't tested it specifically yet, been hacking on it in other ways today
<mwhudson> today, i will mostly be stabbing firefox
<gotgenes> How can I tell what files Bazaar *is* tracking?
<Peng_> gotgenes: "bzr inventory", I guess
<gotgenes> Peng_: Yep, that works. Thanks.
<mwhudson> gotgenes: also ls --versioned
<gotgenes> mwhudson: that works too. thanks
<mwhudson> (i think commands like inventory, ignored, unknowns are gently deprecated in favour of ls --option)
<mwhudson> gotgenes: i'd be lost without my "bzr ls --versioned --null | xargs -0 grep dsadas" commands :)
<lifeless> mwhudson: 'bzr search'
<lifeless> mwhudson: I think I have your conversion issues fixed
<lifeless> mwhudson: pushing soon, once this test completes
<mwhudson> lifeless: cool
<gotgenes> Is there a way to get colorized output from bzr commands?
<bob2> bzrtools has cdiff
<bob2> in general no
<gotgenes> bob2: fair enough
<elben> I want to share my dot-files (.vimrc, etc) across all my machines. what do you think the best way of doing this is?
<bob2> bzr!
<gotgenes> elben: That's what I do.
<gotgenes> Create symbolic links from your home directory to a branch directory
<elben> you just set up a repo with your home folder being the root folder?
<gotgenes> elben: naw
<gotgenes> that gets messy
<elben> @gotgenes: hah that just came to mind!
<bob2> it doesn't get very messy
<gotgenes> bob2: bzr status gets messy
<bob2> I've been doing that for 4 years or so
<elben> hum.. the machines at my univ doesn't have bzr installed =(
<gotgenes> elben: if they have Python, you should be fine
<elben>   alright, i'll try it out
<elben> thanks for the tips
<lifeless> mwhudson: pull groupcompress
<lifeless> mwhudson: it plus the preior fix I gave  you (with a curret bbc branch) will probably be enough
<mwhudson> lifeless: do i need to scrap my half-done branch, or can i pull on top of that?
<lifeless> mwhudson: scrap it
<mwhudson> lifeless: what was the fix you gave me again?
<mwhudson> or at least, which file was it in\
<lifeless> repository.py
<mwhudson> hm
<mwhudson> can you pastebin the diff?
<mwhudson> or tell me the line number
<lifeless> actually that fix is not relevant now, you need:
<poolie> james_w: could you land my patch in https://bugs.edge.launchpad.net/ubuntu/+source/python-crypto/+bug/337073 or prod it along?
<ubottu> Ubuntu bug 337073 in python-crypto "python-crypto uses sha module that's deprecated in python2.6" [Medium,Confirmed]
<james_w> poolie: I can't land it, but I can make sure it is in the correct place
<lifeless> http://paste.ubuntu.com/129110/
<lifeless> mwhudson: you probably want to pull 1000 revisions at a time
<lifeless> mwhudson: we're uhm, a little too efficient at the moment :P
<lifeless> jam: http://paste.ubuntu.com/129110/
<BasicOSX> Hello #bzr, looknig for guidance on where to push the 1.13rc1 for release? I'm "stuck" on step #7, submitting changes to PQM. Any help?
<james_w> BasicOSX: hey, there is no branch yet, Robert is on it
<james_w> BasicOSX: however, it's a bit more tricky as your key isn't known to PQM
<james_w> BasicOSX: if you make your branch available somewhere I will submit it on your behalf
<BasicOSX> Let me push it to my local area, back in a couple
<BasicOSX> james_w:  ok, push underway, will /poke you when complete
<schmichael> does bzr have an "outgoing" type command to see what commits would be applied in a push?
<spiv> schmichael: "bzr missing --mine-only"
<schmichael> spiv: perfect!  thanks!
<BasicOSX> james_w:  prepare-1.13 here => http://bazaar.frostmage.org/prepare-1.13/
<james_w> thanks
<BasicOSX> Shall I continue with the announcement or should I wait for PQM ?
<james_w> I'll submit now, but it may take some time, so you can work on other things in the meantime
<mwhudson> lifeless: global name 'key' is not defined :(
 * mwhudson changes it to 'keys'
<mwhudson> and finally 'chunks'
<lifeless> mwhudson: diff please
<devilsadvocate> hi, IÂ´m trying to get rid of this Â¨Server does not support bazaar protocol 3, reconnectingÂ¨. IÂ´m using the latest bzr in the Debian Lenny repo. Is there any sane way I can either upgrade the server or force clients into Protocol < 3 so that the password doesnt have to be entered twice? (*very annoying)
<Peng_> Are there up-to-date debs for Debian? The Ubuntu ones would probably work, but..
<devilsadvocate> i have no idea. which bzr version did network protocol 3 come in?
 * devilsadvocate is not sure if its a configuration issue
<devilsadvocate> i have 1.5-1.1
<devilsadvocate> which is probably bzr 1.5
<devilsadvocate> hm
<lifeless> devilsadvocate: 1.6 will solve this.
<lifeless> 1.12 is current, 1.13 is entering rc as we speak :)
 * devilsadvocate grumbles about debian stable
<devilsadvocate> lifeless, thanks
<devilsadvocate> iÂ´ll look into trying to install it manuall
<devilsadvocate> manually*
<spiv> devilsadvocate: also, using an SSH key agent will save you typing in your password so often.
<spiv> devilsadvocate: but I believe the bzr PPA has packages that should work on debian stable.
<devilsadvocate> spiv, i use ssh keys, but iÂ´ve got 60 people who dont know the first thing about version control and ssh keys to train, so..
<devilsadvocate> spiv, is it possible to use ssh keys from windows? im using the bzr+ssh transport and the windows binary installer for bzr
<lifeless> mwhudson: ping
<spiv> devilsadvocate: there's a key agent for putty IIRC.  "pagent"?
<devilsadvocate> spiv, hm. IÂ´m not sure what ssh agent is being used. let me find a vanilla windows install and try that out. I dont think putty is being used anywhere... installing bzr + tortoise seemed to have installed some ssh agent as well
<mwhudson> lifeless: hi
<lifeless> mwhudson: pastebin the changes you made?
<mwhudson> lifeless: 'key' only appears once in _inventory_xml_lines_for_keys
<lifeless> mwhudson: got that, and fixed
<mwhudson> that's all the changes i made
<mwhudson> pull -r 1000 worked
<lifeless> oh chunks comment was unrelated?
<mwhudson> pull -r 2000 is still grinding away
<mwhudson> lifeless: i changed key to chunks
<mwhudson> as the other things i tried didn't work
<lifeless> mwhudson: I need to see a diff
<lifeless> mwhudson: as I don't understand
<mwhudson> lifeless: http://pastebin.ubuntu.com/129129/
<mwhudson> ah, -r 2000 completed
 * mwhudson kicks off -r 3000
<mwhudson> grar
<lifeless> oh
<lifeless> right, yes, record.key[-1]is the right incantaiton
<lifeless> mwhudson: after it finishes, do 'bzr pack'
<mwhudson> bzr: ERROR: Revision {('dirstate.py-20060728012006-d6mvoihjb3je9peu-1', 'mbp@sourcefrog.net-20070401013825-zggofbeun985u2ri')} not present in "<bzrlib.plugins.groupcompress.groupcompress.GroupCompressVersionedFiles object at 0x2fbddd0>".
<mwhudson> again :/
<mwhudson> oh, didn't pack first
<lifeless> mwhudson: thats odd and shouldn't have happened
<BasicOSX> Can someone with ops please update the topic to '1.13rc1 released 10 Mar'
<mwhudson> lifeless: maybe you should try it :)
<lifeless> mwhudson: I am
<lifeless> 2.4G of output so far
<mwhudson> hum
<mwhudson> maybe i did something wrong then
<james_w> lifeless: I have submitted the changes to the 1.13 branch and PQM seems to have ignored it. I got no email, and there is no new revision, and nothing in its queue apparently. Is there any way to debug this?
<lifeless> mwhudson: did you delete the repository you were fetching into?
<mwhudson> many times
<mwhudson> i don't know if i did this very last time
<lifeless> james_w: you probably haven't managed to get the mail out of your laptop
<james_w> I have
<poolie> woo way to go BasicOSX!
<BasicOSX> Attempting to update pypi and "Server response (403): You are not allowed to store 'bzr' package information" anyone have auth to give me privs to update?
<james_w> BasicOSX: http://pqm.bazaar-vcs.org/ <- merging now, sorry for the delay
<BasicOSX> james_w:  np, ever sit on hold with a "normal" commercial software vendor? Service here is amazing!
<james_w> heh :-)
* spiv changed the topic of #bzr to: Bazaar version control system | 1.13rc1 released 10 Mar | http://bazaar-vcs.org | http://irclogs.ubuntu.com/ | http://planet.bazaar-vcs.org/
<spiv> BasicOSX: topic updated
<BasicOSX> spiv:  ty
<Peng_> Congrats on the release (candidate), BasicOSX & everyone. :)
<BasicOSX> 1.13 should go smoother as now my feet are wet and I did not drown on my first attempt :-)
<d-b> hi is there a good gui for bzr ?
<AfC> d-b: there are several.
<d-b> yes ?
<d-b> any that i can use to link into konqueror / nautilus gui ?
<spiv> d-b: there's a qbzr plugin (which tortoise-bzr on windows uses, I believe), and bzr-gtk has optional nautilus integration.
<d-b> i have got bzr-gtk ... i wanted a gui manager ^^
<spiv> d-b: try the nautilus integration bzr-gtk.  There's a readme about it in the source.
<poolie> i'm craving a quick review of https://code.edge.launchpad.net/~mbp/bzr-email/335332-starttls/+merge/4331
<poolie> hm needs diffs
<poolie> lifeless: ^^ diffs added, really easy
<lifeless> mwhudson: it converted for me
<lifeless> 37MB total
<nags> my friend tries bazaar from windows and getting this error message
<nags> any clues ?
<mwhudson> lifeless: i don't know what i'm doing wrong then
<nags> C:\Python25\Scripts\racetrack1.0>bzr launchpad-login jwgreen
<nags> bzr: ERROR: Connection error: curl connection error (SSL certificate problem, ve
<nags> rify that the CA cert is OK. Details:
<nags> error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify faile
<nags> d)
<nags> on https://launchpad.net/%7Ejwgreen/%2Bsshkeys
<mwhudson> lifeless: can you upload it to rookery or something?
<lifeless> mwhudson: sure
<lifeless> mwhudson: upload bandwidth sucky, will upload overnight
<lifeless> mwhudson: 37MB is 27MB
<lifeless> bah, 3  in the second part :P
<lifeless> ciao
<mwhudson> lifeless: cool, it's not like i'm going to do anything tonight :)
<johnf> anyone working on 13rc1 packages for bzr-beta-ppa yet? If not I'll start
<shled> hello
<lifeless> johnf: doit
<shled> beginners question: is it safe to remove a branch's directory after merging it into the main line?
<beuno> shled, yeap, should be
<shled> beuno: thanks!
 * beuno waves at lifeless from Cape Town
 * shled happily frees some disk space
<thecookie> New to bzr. I just set up a master branch on a server, I branched it locally. Doing some code changes, commit it. Now it's commited to my local main branch, right? So to push it back to the master branch I do a push?
<thecookie> After I've done a push, the master branch server needs to do an update to get the changes. That's why there is a push-and-update plugin, right? Is there any other way of doing it, or is that "the" way of doing it?
<lifeless> beuno: nice
<lifeless> thecookie: generally you don't need to have a up to date tree on the master for other people to pull from it
<thecookie> lifeless: Well, the project I'm working with is a web page, and the same server hosting it is also hosting the page via http. That's why I want to update it. Maybe the post commit hook is triggerd on a push?
<lifeless> thecookie: for that, most folk use the 'bzr-upload' plugin I think
<lifeless> thecookie: the post-tip-branch-change hook is fired on the server after a push if you are using bzr+ssh
<thecookie> I'm using bzr+ssh, yeah. But it seems to be a bit of overhead. First I push changes to the server, then I upload them too?
<thecookie> I didn't read up on the upload plugin tho. Maybe I should :)
<johnf> lifeless: At some stage I'll need write access to the lp:~bzr/bzr/packaging-hardy is it possible to get access to those as a bzr-beta member? Or should I just create my own branches and propose merges?
<thecookie> Yeah, seems to work like I thought. Seems stupid to upload the changes twice
<thecookie> I guess push-and-update fits me thetter then, just wanted to check if there was a "correct" way to do it
<Jc2k> wg /8
<Jc2k> grr
<lifeless> thecookie: in general update can fail because of local edits; bzr-upload kind of fits the model better; anyhow - as long as you're happy thats great
<lifeless> johnf: we can fix permissions on tha tbranch - move it to ~bzr-beta-ppa or whatever
<lifeless> johnf: let me know tomorrow ;P
<johnf> lifeless: ok cool
<lifeless> Jc2k: :)
<thecookie> lifeless: The master server will never have local edits
<thecookie> It's pretty much just the "main branch" hosted for others
<OllieR> is it possible to cancel a pending merge?
<OllieR> on this branch it looks like someone has done a local ci and then done an up
<OllieR> so the changes are showing as pending merge but I just want to remove them
<OllieR> Whats the best way to do this?
<jelmer> OllieR, bzr revert
<OllieR> jelmer: thanks
<johnf> can someone test http://inodes.org/johnf/debs/bzr_1.13~rc1-1~bazaar1~intrepid1_i386.deb before I upload to the beta ppa?
<rocky> if i merge from branch A into branch B ... and later on i merge from branch B into branch C ... how does the history on branch C reflect the original changes from branch A ?
<rocky> i mean does it show up as a merge commit coming from A ?
<rocky> lifeless: don't suppose you know if the streaming feature for bzr push to a bzr url works over bzr+http:// as well?
 * SamB wonders why jelmer did a release of bzr-svn that depends on an unreleased version of bzr
<rocky> SamB: latest release of bzr-svn should work with released bzr-1.13rc1 no ?
<SamB> rocky: oh, that's a release ?
<rocky> bazaar release notes says it is
<rocky> i haven't actually downloaded it tho
<SamB> nevermind then
<saulus> hi, how do I change the "parent branch", this one is deleted and I want to set the parent branch to the submit branch
<saulus> funny - as soon as i send my request it works 0o
<jelmer> SamB, the API is frozen now there's a RC out
<jelmer> SamB, that's always a good moment to release bzr-svn, otherwise people need to wait for one after 1.13 is released
<KangOl> Hi
<KangOl> How to clean the history of a branch after doing a "bzr split" ??
<KangOl> I want to strip out all unrelated log history
<nathanhammond> Hokay, so. I'm in both this and Mercurial's room and am asking the same question in both places. Why should I choose Bazaar over Hg at this point in time for new projects?
<nathanhammond> (With the continued improvements I've seen on both sides, the BzrVsHg comparison is out of date.)
<nathanhammond> I've been using Git for a while now, but in a mixed environment (Windows) it is hard(/impossible) to justify using it.
<eferraiuolo> I'm wondering if there is a command to remove all *.~1~ backup files that got created on accident? I forgot to add the --no-backup argument to the bzr revert command
<Tak> I personally chose bzr over other DVCSs because: I know it will run anywhere python will run, it has good support for a lot of different workflows, bzr devs are constantly working on better merging and more efficient storage, and support by ubuntu/launchpad
<maxb> eferraiuolo: bzr clean-tree might help. Or, there's always plain old find.
<Tak> find . -regex '.*\.~[0-9]+~$' -execdir rm {} \;
<Tak> ;-)
<nathanhammond> Tak: thanks for your comments. Is there any particular workflow that stands out?
<nathanhammond> (I'm coming from Git, needing something that runs as a non-second-class citizen on Windows)
<Tak> for me, no particular one by itself, but every project has its own workflow
<maxb> I think the point about workflow is that if you want to pretend you're still using a centralized SCM, you can?
<Tak> and I've yet to find one that is uncomfortable with bzr
<nathanhammond> I am trying to train centralized out of the rest of the team in baby steps.
<eferraiuolo> maxb: thanks
<jelmer> KangOl, History isn't really changable.
<Pieter> Tak: heavy rebasing / cherry-picking doesn't work very well with bzr
<Tak> ok
<devilsadvocate> Tak, there are loads of them
 * Tak shrug
<devilsadvocate> nathanhammond, best of luck doing that
<Tak> "I haven't found any" != "They don't exist" ;-)
<devilsadvocate> Tak, nathanhammond : theres always _some_ part of the team thats wants to do thing "the other way"
<Tak> it's true
<Tak> I've spent years migrating my dept from (vault||nothing) => svn
<nathanhammond> devilsadvocate, Tak: fortunately, there are two camps they're coming from: svn locally, and the "copy a folder, edit" approach
<nathanhammond> globally there isn't anything
<nathanhammond> and that is one of my responsibilities
<Tak> is it too late to murder the copy/edit group?
<jelmer> Pieter, Cherrypicking only works well with darcs unfortunately :-/
<devilsadvocate> Tak, you'd be killing off half your team, if not more
<nathanhammond> be nice! web developers, the lot of 'em.
<nathanhammond> SCM-managed websites seems to be a kinda new thing
<devilsadvocate> nathanhammond, you and i have a very unenviable job. the hope is that the univers shall one day repay us
<nathanhammond> devilsadvocate: I'm simply hoping that things aren't so entrenched that it is possible to get people to buy in
<nathanhammond> the problem is that the team actually has decent incremental hourly backups that has been serving as their version control.
<nathanhammond> "why do I need SCM when..."
<nathanhammond> in any case, I'll figure it out.
<devilsadvocate> nathanhammond, its not so much entrenched in a different camp, its more of a "is this really worth my time and effort as this really great effort"
<devilsadvocate> *really gread programmer"
<devilsadvocate> great*
 * devilsadvocate really needs sleep
<nathanhammond> heh
<devilsadvocate> if you ask me, the easier way would be to let it bite them in the face one day and let take it up voluntarily
<nathanhammond> that worked at the last job
<nathanhammond> rm -rf is not a friend
<devilsadvocate> :D
<devilsadvocate> rm -rf is the lesser of devils
<devilsadvocate> a simple backup will do the job, you dont need version control
<nathanhammond> old job: no backups
<nathanhammond> git's distributed SCM to the rescue on 3 of 4 projects (since I set them up)
<devilsadvocate> no, the fun time comes when its time to deliver and you realize different parts of the groups were working on different code, as in, different checkouts from a no-exisiting tree and that they all dont work together
<nathanhammond> fourth project lost a week, since that was the last time it got pushed live
<nathanhammond> ouch. no thanks.
<alefteris> hi all! are symlinks added in the bzr repo? if they are how can I remove them, I tried with bzr remove but that didn't work
<kfogel> sanity check: bzr versions directories as first-class objects, right?  I mean, that's how it's always appeared to me, but I want to make sure I'm not missing any gotchas.
<luks> yes
<kfogel> luks: thanks
<luks> directories are just a different kind of 'inventory items'
<clemente> alefteris: yes, they are added. There is some trouble in removing them; for instance see: https://bugs.launchpad.net/bzr/+bug/236149   . I have added there a link to a workaround
<ubottu> Ubuntu bug 236149 in bzr ""Error: Not a branch" when trying to revert a symlink" [Low,Triaged]
<alefteris> clemente, thanks. another thing: with the symlink added, will I be able to check out to a windows machine?
<clemente> alefteris: I don't know that; I suppose yes, you can, but I don't know what will be checked out. Maybe the same file twice?
<clemente> (however, some messages in the Internet speak about getting just an error...)
<alefteris> clemente, ok thanks a lot
<eferraiuolo> I got the following message when doing a checkout of a branch on over HTTP:
<eferraiuolo> Got a 200 response when asking for multiple ranges, does your server at localhost:8080 support range requests?
<eferraiuolo> Will bzr still function if the server doesn't support multiple range requests?
<eferraiuolo> i.e. will my branch be fine even though bzr wrote that message during the checkout?
<mwhudson> yes
<mwhudson> it's a performance thing, not a correctness thing
<eferraiuolo> mwhudson: thanks for the insight
<pgega> hello
<mwhudson> reboot, brb
<pgega> I am working on the bazaar-based audit script that watches some various dirs for changes and commits the to the repo.
<pgega> Is there any way tor relocate repository (.bzr) from working dir using bzrlib ?
<Spaz> hello
<Spaz> does bzr have a command to copy files?
<bob2> no
<Spaz> :(
<bob2> afaik only svn does
<Spaz> hg does too
<LarstiQ> what are the semantics in hg?
<LarstiQ> for merge, and log?
<LarstiQ> Spaz: does a copy get updated with changes on the copied from?
<Spaz> not in hg.
<Spaz> you can make a symlink though
<Spaz> which effectively does the same thing.
<bob2> what's the point then? :)
<LarstiQ> Spaz: iirc, afaik, the semantics of copy never became crystal clear
<Spaz> bob2, https://bugs.launchpad.net/bzr/+bug/269095
<ubottu> Ubuntu bug 269095 in bzr "bzr missing "cp" command for forking files /w history" [Undecided,Confirmed]
<LarstiQ> Spaz: and implementing it halfbaked would give false promises and trouble etc
<Spaz> eh.
<Spaz> copy should copy the file along with its revision history
<LarstiQ> Spaz: but the developers aren't opposed to copy, if someone does the work :)
<LarstiQ> Spaz: that's only one part of it.
<LarstiQ> Spaz: how does it interact with the rest of the tool?
<LarstiQ> this is all my recollection from the past
<Spaz> ahh. i see.
<Spaz> i would do this but i'm not familiar enough with bzr's internals.
 * LarstiQ doesn't know if there is a different current status
<LarstiQ> Spaz: that we can help with
 * Spaz will give this a shot since he has so much free time today
<Spaz> although this will certainly take a few days.
<Spaz> probably a week. :p
<LarstiQ> Spaz: I'd be impressed if you get it done in that time :)
<LarstiQ> Spaz: will buy you a beverage of your choice when we meet :)
<LarstiQ> jelmer: will you upload 0.5.3 to ppas, or ok if I do that?
<jelmer> LarstiQ, go for it :-)
<jelmer> LarstiQ, and thanks (-:
<LarstiQ> jelmer: you'll have to wait till tomorrow though
<Spaz> LarstiQ, i wrote 900 LOC this week. :p
<Spaz> (according to sloccount)
<LarstiQ> Spaz: I'm afraid that's not where the problem is going to lie
<LarstiQ> Spaz: but don't let me be pessimistic, I should cheer you on \o/
<Spaz> LarstiQ, trust me, much of this code wasn't trivial :p
<Spaz> i'm just insane though.
<LarstiQ> Spaz: cool :)
<mwhudson> mm, multiply_tests looks a lot nicer than what we do in lp today :)
<OllieR> Hey I am setting up a bzr repo for centralised workflow. I have done mkdir /src/bzr/ I was then planning on doing bzr init-repo -treeless /srv/bzr and creating subdirs such as applications and websites which I would do bzr init in e.g. bzr init /srv/bzr/websites/example.com/main/
<OllieR> What I guess thought it is it best to just do bzr init-repo on the dir /srv/bzr or should i do it on the specific project branches
<OllieR> e.g. bzr repo-init /srv/bzr/websites/example.com/
<OllieR> I am going to need to give write/read access on various dirs/branches to various people. Wondering if having a repo for each project would help me do this or whether I have missed something/got confused
<verterok> OllieR: if you create a repo in /src/bzr/ all users must have write access in that dir
<OllieR> verterok: which means all users could write to all branches
<bob2> yes
<OllieR> which is not really what i want so i will do a bzr init-repo for each project
<OllieR> need to also look into giving public access via http
<OllieR> i guess i can just add an apache vhost and let users checkout via http://
<OllieR> then write access doesn't come into it
<johnf> lifeless: So I have bzr 1.13rc1 packages ready to upload. But there isn't a new bzrtools yet so I'm hesitant to upload it. Since this was one of my biggest issues ie the packages in the ppa being out of sync
<lifeless> johnf: thats fair enough.. perhaps abentley: can do a release today; though we are sprinting :)
<kousu> What does diverge mean to bzr?
<kousu> I was able to pull a branch and have it merge changes, but now I keep getting "branches have diverged".
<bob2> pure bzr or does it involve svn?
<jml> radix: regarding bug 152008
<kousu> pure bzr
<ubottu> Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/152008/+text)
<jml> radix: I was wondering, do the Twisted community _really_ need that? You could probably hack buildbot up to do a PQM-style "only land if tests pass" thing.
<mwhudson> lifeless: lp:bzr-search was broken by the removal of adapt_tests
<radix> yeaaaah well
<radix> that's another thing to do
<radix> jml: but it still doesn't solve the problem
<jml> radix: it might make it less pressing.
<radix> jml: I mean, it's pretty easy to introduce tests which spuriously fail
<radix> yeah, true
<radix> we could do the lose-history hack
<radix> when we really need to revert
<mwhudson> i wonder if you could have the reverting process insert a revprop
<jml> radix: so, we do revert revisions from time to time from the Launchpad tree.
<radix> jml: well, and the other thing is that we still can't switch to an "only land if the tests pass" because of *current* sporadic tests
<mwhudson> that merge would notice when you merge trunk into the feature branch
<radix> mwhudson: that's how I was imagining the solution would look
<jml> radix: right. there are things you can do there, but they mostly require either fixing the tests or policy changes.
<mwhudson> AssertionError: Failed doctest test for bzrlib.branchbuilder.BranchBuilder
<mwhudson> because i didn't let it have my passphrase :(
<jml> radix: sporadic tests could be marked todo, for example
<jml> radix: but still, there's a bzr bug, and we should fix it :)
<lifeless> mwhudson: yes, I have a fix just need to upload it :P
<mwhudson> https://bugs.edge.launchpad.net/bzr/+bug/321320
<ubottu> Ubuntu bug 321320 in bzr "bzrlib.branchbuilder tests run GPG (not isolated enough)" [Undecided,New]
<mwhudson> lifeless: oh good
<lifeless> mwhudson: give the bzr.dev.chk copy a spin, you'll want to rsync
<lifeless> -> sprint now
<mwhudson> lifeless: other priorities right now, but will do
<mwhudson> oh, i have a bazaar branch i want landing in a sec :)
<lifeless> mwhudson: ok
<mwhudson> lifeless: http://pastebin.ubuntu.com/129561/
<mwhudson> lifeless: it just extracts the creation of the branch format scenarios out of load_tests
<lifeless> mwhudson: looks fine to me
<mwhudson> lifeless: cool, i sent a bundle off, but it doesn't seem to have made it to the list yet
<lifeless> JFDI
<lifeless> you chave commit rights yeha?
<mwhudson> nope
<lifeless> oh
<mwhudson> though of course i can't change launchpad to use this until after i land bzr.dev into sourcecode
<mwhudson> but well
<mwhudson> lifeless: the branch is at https://code.edge.launchpad.net/~mwhudson/bzr/extract-make-branch-scenarios fwiw
<mwhudson> and the bundle here: http://people.ubuntu.com/~mwh/extract-make-branch-scenarios-4109.patch
<spiv> Apparently calling fsync is more important under ext4: https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/317781/comments/54
<ubottu> Ubuntu bug 317781 in linux "Ext4 data loss" [High,Confirmed]
<blueyed> Is there a better way to get a revisions log message than $(bzr log -r $rev --long | grep '^  ' | sed 's/^  //') ?
<kousu> blueyed: what's wrong with bzr log -r $rev?
<blueyed> kousu: I only want the message (for a script).
<kousu> ooh
<blueyed> ok, the "--long" is not required (since it's default).. but anyway..
<kousu> You could bzr log -r $rev --short | tail -n +2 but that's not much better
<kousu> Or you could write a bzr plugin that gives you just the log messages
<kousu> But what you've got already is probably as good as either of those
<blueyed> ok, thanks, kousu. It would break however when the amount of spaces changes.. :/
<kousu> So give up on shell and write it in python? str.strip for the win
<blueyed> well, sure. I could strip it in shell, too - but it's used for detecting the message, too. therefore "--short"/tail is an improvement already.
#bzr 2009-03-11
<lifeless> jml: http://pypi.python.org/pypi/testtools/0.7.8
<jml> lifeless: yeah, someone filed a bug about it on the testtools launchpad page
<lifeless> :P
 * SamB looks for the bzr reconfigure command to turn an SVN checkout into a BZR checkout
<SamB> huh. it apparantly took it a while to figure out it can't do that ?
<SamB> that was with --checkout
 * SamB wonders why doing `bzr info --verbose' in his svn checkout of Coq uses so much CPU
<mwhudson> info -v does some fairly silly things
<SamB> it says something about browsing branches
<spiv> info -v is a bit expensive for bzr branches, I can imagine it would be a bit ridculous with svn branches...
<SamB> it's gone and crashed on me
<lifeless> SamB: bzr checkout fresh :). also perhaps file a bug on being abe to do the conversion via reconfigure.
<james_w> upgrade?
<SamB> james_w: what to ?
<james_w> "bzr upgrade --default" might work
<lifeless> or it might eat you
<lifeless> 50-50 chance I reckon :P
<lifeless> mwhudson: search is fixed
<mwhudson> lifeless: ta
<jml> maybe bzr should have a buildbot that tests a bunch of common plugins.
<lifeless> abentley: http://pastebin.ubuntu.com/129601/
<jml> spiv: so have you satisfied your curiosity about that patch yet?
<SamB> lifeless: more likely that it will just leave me with a working directory that isn't
<SamB> rather than eating me
<lifeless> http://pastebin.ubuntu.com/129601/
<SamB> is someone writing a "bzr gc" command ?
<spiv> jml: which patch? ;)
<spiv> jml: you mean https://code.edge.launchpad.net/~jeanfrancois.roy/bzr/url-safe-escape/+merge/3417 ? ;)
<spiv> SamB: actually, we were talking about that last night.
<spiv> SamB: the new 'fetch_spec' part of the fetch API may make it pretty easy to write.
<mwhudson> lifeless: did you add multiply_tests and so on in the same landing as removing adapt_tests?
<jml> spiv: yes that one -- the one that's blocking your review of my patch :P
<spiv> jml: I don't actually see your patch
<lifeless> mwhudson: yes
<jml> spiv: that sucks.
<thumper> what is revision.timezone stored as?
<lifeless> mwhudson: also, separately, see lp:testscenarios
<thumper> or what does 43200 translate to?
<mwhudson> lifeless: that makes life difficult for us :/
<spiv> thumper: 12 hours
<lifeless> how so?
<spiv> thumper: assuming that's seconds
<thumper> is the timestamp on a revision stored at UTC?
<spiv> (doesn't everyone know that there are 86400 seconds in a day?...)
<mwhudson> lifeless: it's much easier if i can land a launchpad branch that passes with bzr-as-in-sourcecode and bzr.dev
<jml> spiv: I sent it to bazaar@lists.canonical.com
<mwhudson> last time i got spm to do a simultaneous landing i ended up getting phoned up when i was in a bar
<jml> spiv: but I haven't got any bundle buggy mail about it.
<thumper> mwhudson: sorry about that
<spiv> jml: I haven't got it at all, I doubt bb has either
<spiv> jml: I'll check the mailman moderation thingy
<mwhudson> thumper: heh, it's ok, but it motivated me towards doing things the other way
<mwhudson> maybe i can just copy-paste bits of testscenarios into launchpad temporarily...
<thumper> spiv: is the revision.timestamp in UTC?
<spm> mwhudson: but we were trying to make you look important by ringing your phone while you were in the bar!?!?! ;-)
<spiv> jml: nope, not there either...
<mwhudson> spm: heh heh
<jml> spiv: maybe gmail is broken.
<mwhudson> spiv, jml: "list server is currently backed up"
<lifeless> thumper: no
<lifeless> thumper: its in revision.timezone
<jml> mwhudson: where's that from?
<mwhudson> jml: #is on the private server
<thumper> lifeless: so the utc time would be: revision.timestamp - revision.timezone ?
<jml> mwhudson: ahhh
<lifeless> thumper: there are normaliation functions around
<thumper> lifeless: where?
<lifeless> in bzrlib
<thumper> lifeless: can you be a little more explicit or shall I just grep?
<lifeless> I would be grepping to
<thumper> ok
<lifeless> I have a small page cache :)
<thumper> lifeless: really?
<thumper> lifeless: I thought it was large
<lifeless> size is relative; I last looked at tz stuff about 2 years back
<spiv> mwhudson: ta
<mwhudson> btw, if someone wants to merge http://people.ubuntu.com/~mwh/extract-make-branch-scenarios-4109.patch
<mwhudson> ,,,
<mwhudson> ,,,
<mwhudson> ...
<mwhudson> !
<mwhudson> (also currently somewhere between here and bb)
<spiv> mwhudson: looks sane and near-trivial to me, I'll merge.
<mwhudson> spiv: thanks!
<mwhudson> oh, looks like robert already did :)
<spiv> mwhudson: oh :)
<spiv> mwhudson: even better.
<lifeless> :P
<lifeless> mwhudson: sorry re: single landing, but its easier for bzrlib to not have duplication
<mwhudson> i just want to delete this code from lp :(
<thumper> lifeless: I was just talking with jamesh about revision.timestamp
<thumper> lifeless: observations on the lp scanner would be that it is recording the timestamp in utc
<thumper> lifeless: but the code seems to indicate localtime
<thumper> lifeless: now I'm confused
<spiv> thumper: See bzrlib.repository.CommitBuilder's __init__, it defaults the timestamp to time.time(), which is seconds since the epoch, in UTC.
<lifeless> ah so it is utc :P. oops :)
<mwhudson> spiv: i would hope seconds since the epoch is timezone neutral!
 * mwhudson sees jamesh making the same point in another place
<jamesh> mwhudson: it measures time since the epoch assuming that every day has only 86400 seconds
<SamB> hmm, say I'm writing an elisp program and I want to know what the default destination for "bzr send" is ... how should I do it ?
<jelmer> SamB, hi
<spiv> mwhudson: I'm just quoting the official docs :)
<SamB> jelmer: hi!
<jelmer> SamB: You filed a bug about being able to run "bzr reconfigure --branch" in a svn working copy
<SamB> jelmer: yes
<spiv> mwhudson: if you want to improve them, you're the one with the commit privs for python, not me ;)
<SamB> I'm either for or against
<jelmer> SamB, that doesn't make sense though, as subversion doesn't support working copies that carry a branch
<jelmer> SamB, you would have to upgrade to a bzr format first
<SamB> jelmer: oh. why first?
<SamB> that sounds inefficient
<jelmer> SamB, That's how reconfigure works
<SamB> and also why does it take reconfigure so long to figure that out ?
<spiv> SamB: "bzr upgrade" is really "bzr change-format"
<jelmer> SamB, it's pretty much instantaneous here
<SamB> plus, the bzr upgrade part doesn't seem to work either :-(
<spiv> (but usually the only time you want to change format is to upgrade to a newer, better one, hence the name.)
<SamB> jelmer: what SVN server ?
<jelmer> SamB, gnome
<SamB> huh. and you don't live in gnome?
<jelmer> SamB, it might do some analysis of the repo first, but that should be cached
<SamB> jelmer: I don't see why it needs to analyze the remote repository just to figure out it can't do a reconfigure in that directory!
<jelmer> SamB, reconfigure probably looks at the branch tip before it tries to initialize a branch
<jelmer> and that requires bzr-svn to do some analysis
<SamB> well, okay, lets move on to Bug 340854
<ubottu> Launchpad bug 340854 in bzr-svn ""bzr upgrade" fails rather slowly on SVN working directories" [Undecided,Confirmed] https://launchpad.net/bugs/340854
<jelmer> SamB, I've just commented on that one
<SamB> oh. I wish it didn't take so long for email to make it from launchpad to gecko ...
 * SamB frowns at Low
<jelmer> SamB, You can just checkout from svn in the proper format
<SamB> jelmer: shouldn't it check whether or not it can finish the job before starting ?
<SamB> it rather rudely moved all these directories in my checkout ...
<SamB> oh, and I'm not quite sure what it failed to do, either!
<SamB> why'd it leave me like this:
<SamB>        control: Meta directory format 1
<SamB>   working tree: Working tree format 4
<SamB>         branch: Subversion Smart Server
<SamB>     repository: Subversion Repository
<SamB> isn't that a little insane ?
<jelmer> SamB: This is what I mentioned in my bug report, there's no way for bzr-svn to control the upgrade process
<jelmer> s/bug report/bug reply/
<jelmer> SamB, Bazaar just assumes WorkingTree format 4 knows how to upgrade from a svn working copy
<jelmer> but it doesn't and blows up
<SamB> jelmer: well, now I'm bitching about how Bazaar just assumes that
<johnf> excellent new bzrtools. Off a packaging I go
<spiv> SamB: yeah, that's a real bug
<spiv> SamB: not many users try to "bzr upgrade" bzr-svn branches to other formats, but we would like it to work.
<Kobaz> how would i make bzr st and friends just show the filenames themselves without the path
<SamB> any idea what the "conflict adding file" business was about ?
<SamB> spiv: or at least fail at the beginning instead of half-way ?
<Kobaz> like: cd /working_path/foo/bar; bzr st
<spiv> SamB: that would be a start
<Kobaz> and all the files are prefixed with their paths...
<spiv> SamB: actually working would be better :)
<Kobaz> even if i do bzr st *
<TDT> Hey all.  I've been asking around a bit about this and spent anumber of hours on this.  I was just curious, was there a good way to basically create a "glue" between git and bzr?  TBH since I use git for 90% of my work, I'd prefer to be able to manage the bzr repositories I need to through git as well. I've read about the fast-export and fast-import, but have been having a lot of problems getting this all to work correctly.
<SamB> and, of course, bzr-svn should be the package responsible for determining whether or not it works ...
<spiv> SamB: right.  The problem is that the upgrade code in bzrlib isn't yet flexible enough to let bzr-svn hook in when it needs to.
<jelmer> TDT, I'm working on a plugin called bzr-git that allows accessing git branches as if they were bzr branches
<SamB> hmm, well, for some reason I decided to re-run the "bzr reconfigure --checkout" command after the "failed" upgrade run ... it hasn't failed yet, but there's still plenty of time for it to get around to failing ;-)
<SamB> jelmer: oh, there isn't one yet?
<SamB> and will it interoperate with git-bzr ?
<jelmer> SamB, bzr-git is a work in progress but doesn't support e.g. writing to git yet
<TDT> jelmer: *nod* yeah I've been using git-bzr for the opposite of that, it's out of development now,and...the guy has no reason to bother, heh.
<jelmer> SamB: well, it won't recognize shared history with git-bzr
<SamB> hmm. git-bzr isn't in my package database. maybe I don't care.
<TDT> http://github.com/pieter/git-bzr/tree/master -- this is the project I was talking about
<TDT> It's not standard included with git-0core, it's an addon.  I don't know if others exist
<jelmer> TDT, yeah, I'm aware of it
<jelmer> TDT, it basically allows access to bzr branches from git, whereas git-bzr allows access to git branches from bzr
<SamB> jelmer: you got your package's name backwards
<TDT> jelmer: Yeah, but I'm kinda assuming both rely on the git-fast-export/import and bzr-fast-export/import, am I right?
<jelmer> TDT, no, bzr-git doesn't use fastimport/fastexport
<TDT> Hmm, definitely perked my interst in how you got that to work then
<jelmer> SamB, whoops, sorry - it's getting late :-)
<TDT> I want something that works the opposite, but it relies on way too many dependencies that it's causing issues..been a real pain anyways.  Been reading way too much on it, it may turn into something I need to work on more over time.
<SamB> hey, it's an easy mistake to make, especially in that conversation ;-)
<jelmer> TDT: what do you mean with "something that works the opposite" exactly?
<jelmer> TDT, bzr-git does more than just fetching from git into bzr and vice versa
<jelmer> TDT, it allows all of the Bazaar API to be used with git repositories
<jelmer> (or that's the goal, anyway)
<TDT> jelmer: Yeah, I understand that.  Your solution goes from the idea of using bzr as the baseline.  My goal is to do the opposite, use git to read bzr branches and use git commands and "push" changes to a bzr bound branch.
<SamB> jelmer: will it allow bzr upgrade --format=git ?
<jelmer> SamB, No, as the upgrade code in bzr isn't flexible for that yet as we've just concluded :-)
<jelmer> SamB: In due time, yes
<SamB> jelmer: but you said it was the target format that was responsible for providing the conversions
<SamB> so I figured that might be okay then ;-)
<johnf> can someone check http://inodes.org/johnf/debs/bzr before I upload them to beta ppa
<jelmer> SamB: Right now the target format is responsible, it should be a combination of the source and target format though
<jml> spiv: https://lists.ubuntu.com/archives/bazaar/2009q1/054539.html
<SamB> jelmer: yeah
<jelmer> TDT, I thought git-bzr just depended on ruby and fastimport/fastexport ?
<TDT> jelmer: it does, it's going by a different idea than what you're doing - which is why I'm pretty interested in what you're doing :)  For whatever reason the whole fastimport/fastexport thing is horribly broken for me right now
<jelmer> TDT: Something like bzr-git wouldn't be possible in git, as it doesn't have an API that's abstracted like bzr
<jelmer> TDT: It's just a collection of command-line tools with a specific file format
<SamB> hmm. too bad git-fast-export doesn't support ASCII armoring of binaries ...
<jelmer> SamB, hmm
<jelmer> SamB, the fact "bzr upgrade" breaks the working copy is a bit annoying indeed, I've upgraded the bug to medium
<SamB> :-)
 * SamB wonders if this second "bzr reconfigure" is going to work
<jelmer> SamB, it might, but only because the working tree is now workingtree format 4
<SamB> yeah, I figured that was why it had gotten as far as it has
<SamB> [######/             ]  18995kB @    2kB/s | copying revision 3363/10231
<jelmer> that looks about right
<SamB> I'm just wondering if it's going to (a) crash part-way through complaining about
<SamB> bzr: ERROR: bzrlib.errors.NoSuchRevision: <bzrlib.plugins.svn.revids.RevisionIdMapCache object at 0x89ee70c> has no revision svn-v4:c7f1d35c-780e-0410-8b2b-bc164f6bbeca:coq-local/trunk:8620
<SamB> or something else wierd
<SamB> or ... will it actually work ?
<jelmer> SamB: Is there any reason you're upgrading an existing svn working copy rather than just doing "bzr branch <remote-svn-url>" ?
<SamB> jelmer: well, I might have some local changes
<SamB> that, and I like trying things to see if they work
<jelmer> SamB, well, the latter is certainly appreciated :-)
<SamB> and if they don't, I like them to fail as gracefully as possible
 * SamB goes to bed
<jelmer> SamB, bug reports like these are useful, even if they're blocked by bzr :-/
<SamB> you're welcome
<johnf> anyone? can someone check http://inodes.org/johnf/debs/bzr before I upload them to beta ppa
<lifeless> johnf: if they work for you, jfdi
<lifeless> -> lunch
<johnf> fair enough. Only real issue is people will need a newer builddeb package
<james_w> why's that?
<james_w> <- lunch
<johnf> james_w: it works but has an annoying deprecation error
<johnf> usr/lib/python2.5/site-packages/bzrlib/plugins/builddeb/revspec.py:68: DeprecationWarning: Modifying SPEC_TYPES was deprecated in version 1.12.
<johnf>   SPEC_TYPES.append(RevisionSpec_package)
<johnf> about to go see if there is a bug
<james_w> it's fixed
<johnf> excellent
<james_w> it's just a warning though, so it shouldn't prevent things working
<mwhudson> jml: i'm using lp-open a lot now, thanks for doing that! :)
<lifeless> poolie: AllowDeactivateGrabs in man xorg.conf
<jamesh> note that that setting effectively kills the security of the screen lock
<jamesh> kill the grab and alt+tab away from the screen saver
<poolie> because people can send input to tasks behind it?
<poolie> heh
<poolie> DisableXorgBugs true
<jamesh> it isn't a bug: the feature works as advertised.
<jamesh> and there is a reason it is disabled by default
<lifeless> jamesh: actually, there is a new api for screen savers
<jamesh> if you need it and are not developing X software that performs grabs, then that is a bug
<lifeless> An API was written to such cases.  If you enable
<lifeless>               this option, make sure your screen saver/locker is updated.
<lifeless> jamesh: there are bugs; see under software
<lifeless> for instance, drag and drop in gnome takes grabs
<bob2> and firefox
<mwhudson> hm
<mwhudson> what are the chances that the latest change to bzr.dev will end up in 1.13?
<mwhudson> i guess i can always cp it onto the branch of bzr we use
<james_w> mwhudson: should be pretty uncontroversial for a cherry pick to the release branch if you want to mail the list about it
<poolie1> mwhudson: what was it?
<lifeless> pulling out the branch scenarios generation to a helper
<mwhudson> poolie1: moving the generation of branch scenarios into a separate function
<lifeless> mwhudson: did you get the chk repo?
<james_w> vila: p:~james-w/+junk/favourites-package
<james_w> with an l of course
<johnf> should we remove the feisty 1.12 packages from the beta ppa seeing as feisty is now EOL?
<lifeless> johnf: so, bzr-builddeb, what about it?
<johnf> lifeless: works fine just a deprecation warning
<johnf> which is already fixed in trunk
<lifeless> johnf: are you going to upload the fixed version to the ppa?
<johnf> that was my next question. bzr-beta ppa doesn;t currently have builddeb packages. Do we want it to?
<lifeless> let me do a straw poll
<johnf> I vote yes and am happy to make it happen :)
<johnf> jelmer: are you going to create new bzr-svn packages in the beta-ppa or would you like me to do it?
<lifeless> johnf: so, mostly 'shrug', one 'no', couple of yeses
<lifeless> so - do it, I think. I'll wear the blame if its wrong :)
<johnf> cool
<johnf> lifeless: next thing is best way for me to get my packaging changes commited
<johnf> I could just branch those repos into beta-ppa or maybe we just move them
<johnf> probably makes more sense to have them there since most of the packaging work will happen in beta and then the final packages can just be copied to the bzr ppa
<vila> james_w: thanks !
<james_w> vila: no problem, let me know if the instructions aren't clear
<vila> james_w: I'll do that
<lifeless> johnf: let me rename them
<lifeless> johnf: The price is that you update the docs and put forward a [MERGE] with the changes
<johnf> I already have a heap of edits for ppa.txt that I'll put up soon
<johnf> also some changes to the packaging scripts
<lifeless> johnf: what are the branches you need access to
<johnf> lifeless:  lp:~bzr/bzr/packaging-* although you can probably kill off feisty and  lp:~bzr/bzrtools/packaging-*
<lifeless> oh hmm
<lifeless> johnf: ok, the easiest thing here is for you to join the bzr team
<lifeless> you'll get bugmail; but you have procmail ? :)
<lifeless> johnf: the ppa docs about joining the beta team to be able to do this are probably necessary but not sufficient
<johnf> I have sieve but yes :)
<lifeless> ok
<johnf> is it easier to just branch them into beta an pull every so often?
<lifeless> no, easiest is to give you lots of mail
<johnf> fair enough
<lifeless> if thats ok
<lifeless> in a technical sense we probablt want a bzr-ppa team, which has bzr as a member, and owns all th epackaging branches
<lifeless> and is a member of bzr-betta-ppa, bzr-ppa, etc etc
<lifeless> but right now, JFDI time :)
<lifeless> whats your lp account name?
<lifeless> johnf: ^
<johnf> lifeless: johnf-inodes
<lifeless> done
<spiv> New way to break the test suite: put a bzrdir in /tmp with a default_stack_on in its control.conf
<lifeless> slick
<Smiskis> Bzr or Git? How do they differ? Why do you prefer Bzr?
<lifeless> http://bazaar-vcs.org/BzrVsGit
<Smiskis> I heard about an SCM that was sprung from "mathematical" theory - with operations of more "logical" nature, supposedly created by academic people... anyone know what im talking about?
<lifeless> possibly monotone, or codeville, or darcs
<Smiskis> must be darcs
<Smiskis> thanks lifeless
<lifeless> Smiskis: no probs
<poolie1> vila: "Wed Mar 11 06:43:20 2009 UTC: Vincent Ladeuil <v.ladeuil+lp@free.fr>, Request for non-PQM managed branch." ie your branch is going to bounce
<SuperMMX> pwd
<spiv> poolie1: same for yours!
<poolie1> i know
<poolie> here's an interesting thing: orcadas got noticeably faster when it was upgraded to hardy
<poolie> some combination of kernel and python
<poolie> pqm could possibly get faster too
<lifeless> poolie: running parallel tests would probably be faster too :P
<bialix> hi, anybody with Python 2.6 installed? I need a little help to check 2.6 behavior
<spiv> bialix: sure
<spiv> poolie: ooh, you broke bzr+ssh :P
<bialix> can you check stream attribute as I shown here: http://permalink.gmane.org/gmane.comp.version-control.bazaar-ng.general/53539
<bialix> I'd like to finish my patch, because igc is busy
<poolie> spiv, do you get a failure in __repr__?
<james_w> bialix: python 2.6 shows the same behaviour here as in your email
<bialix> thank you!
<bialix> I'll add simple smoke test for that bug and will send the complete patch then
<clemente> Hi, a patch I sent has to be marked as superseeded by another one in Bundle Buggy. I don't have a login. How do I proceed?
<George2> hi
<George2> what's the difference between bzt init and init-repo? am i right in thinking that to create a repo, i can either bzr init, and if no repo exists in the parent dir, it will create one in the current dir?
<SamB> init-repo doesn't create a branch
<SamB> that's the main difference
<SamB> that, and init-repo creates a repository whether you're in one or not, I assume ...
 * SamB wonders what computer is pulling down data at 200K
<fullermd_> init-repo creates a shared repository, that later branches can use (and share).
<fullermd_> init creates a branch, which will use an existing shared repo if there is one, or create an internal [private, non-shared] repo if there isn't.
<SamB> oh, it can't be shared ?
<fullermd> init won't make a shareable one, no.
<fullermd> You could probably trick it into being sharable later by manual ad-hackery in the bzrdir.  But I don't recommend it.
<SamB> what's the difference between a shareable repo and an unshareable repo?
<fullermd> A shareable repo can be used in common by multiple branches.  An unsharable one can't (and generally doesn't exist except hidden inside the branch that owns it)
<fullermd> Basically, a share repo is the only sort of repo you ever see or interact with in any way.
<fullermd> You never create a non-shared repo, it just happens when you make a branch that can't find an existing shared repo to use.
<fullermd> This also means that colloquially, any time somebody talks about a "repo", they almost certainly mean an explicitly-created shared repository, unless they're discussing internals or relatively arcane implementation details.
 * SamB contemplates bzrcrush
<George2> thanks guys, that helps a bit!
<George2> a la git, switching from one branch to another in the same dir is simply a matter of checking out the different branch, how do i do this with bzr? the init-repo --no-tree option is confiusing me
<fullermd> That's probably a side effect of init-repo --no-trees not really having much to do with that problem   :P
<fullermd> (well, it's usually a step in the process, but doesn't directly bear on it)
<George2> oh
<George2> trying to wrap my head around the user guide
<fullermd> The central command to think about in that case is 'switch', which throws a working tree from one branch to another.
<George2> is the only way to create a separate branch in a new dir and then merge?
<SamB> George2: did you see the GitStyleBranches wiki page?
<George2> SamB: no?
<SamB> well, it's kind of new
<George2> fullermd: oh, so just simply bzr switch newbranch
<fullermd> Yah.
<George2> wow, nice
<fullermd> Details like setting up a --no-trees shared repo are often parts of _setting up_ a layout where you later do that.  But they're not strictly speaking necessary parts of it.
<George2> what's the no-trees option for then?
<SamB> George2: are you using a lightweight checkout?
<George2> SamB: no, trying to get my head around normal checkouts!
<SamB> oh, it just keeps your storage branches from having working trees
<George2> lightweight is history-less right?
<fullermd> Basically, it all makes a bit more sense if you grok the triumverate of Working Tree, Branch, and Repository.
<SamB> George2: oh ;-)
<SamB> lightweight is good for doing git-style switchable branch checkouts, actually
<fullermd> Don't worry about lightweight vs heavy checkouts, at least at the start.  The differences shouldn't affect the semantics (if they do, it's probably a bug), and it can be a little confusing.
<SamB> fullermd: oh?
<George2> fullermd: the userguide is great from what i've read - half way so far, but the intro about explaining the terms is perhaps the only weak part
<SamB> what about the parent/push paths ?
<fullermd> (not to say the differences are unimportant, but..)
<SamB> I'll agree that other differences are probably bugs
<George2> doesn't lightweight only affect what is pulled - ie. branch history?
<fullermd> See, this just goes back to my periodic bitchings about leaky abstraction on [heavy] checkouts   :p
<SamB> but don't try to convince me that bzr isn't full of bugs of that sort ;-)
<fullermd> George2: Basically, just use this rule of thumb; if the branch is on the local machine, use a lightweight checkout.  If it's on a remote machine, use a regular (heavy) checkout.
<George2> oh
<SamB> anyway, if you have a --no-trees repo with your branches in it in the next dir over, you still have all the history right there ;-)
<George2> well i'm looking for a single-dev local maching setup
<SamB> I mean, assuming that's what the lightweight checkout is bound to
<George2> except depending on the project, my workflow may change, so i'm just trying to wrap my head around it all!
<George2> should i have a repo for each project, or can i have a projects dir?
<SamB> anyway, if you do look at the GitStyleBranches page, please give any comments about what isn't clear enough
<George2> SamB: url?
<fullermd> Generally, a repo per project is a good demark.
<SamB> I don't bother unless I actually want more than one branch
<fullermd> You could stick everything in one repo.  Or you could not use shared repos at all.  Or anywhere in between.
<fullermd> But sharing a repo across projects generally gives very little gain.  And using more than a very few branches of one project without one is pretty wasteful.
<SamB> http://bazaar-vcs.org/GitStyleBranches
<SamB> George2: I can see why you wanted the URL
<SamB> it doesn't really google too well yet, does it?
<SamB> google's top hits on the wiki are RecentChanges and WordIndex ...
<George2> fullermd: i'm looking for a way to store a cms core, and modules for the cms. i essentially would like to be able to checkout the core files, and then the modules. but i maintain some modules, so can i have a repo inside the modules repo for each module i maintain?
<fullermd> Well, you can put one shared repo under another in the filesystem.  But they don't have anything to do with each other.
<fullermd> I'd generally discourage that, just because it can open up chances for you to get confused about what's where.
<George2> SamB: first line: [...] it's true than many Git users like its approach and it does have benefits worth noting: -- add some context, does the quote refer to git or bzr?
<SamB> George2: refers to git
<George2> fullermd: oh, so what solution would you suggest?
<SamB> at least, I assume
<SamB> George2: is that what you thought?
<George2> should i have a repo for others modules, and a repo for mine?
<George2> SamB: after reading a bit yeah, but it's not immediately clear. this is your site right?
<George2> oh no, sorry - hehe
 * George2 checks the url ;)
<SamB> I did make the wiki page though
<SamB> but I didn't write that part
<SamB> copied it from the linked section
<fullermd> Well, a lot depends on just how much breadth you get.
<fullermd> I mean, if you only have one branch of a given module, a shared repo buys you nothing.
<fullermd> If two modules share no history, then having them use a common repo also buys you nothing.
<George2> fullermd: for others modules, i'm just looking for a place to esesntially dump them i guess, but i'd probably have a few branches for my modules
<SamB> shouldn't there be a flag to "bzr init" that tells it not to use a shared repo ?
<SamB> I can't seem to see it in the HEAD
<SamB> well, it is the HEAD as of the night before last ...
<fullermd> Modules are pretty small, presumably, so history probably doesn't eat that much space or I/O.  I'd suggest just ignoring shared repos for them for right now, and letting them be standalone branches.
<George2> SamB: yeah there is, i think i remember reading about it
<fullermd> Then you can see what works and where you might benefit from repos, and retrofit them in later.
<SamB> all these branch format flags are a bit distracting
<fullermd> I don't think it does.  You could reconfig it afterward.
<SamB> I think the user should be advised to see "bzr help upgrade" for the documentation for those, personally ...
<SamB> it's too bad you can't use javascript to make things collapsable in terminal-based UIs ;-P
<George2> ok so i'm confused fullermd! so you're suggesting a shared-repo in say /modules. and then each module (~40kb) is a subdir of /modules?
<SamB> George2: not really
<SamB> the shared repo there wouldn't really get you anything
<fullermd> Well, what I'm really suggesting is a bit more meta than that; don't worry about shared repos there period, at least for now.
<SamB> yeah.
<fullermd> Shared repos don't have semantic value; they save you storage space and I/O bandwidth.
<fullermd> But everything else (there are some arcane exceptions, but you don't care) will act exactly the same whether the branches share a repo or not.
<SamB> if that happens to be inside one, no big deal, but it won't buy you anything to explicitly create one there
<fullermd> And it's not very difficult to reorganize things later to add shared repos around parts of the branch set.  So your initial decisions in that area aren't cast in stone.
<SamB> fullermd: and the exceptions are going to be far fewer and farer between than the differences between lightweight and heavyweight checkouts
<fullermd> They're not even cast in foam latex...
<George2> mhh, i wonder, instead of having a separate core and modules repo, maybe combinging the two would be best
<SamB> George2: you mean having them all in one branch ?
<fullermd> I think you're worrying a little too much about repo boundaries.  Maybe you're thinking SVNish, where the repo is an important semantic boundary?
<George2> exactly
<SamB> or darcs or git?
<George2> well i'm trying to get my head around a workflow that will be benficial
<George2> i've just come from git, it was too limiting
<fullermd> Or gitish, where it's an important (in a totally different way, and much more malleable) boudnary as well.
<SamB> well, are the modules developed seperately from eachother?
<George2> SamB: yeah they are
<SamB> but he's not scarred enough to come from tla
<George2> SamB: but to me as they're not my modules, doesn't really affect me
<George2> tla?
<SamB> George2: well, where are you getting them from?
<SamB> George2: you don't want to know ;-)
<fullermd> How 'bout this; unless you have a component with "a lot" of history (>50 megs, maybe), that you'll have more than a few branches of, forget init-repo exists.
<George2> SamB: a cvs repo / downloading from modules site
<George2> hehe - that simple
<George2> the userguide doesn't really mention that at all fuller
<SamB> and who is going to access the bzr branch(es) you are making?
<George2> SamB: just me
<fullermd> Well, a great thing about bzr is how flexible it is, and how many ways you can combine the pieces depending on your specific needs.
<SamB> well, just do whatever then
<fullermd> One terrible thing is that it's very flexible, and you can combine the pieces a lot of different ways depending on your specific needs.
<SamB> I might make a different branch for each source of code
<fullermd> So it gets really hard to say "just do X, Y, Z" without reference to a specific case.
<George2> fullermd: its flexibility is what attracted me here
<fullermd> In this case, the CMS core may be large (in terms of the tree size, and in terms of history size), and you may have many branches of it hanging around.
<fullermd> So a shared repo can gain you a lot there.
<SamB> maybe one would be an svn checkout (BZR format, probably -- it's faster ;-)
<fullermd> The modules, though, are presumable small (in both tree and history), won't have common history with each other, and you probably won't have all that many branches of any individual one of them.
<George2> fullermd: drupal. the core is about 2mb i believe, currently 3 major versions, 1 of them still in dev
<fullermd> So repos aren't necessarily going to gain you very much.  And working out just where they can be put to help you out, especially in advance, is probably more trouble than it's worth.
<SamB> I wouldn't involve any repos unless you find yourself with a couple of branches of the same module
<George2> the modules, are small, and i just want a repo to dump them and pull out of as necessary. though the modules i maintain, i'd like to have a separate repo for each i guess
<fullermd> OK, there you're using "repo" in a way that doesn't really mean anything (or anything like a repo, anyway) in a bzr sense.
<SamB> of course, setting all the checkouts up might be a bitch, so maybe I would just dump the modules all in one branch ...
<SamB> fullermd: I think he means branch
<George2> a bzr branch != cvs branch
<fullermd> Well, more specifically, probably treeless branch.
<SamB> hmm ?
<fullermd> Though whether the treeless really matters much may be questionable.
<SamB> George2: describe how you would like to use the VCS setup
<George2> ok, so i would like to be able to checkout a version of drupal with related modules for that version to assist in a speedy setup of a site. i'd also like to be able to log changes to my modules that i make for that core version of drupal
<fullermd> George2: I would suggest chewing a bit on WT, Branch, and Repo until you grok them separately.  Then it'll be easier to work out which you want where, which makes it real easy to figure out how to lay things out.
<George2> there are perhaps 40 or so modules, and about 5 of mine
<George2> ok
<SamB> would you mind terribly having to check each of yours out seperately?
<George2> samb, prolly not
<SamB> like, would it be okay like this: 1) check out drupal 2) check out modules directory containing foreign modules 3) check out each of my modules
<George2> i'd like of course to have the ones i checkout to be two-way synced up to the repos
<SamB> where by "my" of course mean your
<George2> SamB: i'd like to checkout a version of drupal, and get all teh modules for that version
<SamB> oops. I forgot an I in that last sentence
<SamB> George2: well, this way might make it easier to track bugfix releases
<SamB> also you could set up a script for it or something ...
<SamB> how many of these websites do you make?
<George2> ohhh
<George2> so Repo -> working tree -> branch
<George2>               \> another working tree -> branch etc ?
<fullermd> Another option (just to complexify things) is to create 'rollup' branches, where you combine a given drupal version with whatever modules make sense for that version, merging from the various sources as necessary, so you have a single branch to work from for deployments.
<SamB> yeah
<fullermd> (ignore that of course; I'm just making trouble  :p)
<SamB> I thought of that
<George2> fullermd: so a middle inbetween branch
<George2> so all sources, combing sources, and new projects are a checkout of the combining sources
<fullermd> Not exactly...   a WT "points" to a branch, and a branch "points" to a repository.
<George2> i've thought about that for git
<fullermd> (generally the pointing is implicit rather than explicit, but...   implementation detail)
<SamB> George2: how did you want to do it with git?
<George2> oh so each branch has its own wt
<fullermd> A WT is where you have working files, that you can read or run or print or compile or make changes to or whatever.
<SamB> George2: can have
<fullermd> A branch defines a particular history, the past revisions, and what revision is the current 'head'.
<fullermd> A repository is basically just a big bucket full of revisions, with no ordering or anything like that.
<SamB> you can think of a branch as being a bit like a one-head git repository
<fullermd> So phrases like "check out a repository" don't make any sense in bzr.  You can only "check out" a revision, but a repository is just a big sea of revisions, with no indication of which one you might be interested in.
<fullermd> A branch [practically] necessary has a repository somewhere; otherwise it wouldn't have anywhere to store revs.
<George2> i see
<fullermd> The branch serves to tell you WHICH revs are important in a given case, by saying "this is the current head"
<SamB> well, yeah, a branch with no repository is like a broken symlink
<SamB> even an SVN branch needs a repository
<George2> so the branch indexes what revisions are important to that particular branch from whichever repo? hence the need to refer to the repo
<fullermd> Right.
<fullermd> This is fundamentally the same as git, though different pieces are visible.
<fullermd> The git moral-equivalent-ofrepo is also a giant bucket full of revisions, and the 'branch' is a pointer to one (via its SHA1 hash)
<fullermd> The branch is just a file hidden under .git/, rather than an explicit exterior directory.
<ronny> gits is more like a buked of "objects"
<George2> ok, so essentially, would it make sense to have a repo that stores drupal and the related modules for that version. with each version being a branch. and a repo for my modules with each module being a branch?
<fullermd> Well, it's a bucket of somethings, and the branch lets you refer to somethings.  Don't get technical  :p
<SamB> ronny: well, a lot of those objects are commits
<SamB> and most of the rest are referenced only via commits
<ronny> SamB: more of them are tree's and blobs
<fullermd> George2: Think of it in terms of revisions.  If two branches share no revisions, then having them use the same repository doesn't gain anything.
<SamB> those can be viewed as part of the commits, for the most part
<fullermd> So, e.g., having drupal and some module sharing a repo doesn't save you anything, versus having them be standalone (and thus each having its own repo internally)
<fullermd> On the other hand, having 2 branches of drupal share a repo probably gains a lot, because presumably a lot of the history is common, up to the point where the branches diverged.
<fullermd> So, in one sense, it makes more sense to have the various branches of drupal grouped together one place, and the modules in another.
<George2> fullermd: i understand that - kindof - but having a repo for each module is overkill no?
<George2> i don't particularly want to have to set up 40+ repos just for the modules
<fullermd> Probably.  Unless the module is big or has a lot of branches, it's probably more trouble than it's worth.
<fullermd> Well, that's why I said don't set up repos for the modules period  ;)
<George2> fullermd: but i want the modules to be associated with the core version of drupal!
<fullermd> Repos don't do any sort of association.
<fullermd> All they do is share storage space.
<fullermd> Like I said, I think you're assigning way too much meaning to them.
<George2> probably
<fullermd> (by 'repo' in this part of the discussion I mean "shared repo" the thing you create with init-repo.  In the earlier WT/Branch/Repo discussion, I meant it as the underlying object in the bzr gestalt)
<fullermd> So, let's suppose you have a /work where all this goes.
<fullermd> You have /work/drupal/1.0 and /work/drupal/2.0 and /work/drupal/3.0 (or whatever branches of drupal there may be)
<George2> actually. i'm mistaken. i think i do need a middle ground
<fullermd> And also /work/modules/foo and /work/modules/bar and so on.
<fullermd> Using init-repo to make /work/drupal a shared repository can be a useful thing to do, since those branches will have common history.
<fullermd> But for now, I'd just totally ignore init-repo in the /work/modules/ hierarchy.  Just let them all be standalone branches, with the internal private repos 'init' (or 'branch' or however they come into being) creates for them.
<George2> ie. i have a drupal core repo, i have a modules repo and for each major drupal core i have a set of plugins, and then a repo for each of my modules. if i then set up a repo to store checkouts as necessary from the specific branch from each repo, and then i checkout from this  that should work right?
<fullermd> And ignore init-repo _conceptually_ in /work/drupal/ too.  It doesn't make anything act differently from having those be standalone branches too, just a bit faster and a bit smaller.
<fullermd> No, not a modules repo.  No repo.  Ixnay on the eporay.  There Is No Repo.   :)
<fullermd> Just a directory under which you have a lot of branches for modules.
<George2> damnit! but a repo stores branches no?
<fullermd> No, a repo stores revisions.
<awilkins> A branch is really just a pointer to one revision
<fullermd> A shared repo can be used by multiple branches.  That's what sets it (what you make explicitly with init-repo) apart from the Repository that's a underlying piece of how bzr works.
<fullermd> Branches (so to speak) store themselves.
<fullermd> Mmm.  Clear as mud?  Maybe we should back up...
<George2> ok, i didn't explain that properly. i understand about a drupal repo to share revisions
<SamB> http://hpaste.org/fastcgi/hpaste.fcgi/view?id=2298#a2298
<George2> but then for each drupal core, i could have a branch with a set of modules in for that specific core right?
<fullermd> In day to day operations, the repo is completely uninteresting.  Nothing you do will ever interact directly with it.
 * fullermd suspects we're talking about too many things at once...
<SamB> any idea how to fix the conflicts in the above-pasted "bzr info" output?
<George2> ok, so in its simplest terms at the most basic level. a branch for drupal 5, branch for 6, branch for 7. branch for modules for 5, branch for 6 modules, branch for 7 modules. branch for each of my modules?
<George2> fullermd: i think i'm locked too much into the cvs / svn workflow idea
<fullermd> The big thing that bites you there (next to the importance of repos, anyway) is that in CVSVN, you tend to have one big tree that you check out and work on parts of.
<SamB> some people even check out all the branches at once
<fullermd> Whereas in bzr, you pretty much always work with whole branches, never with parts of branches or with conglomerations of multiple branches.
<SamB> I dunno why
<SamB> I had assumed at first it was ignorance ... but one guy said he did it that way on purpose ...
<fullermd> So in SVN, the repo boundary is vital, while branch boundaries are not only unimportant, they're terribly ambiguous.
<fullermd> While in bzr, the repo boundary is utterly meaningless, while the branch boundary is a hard line.
<SamB> nevermind that people might make a branch based on only part of the another branch ...
<SamB> or put a readme.txt where you might expect a branch
<SamB> or ...
<George2> i'm starting to get the meaningless-ness of the repo now
<fullermd> So how you want to subdivide branches (branch of all 5 modules, branch for each individual 5 module, etc) depends on at which granularity you'll want to work with them.
 * SamB is talking about the firebug repo
<George2> the repo is just an abstracted place to store revisions which is unimportant
<SamB> unimportant in theory, yes
<SamB> and in practice at small sizes
<fullermd> Right.  The Repository (object) is something that's always around one way or another, and directly stores the history.
<George2> fullermd: well having separate branches for each would be foolish as i don't particularly want to track each update. if an update is broken, i can rollback from the drupal module cvs
<fullermd> The repository (shared repository, thing you make with init-repo) is something you use to share space and I/O among related branches, but otherwise makes nothing act differently than if the branches were completely standalone.
<George2> whereas for my modules, i'd like to eb able to track each commit
<George2> fullermd: i understand that now - it's just an optimising process
 * fullermd nods.
<SamB> does drupal really use CVS ?
<George2> thanks for sticking with me :)
<George2> aye
<SamB> why the heck?
<fullermd> Yeah.  How you split those branches is pretty much dependant on how you'll expect to be updating/working on them, etc.
<George2> no idea
<fullermd> At one point, drupal had a semi-official bzr mirror.  I don't know whether that's still kept up or not, though.
<George2> fullermd: ok, so for each new drupal project, if i check out 40 modules, but decide i only want 10, if i remove them, it would affect the parent branch right?
<George2> i would essentially like each new drupal project to be a branch itself
<George2> fullermd: 4 kitchens have one for core
<SamB> it's just that CVS is so flaky -- why haven't they switched to SVN ?
<George2> SamB: no one to update it
<SamB> hmm?
<fullermd> Well, *I* never switched to svn.  It exchanges CVS's braindamage for its own, which may or may not really be a win in a given case.
<George2> what confused  me about git was clone, pull, fetch, checkout etc
<SamB> fullermd: well, I prefer atomic braindamage
<SamB> which brain damage of SVN's were you referring to, anyway?
<fullermd> The bizarre fluidity of its pseudo-branchiness, for one.
<SamB> oh, yeah, I do hate that
<fullermd> More abstractly, CVS's intense dainbramage has the advantage of being well known and plumbed, so Everybody (FSVO) knows how to deal with it and what actions to avoid.
<SamB> it works fine if you adhere to the trunk/branches/tags convention though
<SamB> though the fact that such "tags" are mutable is lamentable :-(
<fullermd> And it's there and running.  Moving to any other VCS is a moderately involved undertaking, so if you're gonna go through it anyway, might as well go to a good choice instead  ;)
<fullermd> Anyway.
<SamB> well, yeah, I guess
<SamB> but staying with CVS?
<SamB> that's harder to imagine
<fullermd> Drupal was at that time in the past at least fairly actively considering moving to bzr.
<George2> ok, so i think i have dir structured now - thanks!
<fullermd> But the last I heard of that was, like, 3.5 years ago or something.
<fullermd> George2: I would definitely take the stance that you'll set it up to experiment with, with the expectation of throwing your first organization away at some point.
<George2> however, what about minor updates? i'd like to have a browsable dir structure like drupal / drupal-6 / drupal-6--9 etc
<SamB> so does anyone have any idea about the conflicts in http://hpaste.org/fastcgi/hpaste.fcgi/view?id=2298 ?
<George2> fullermd: yeah, that's the painful part :(
<fullermd> http://drupal.org/node/45368
<fullermd> That's only ~ a year old, so it may still be being kept up.
<fullermd> It points at a LP import, so I'd guess so.
<George2> ohhh
<fullermd> SamB: It looks like a giant mess.  Smells like a merge of a near-exact copy of a tree you had sitting around, un-add'd in the dir before you merged.
<George2> i think i understand!
<SamB> fullermd: actually I tried to use "bzr upgrade" in an svn checkout
<fullermd> ...
<fullermd> Oh.  In that case I suggest "sobering up"   :p
<SamB> it half worked: https://bugs.launchpad.net/bzr/+bug/340854
<ubottu> Ubuntu bug 340854 in bzr-svn ""bzr upgrade" fails rather slowly on SVN working directories" [Undecided,Confirmed]
<SamB> then I ran "bzr reconfigure --checkout"
<SamB> and that actually worked
<George2> i *could* have a shared-repo for say a drupal-core branch and for each major and  minor version, just tag appropriately
<George2> bzr is just so damned difficult to type :/
<fullermd> That's just 'cuz it's not trained into your fingers yet.
<fullermd> Once it is, you'll find that 'bzr' is impossible to type.
<fullermd> ...
<fullermd> Dangit.  'bar' is impossible to type.
<fullermd> See what I mean?
<pigmej> fullermd: For me it's easy to type ;d
<pigmej> 3 fingers and "done" :d
<pigmej> easier than svn
<George2> svn and cvs are easy
<George2> git is nice
<pigmej> hmm
<George2> let's propose bzr changes its name :)
<pigmej> cvs is harder to write becouse of you need to change key on the same finger
<pigmej> bzr is to type with 3 different fingers, svn too
<pigmej> git too
<pigmej> Ehh i forgot, I have other layout ;d
<fullermd> cvs is 3 different fingers for me...
<fullermd> Actually, the only vcs that isn't that comes readily to mind is cdv.  darcs too, I guess.
<fullermd> Maybe baz if anybody still uses it.  But people left in that world presumably all use tla.
<Peng_> I think "hg" wins at typability. :P
<pigmej> Peng_: right ;d
<fullermd> Actually, it seems a bit lower for me.  It means yanking both hands away from home.
<pigmej> so let's make an "a" vcs
<pigmej> ;d
<fullermd> bzr is a quick rock with one hand.
<fullermd> git is more sensitive to timing between hands too.
<Peng_> How do Dvorak keyboards change this? :D
<fullermd> On the other hand, RCS wins because you don't even need to type the VCS's name before the command.
<pigmej> do you use qwerty layout ?
<George2> non-qwerty sucks for programmers
<pigmej> George2: I use colemak
<pigmej> ;d
<pigmej> for about 7 months and I'm really impressed
<pigmej> and happy
<nevans> my new years resolution was to learn colemak by the end of 2009... haven't made any real progress yet...
<pigmej> before colemak I used naturally qwerty ;d
<pigmej> nevans: First month was terrible...
<pigmej> First days was a #$%^&*
<pigmej> but now I'm very very happy :)
<nevans> pigmej: did you just switch to it for everything all at once, or ease yourself into it (an hour or two a day)?
<fullermd> Eek, what is colemak doing stealing my Ctrl key for an extra backspace?   :p
<pigmej> nevans: everything
<nevans> fullermd: I thought it did that with CapsLk, not Ctrl
<pigmej> fullermd: backspace is moved to capslock
<nevans> to CapsLk, I say good riddance.
<pigmej> and that's one of the best things in colemak
<fullermd> Only for silly people who didn't do away with their capslock already and make it a Ctrl.
<fullermd> It looks like it would suck for moving around in vi though.  So not much point...
<nevans> I've mapped it to Esc in the past, but that always winds up hurting me when I start vimming at someone else's computer.  ;)
<pigmej> fullermd: it's optional, there are coleak layout's without that modification
<George2> colemak?
<pigmej> btw nevans as I sad, I switched to colemak completly.
<pigmej> all hours on colemak
<pigmej> every single letter...
<pigmej> and the beginning was a little bit hard
<pigmej> now it's very very good ;d
<George2> i thought qwerty was designed to slow typists down
<pigmej> George2: right ;)
<fullermd> Not exactly, no...
<George2> why is it called colemak?
<pigmej> George2: becouse qwfpgj isn't good name ;d
<pigmej> because*
<nevans> http://colemak.com/FAQ#Why_is_it_called_Colemak.3F
<George2> and where's caps lock?
<pigmej> there is no capslock George2 ;d
<George2> i need a keyboard that has a $ key without pressing shift
<pigmej> why ?
<pigmej> php ?
<George2> what about apostrophe?
<George2> yeah php
<pigmej> George2: the changes to qwerty are not so big
<luks> I wonder if typing speed is really the bottleneck for you in programming
<luks> it surely isn't for me
<pigmej> but very very important
<George2> luks, not so much speed, but pressing shift for such an essential char is a pain, same with underscore
<George2> $_GET['foo'] = ugh to type
<pigmej> luks: less "distance" for fingers it's better
<luks> that's where you problems start, don't use $_GET :)
<pigmej> for our fingers ;d
<George2> an ampersand key would be nice too
<George2> until that day, i'm not switching!
<luks> pigmej: I personally spend less time typing than I do with other tasks
<George2> can i see a list of branches available ala git?
<fullermd> $_GET is easy, you just hold down shift the whole time   :p
<fullermd> And the _ is the only other char with the right hand, so that pinkie just takes a little nap on shift.
<pigmej> luks: I'm typing a lot...
<pigmej> my keyboards ( always MS natural ergo 4000 ) lives about 6-8 months ;d
<luks> must be very boring programming :)
<fullermd> Sunday is my keyboard's 18th birthday   :p
<pigmej> luks: programming is my hobby ;)
<pigmej> not a work :)
<luks> even worse then :)
 * fullermd would treat a keyboard with a 6 month lifespan with explosives...
<luks> my keyboards last for about a year, but for different reasons
<George2> i <3 my ms media keyboard, really comfy and right amount of firmness
<George2> unfortunately i don't have it here :(
 * fullermd ain't budging from his Model M.
<George2> is it not possible to switch to a tag directly? i have to use the revision number associated with that tag?
<fullermd> You can only switch to branches.
<George2> oh
<LeoNerd> A tag is a single static snapshot in time.
<LeoNerd> You could checkout, or export it.
<George2> no namespace registered for string:u'MY_TAG'
<Peng_> George2: "tag:MY_TAG"?
<George2> ohh
<George2> heh, file exists .... .bzr
<George2> trying to checkout in same dir
<George2> bzr forces a new branch to be a new dir doesn't it?
<Peng_> George2: Yes.
<Peng_> George2: There's some work being done on making that...not the case.
<George2> that's what i really like about git
<George2> making it so easy to be able to switch between tags and branches with a simple checkout
<awilkins> Model M 4tw
<Peng_> Earplugs 4tw
<Peng_> :P
<George2> can i get a one-way checkout? ie. if i checkout out a branch, i want to be able to delete files and hack at it, and then start a new project with it, but for it to still update if the parent updates
<Peng_> Isn't that what a branch is for?
 * Chipdancer waves to jml and wonders where poolie is
<George2> ,hh
<George2> uh oh. how do i pull from two branches into one?
<ronny> George2: if they diverged, merge
<George2> ronny - they're separate branches with no common ancestor
<hmeland> IIRC, in branch1, you can do "bzr merge -r 0.. /path/to/branch2" to merge the two branches' histories.
<derekS>  hey guys. Is there a way to validate my local repository?
<Peng_> derekS: "bzr check"?
<George2> omg, there has to be an easier way!
<George2> does this sound sane? i create a dir for drupal core files. i commit an empty dir. i branch from that and make a branch for modules. i put the core files in the core branch and commit. i put modules in the modules branch and commit. when i start a new project. i branch from core, and then merge in the modules branch
<derekS> Peng_: thanks!
<devilsadvocate> George2, that does not sound sane :P
<Peng_> derekS: BTW, some unimportant things like inconsistent parents can be fixed with "bzr reconcile", but you don't need to bother.
<George2> devilsadvocate: well how else can i merge two branches together that have no common base?
<George2> i want to make a project that pulls from two branches. that sounds sensible in itself right. that has to happen all the time?
<devilsadvocate> George2, what hmeland said?
<LarstiQ> George2: you could use the scmproj plugin
 * George2 scrolls up
<George2> hmeland: but the histories shouldn't be merged as they're  unrelated
<LarstiQ> George2: then merge/pull is not the operation you are looking for
<George2> so what is then?
<George2> i can't checkout as .bzr already exists
<derekS> Peng_: i just want to do a validate, time isn't an issue, so you would reccomend doing a check then reconcile
<derekS> just for the sake of doing it?
<Peng_> derekS: I dunno. reconcile is redundant if there's nothing wrong.
<LarstiQ> George2: I haven't scrolled back and analyzed your problem, but in passing it sounds like what scmproj would help with.
<devilsadvocate> George2, if you dont want the histories then why do you want to merge? as in, you could just make a folder and add the files
<George2> devilsadvocate: i'd like to have a 1-way relationship where if the files update in teh original branch, i can easily update in this branch
<devilsadvocate> George2, typically, if two things are separate, you should probably continue to keep them separate.
<devilsadvocate> IMO
<George2> that' not possible. cms / modules for cms
<George2> they have to be combined for a site project
<devilsadvocate> hm, your modules folder is within your cms folder
<George2> yep
<devilsadvocate> i you can remove individual files from version control. how about you add a single file, a symlink to the modules folder. dont add that to the repo. job done.
<LarstiQ> George2: I repeat, http://launchpad.net/bzr-scmproj
<LarstiQ> or devilsadvocate's advice if that's enough for you
<George2> LarstiQ: i'm looking at it now
 * LarstiQ trots off to work
<LarstiQ> George2: good luck
<George2> thanks
<George2> devilsadvocate: yeah, i've thought about symlinking, which would be a nice solution, and is something i'm using atm without version control. however, and export wouldn't resolve those symlinks right?
<devilsadvocate> George2, probably not, especially if they arent version controlled.
<devilsadvocate> im not sure
<George2> wow
<George2> devilsadvocate: i've put a file in a test repos anad commited, and in another separate branch added a symlink, and export resolves it ;)
<devilsadvocate> nice :)
<George2> as i'm working on a local machine only, that sorts it :)
<George2> that's genius!
<devilsadvocate> if your ftp or whatever you use to expose the bzr (if you do expose the bzr) is configures to follow symlinks, it will works remotely as well, then
<George2> yep
<George2> but this is just for a local machine atm, so this is perfect!
<derekS> Peng_: thanks :)
<Peng_> derekS: You shouldn't need to run "bzr reconcile" more than once, so I wouldn't add it to your cronjob or whatever.
<ronny> jelmer: aware of a gentoo overlay for subvertpy/bzr-svn?
<jelmer> ronny, I think the gentoo bzr overlay has both
<jelmer> ronny, http://launchpad.net/bzr-gentoo-overlay IIRC
<derekS> Peng_: i wasn't planning on it. i want to push my directory to the parent server, just wanted to make sure it was all good
<thecookie> Hmm. This is not really a bzr question, but.. I'm using eclipse. What is the smoothest way to work with a new branch? Seems a bit sucky to create a new project each time you want to work with a new branch.. and preparing it with the config files and such
<LarstiQ> thecookie: `bzr switch`
<thecookie> I see. Switch with my main branch? (Not sure it's called that but the branch I first checked out called trunk)
<derekS> anyone knwo of a decent ide for windows that does python and perl that natively supports bzr? Komodo is too expensive but fits the bill. Eclipse is a beast...
<ronny> jelmer: it does, thanks
<thecookie> Hmm. So, locally I would have a mirror of the master server, a local working tree and a new branch?
<devilsadvocate> thecookie, bzr bind?
<LarstiQ> devilsadvocate: no, just a lightweight checkout and switch
<thecookie> What should the master with the main branch host? A branch? Working tree? Checkout?
<thecookie> Locally I followed http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#team-collaboration-distributed-style
<cyberix> I'm trying to use "bzr send --mail-to=person@domain.com"
<cyberix> Evolution opens up, but tells me...
<cyberix> "You cannot attach the file `%2Ftmp%2Fbzr-mail-GPry9l%2Fmsk-32.patch' to this message."
<cyberix> "Cannot attach file %2Ftmp%2Fbzr-mail-GPry9l%2Fmsk-32.patch: No such file or directory"
<cyberix> Is this a known problem?
<LarstiQ> cyberix: not that I know of, does the un-urlencoded path exist?
<cyberix> Also when I pass the error, I notice that the email address is prefixed with ///
<LarstiQ> cyberix: that, however, is known.
<cyberix> LarstiQ: Yes it does
 * LarstiQ looks up the bug number
<cyberix> cyberix@eval:/tmp/msk$ du -b /tmp/bzr-mail-GPry9l/msk-32.patch
<cyberix> 1638	/tmp/bzr-mail-GPry9l/msk-32.patch
<LarstiQ> bug 291847 I believe
<ubottu> Launchpad bug 291847 in bzr "xdg-open mangles mailto: urls to ///foo@bar.com (dup-of: 294233)" [High,Confirmed] https://launchpad.net/bugs/291847
<ubottu> Launchpad bug 294233 in libgnome "running gnome-open 'mailto:user@acme.com' open thunderbird mail to ///user@acme.com" [Low,Triaged] https://launchpad.net/bugs/294233
<cyberix> I filed a bug
<cyberix> https://bugs.launchpad.net/bzr/+bug/341182
<ubottu> Ubuntu bug 341182 in bzr ""bzr send" fails to attach file in Evolution" [Undecided,New]
<LarstiQ> cyberix: I suppose send -o and attaching by hand works though?
<cyberix> Last time it failed I just corrected the email address and attached the file from tmp by hand
<cyberix> and the patch was applied
<LarstiQ> good
<cyberix> and it worked fine
<cyberix> should I still try using -o?
<LarstiQ> cyberix: nah, if it worked then, I trust it works now
<cyberix> ok
<kfogel> heh: lots of people seeing this error with recent dev sources?
<kfogel> bzr: ERROR: exceptions.AttributeError: 'Serializer_v5' object has no attribute '_init_inventory_with_root'
<kfogel> Anyone understand what's going on here: http://paste.lisp.org/display/76830
<kfogel> ?
<kfogel> kiko__: ^^ :-)
<luks> you probably want svn up
<luks> er
<luks> bzr up
<luks> :)
<kfogel> luks: I guess what's confusing me is: I've been using that bound branch as a local mirror of trunk for ages now, and all I've ever had to do is 'bzr pull'.  That has always updated my working tree, and afterwards I just do 'sudo python setup.py install' if I want to install the latest bzr dev sources.
<kfogel> luks: So why all of a sudden is it not updating the working tree?
<LarstiQ> kfogel: you haven't reverted it to a non head revision per chance?
<kfogel> LarstiQ: not to my knowledge.  Would there be some way for me to tell if I've done that?
<luks> brw, the result of bzr info -v doesn't seem to indicate a bound branch
<luks> *btw
<luks> you would see 'checkout of branch: http://bazaar-vcs.org/bzr/bzr.dev/'
<thecookie> So, even tho the main branch server didn't do an update, other people can do a pull from it after one has done a push towards it?
<kfogel> luks: hmrmrm.
<kfogel> cat .bzr/branch/branch.conf
<kfogel> parent_location = http://bazaar-vcs.org/bzr/bzr.dev/
<luks> that's parent location, not the bound branch location
<kfogel> luks: I may be using the term "bound branch" incorrectly.  I *also* did a 'bzr bind' to that URL when I edited branch.conf.
<kfogel> (This was all more than months ago.)
<kfogel> s/more than//
<luks> kfogel: well, what you have is a standalone branch, not a bound branch
<kfogel> luks: okay, thanks.  Any ideas why it would have been working (that is, updating the working files whenever I did bzr pull) before now?
<luks> do you want to use a standalone branch or a bound branch?
<kfogel> luks: I guess I'll go re-read the user's guide and make sure I understand those terms before answering!
<kfogel> :-)
<kfogel> luks: I can tell you the behavior I want, maybe that would help?
<luks> kfogel: sure
<kfogel> luks: I'm trying to maintain a pure mirror of http://bazaar-vcs.org/bzr/bzr.dev/ -- locally, I call it bzr.dev-trunk.  The only way changes ever get into bzr.dev-trunk is by me doing 'bzr pull', which would update both the branch and the working tree.  Periodically, I make further local branches of bzr.dev-trunk when I want to actually do development, but I never push changes back into bzr.dev-trunk from them, nor do I do 'bzr merge' in bzr.dev-trunk.
<kfogel>   It is intended to always mirror a current or past state of the bzr dev trunk, nothing more.
<kfogel> luks: this seemed to work for a while; today apparently it has stopped.
<luks> by making local changes you mean 'edit && commit' or just 'edit'?
<luks> because commit wouldn't be possible in such a bound branch
<kfogel> luks: both
<kfogel> luks: AFAIK, I've never done a commit in there.
<luks> oh, I misread a part of it
<rocky> jelmer: hey, why is it that when i install bzr-rebase (latest on bzr 1.13rc1) and do "bzr plugins" that rebase doesn't display ?
<rocky> but "bzr rebase" does actually work
<kfogel> luks: I've occasionally edited a file and then done 'bzr revert file' (I think -- not sure I've done even that)
<luks> kfogel: well, what I'd do it 'bzr up' in the current bzr.dev mirror
<luks> kfogel: then 'bzr bind http://bazaar-vcs.org/bzr/bzr.dev/'
<kfogel> luks: hunh.  Okay.  Thanks
<luks> kfogel: and then *only* 'bzr up' whenever you want to update from the remote location
<kfogel> luks: ???
<kfogel> Sigh.  I got a different answer from knowledgeable devs on the list when I started this process.
<kfogel> So you're saying 'bzr up' where I used to do 'bzr pull'?
<luks> kfogel: 'bzr up' is used in a checkout (bound branch), 'bzr pull' is used in a standalone branch
<luks> bound branch basically means you are working with the remote branch using the local working tree
<kfogel> luks: is "standalone branch" synonymous with "standalone tree" ?
<luks> um, I don't know what "standalone tree" is
<kfogel> luks: "checkout" and "bound branch" are exactly synonymous?
<luks> yes
<kfogel> luks: "standalone tree" is a phrase in the Users Guide (where I've been reading while we talk)
<luks> maybe they mean lightweight checkout
<luks> where no history is stored on the local side
<luks> but that's not very useful for you
<kfogel> luks: note that the parent directory of all this is a repository.
<jelmer> rocky, no idea, sorry
<kfogel> I did bzr init-repo, then set up bzr.dev-trunk, and then the other branches.
<kfogel> luks: don't know if that's relevant, but thought I'd mention it.
<jelmer> rocky, the listing of plugins is up to bzr itself not to the individual plugins
<luks> kfogel: according to your bzr info, there is no shared repository
<kfogel> luks: !!! ???
<kfogel> luks: dang it, I was so careful to set this up.
 * kfogel sobs
<kfogel> I pasted transcripts on the list, I...
<kfogel> Okay.
<kfogel> Let me get calm :-).
<luks> kfogel: run bzr info in the parent directory
<luks> and pastebin that
<kfogel> luks: sure, one sec
<kfogel> luks: http://paste.lisp.org/display/76835
 * LarstiQ blinks
<luks> that another completely standalone branch :)
<luks> wait a sec, let me write something down for you
<LarstiQ> kfogel: you also have a ~/src/bzr/bzr-repo ?
<kfogel> LarstiQ: hmmmm
<LarstiQ> kfogel: it almost looks like ~/src/bzr is the result of `bzr init` instead of `bzr init-repo`
<kfogel> luks: LarstiQ may have caught a truly dumb braino here, one sec
<kfogel> luks: ignore all the above please
<kfogel> luks: PEBK
<kfogel> luks: PEBKAC
<kfogel> sigh
<luks> http://rafb.net/p/YR964W31.html this is what you want
<kfogel> I know what happened now.  And it's simultaneously complicated and truly boring.  I'm going to fix the setup so this can't happen again.
<kfogel> luks: thanks for your time
<LarstiQ> kfogel: for later reference then, in the case of having a branch that doesn't use a shared repository above it, `bzr reconfigure --use-shared`
<kfogel> LarstiQ: thank you
<kfogel> luks, LarstiQ: I can move a shared repo directory around with no penalty, right?
<LarstiQ> kfogel: yes, but
<LarstiQ> kfogel: as long as you move all the contained branches with it
<LarstiQ> kfogel: (so normal unix mv semantics on the repo dir would do that)
<kfogel> LarstiQ: well, I'm just moving the entire repo dir from above, from its parent to its grandparent -- the branches inside will get moved along with it.
<LarstiQ> kfogel: that's fine then
<kfogel> LarstiQ: ah, okay, yeah, Unix mv
<kfogel> luks: if we ever meet, you'll see me looking slightly embarrassed
<luks> heh :)
<kfogel> luks: so now I've moved everything around and I'm doing 'bzr pull' in $MY_BZR_SHARED_REPO/bzr.dev-trunk/, and it ran for 10 min with no output.  I hit C-c and now am rerunning with -v...
<Kobaz> how would i move a file from one branch to another, preserving it's history
<kfogel> luks: somewhat shy to ask another question, after my last round, but: have you seen this error lately?
<kfogel> http://paste.lisp.org/display/76845
<LarstiQ> kfogel: I haven't
<LarstiQ> kfogel: it seems like you are using an older format though
 * LarstiQ tries to reproduce with that information
<kfogel> LarstiQ: (phone)
<kfogel> thx
<kfogel> LarstiQ: I'm re-initializing the shared repo with --1.9 and re-branching trunk
<LarstiQ> kfogel: line 37 of xml5.py looks very different here
<kfogel> LarstiQ: thx (on phone, will look in detail when off)
<LarstiQ> kfogel: I'm fine with carrying on conversations over multiple days, no hurry :)
<luks> kfogel: initializing a repository with a different format than the upstream branch is only going to cause slowness
<kfogel> luks: thx
<luks> kfogel: because it has to transcode every time it needs to access the remote branch
<kfogel> luks: ah
<kfogel> luks: (on phone)
<luks> I think bzr.dev is still in --pack-0.92, which is the default format
<luks> hm, I'm wrong, it's 1.9 now
<LarstiQ> yeah, the switch happened a little while ago
 * emmajane waves.
<marianom> hi everyone. I'm currently running bzr 1.3.1 in a CentOS server. Anyone know where I can find an up2date rpm?
<marianom> I'm checking http://bazaar-vcs.org/DistroDownloads, will try epel testing
<marianom> ummm... epel-testing has the same package that epel... too bad
<GPHemsley> Can I get Loggerhead help here, or no?
<mwhudson> GPHemsley: sure
<GPHemsley> mwhudson: How can I install it on a Mac?
<GPHemsley> I've used port to install py25-paste and py25-pastedeploy, but I'm stilling getting an error
<GPHemsley> ImportError: No module named paste
<mwhudson> you don't really need to install loggerhead to get it to work
<mwhudson> GPHemsley: um, are you running loggerhead with the same python you installed the dependencies for?
<mwhudson> GPHemsley: try "import paste" at a python prompt
<GPHemsley> oh, hmm
<GPHemsley> maybe not
<GPHemsley> I suppose that would do it
<GPHemsley> any idea how I can connect the two?
<mwhudson> GPHemsley: something like /opt/bin/python serve-branches
<GPHemsley> DNE
<marianom> sorry to bother again guys. but I have this commit (single file) and is taking, well, more than an hour.
<marianom> it's stuck at "Uploading data to master branch - Stage:Finishing pack 5/5"
<marianom> if I ^C it, I have to log in the server and break-lock to release it.
<marianom> what can be happening?
<emma> Hey guys. I'm doing some independent research, I just wanted to ask a history of FOSS question.
<emma> Why was bzr made when git already existed and (i've been told) git does everything bzr does.
<emma> some people have also claimed that git is faster, but I'm not claiming that, if that were true then it is even more mysterious though.
<LeoNerd> Why anything?
<LeoNerd> Specifically.. what makes you think it came second?
<LeoNerd> Furthremore.. why have just one?
<emma> I was just told by several generally knowledgable geeks that git was made first.
<emma> if that's not true well then that is important to know too.
<LeoNerd> Was it public enough? Usable enough?
<mwhudson> bzr's lineage is definitely older than git
<LeoNerd> bzr has a lot of history from bazaar, which is a fork of tla, which is an implementation of arch,...
<LeoNerd> That's years older than git
<emma> so git was by far not a new idea or something Linus came up with.
<LeoNerd> These sorts of ideas have been milling around for aaaages
<LeoNerd> bzr, git, hg, darcs, monotone... they're all reinventions of the same sort of idea
<LeoNerd> Before them was perforce, svn... cvs... rcs..
<LeoNerd> sccs... sourcesafe...
<emma> Some people say that modern development of bzr didn't happen until around 2006
<LeoNerd> Some people say all sorts of things.
<mwhudson> emma: revision 1 in the bzr tree has the date 2005-03-09
<mwhudson> emma: the first email about git was on 2005-04-07, i think
<mwhudson> so it's not really clear to talk about "which came first"
<lifeless> LeoNerd: bzr's commit history doesn't have anything from 'bazaar' or 'tla'; the heritage is purely conceptual
<lifeless> marianom: is there anything in ~/.bzr.log? What bzr version?
<thumper> mwhudson: surely that is for bzr not baz right?
<luks> thumper: that's bzr, and it's date since it was self-hosting, not since it existed
<thumper> ah, that makes sense
<luks> the commit message says "import from baz patch-364"
<emma> look what I found -- http://bazaar-vcs.org/BzrVsGit
<emma> is that bazaar the same thing as bzr ?
<thumper> emma: Bazaar is the long name, bzr is the command
<lifeless> luks: thats a migration of bzr's commits, while it was bootstrapping it was versioned in a baz tree
<emma> okay but it is the same app, i wasn't sure if bzr was a spin off of Bazaar.
<thumper> emma: Way back, Bazaar related to baz, and bazaar-ng was bzr (since you are asking about history)
<thumper> emma: baz was depricated and bzr took the reigns
<lifeless> emma: in terms of debian packages, 'bazaar' was 'baz'
<emma> wow it's very complicated.
<thumper> emma: there is a lot of history
<emma> in your opinion if someone did not know either git or bzr, and then someone learned one of them, would they be relatively further along to know the other much more easily?
<Peng_> Oh, the original baz history wasn't imported into bzr?
<Peng_> emma: Yes.
<Peng_> (That's a helpful answer, eh?)
<emma> it's a rare answer but a cool one :)
<luks> but just learning basics of one would not help you much with the other one
<luks> because they *look* different
<lifeless> Peng_: the history for 'baz' has been converted into a bzr tree, but its not part of the 'bzr' history :)
<emma> well i have some personal investment in ubuntu so I will probably go with bzr.
<lifeless> Peng_: we need better adjectvies for this discussion :P
<Peng_> emma: Good idea, but I'm ever so slightly biased. ;P
<luks> Peng_: I think he meant "bzr from baz", not baz itself
<luks> er, lifeless
<marianom> lifeless: thanks for answering. I'm getting: http://paste.ubuntu.com/129926/
<Peng_> I don't know. What are we talking about?
<Peng_> lifeless: That's a shame. Why wasn't it converted at the time? Doesn't everyone want to write a complicated converter instead of doing real work on their new project? :D
<lifeless> 214.312  Auto-packing repository <bzrlib.repofmt.pack_repo.RepositoryPackCollection object at 0xa53138c>, which has 14 pack files, containing 922 revisions. Packing 9 files into 1 affecting 22 revisions
<lifeless> marianom: ^ thats the key thing, its doing an autopack
<lifeless> marianom: what bzr version do you have?
<marianom> lifeless: the server is Bazaar (bzr) 1.3.1 and my os has Bazaar (bzr) 1.12.
<lifeless> Peng_: well its a completely different code base, there is no benefit to converting
<marianom> the thing is that it already packed in a previous commit
<marianom> one I did a few minutes earlier
<lifeless> marianom: so, two separate things; if you upgrade the server to bzr 1.10 (I think thats the needed version, might be 1.11), it will do the autopack on the server which is much faster if you're not on a LAN
<marianom> lifeless: ok. I was trying to find a rpm up2date in epel-testing to no avail (centos server here). it seems I will need to grab it from source
<marianom> I hope I can remove current bzr with yum without affecting the branches
<emma> Why does bzr use branch numbers. Someone I was talking to said that makes no sense in a distributed version control
<lifeless> marianom: secondly, each commit is a 'pack', an autopack occurs every 10 commitsand prevents the number of packs getting too big (but it doesn't pack everything, so its generally very fast)
<lifeless> emma: do you mean revnos ?
<emma> lifeless: yeah the person I was talking to told me this, "revision numbers are problematic because: you start  with A at 1, branch it to A', code new features so that A' is at r10,  and backport a fix to A so it becomes r11. now, which branch has the  newer version?
<emma> "
<lifeless> emma: well neither, because they aren't fully merged :)
<lifeless> emma: revno's don't tell you stuff about one branch relative to another, but thats not why we use them anyhow; we use them because they are usually nicer to work with and they are useful within a branch
<kiko__> emma, git is definitely newer than bzr.
<kiko__> emma, it was started by linus when the whole bk debacle happened
<kiko__> it's all over kernelnotes
<emma> lifeless:  what happens if you have two branches with the same revision
<emma>                   numbers in them, but different commits, and try to merge them?
<emma> oops im sorry
<kiko> emma, they are different branches -- they will merge just fine.
<emma> kiko: but what do you do with the revision numbers in that case?
<kiko> emma, the merge will be a new commit wherever you are merging into.
<lifeless> emma: the revnos are a ui layer, they don't affect the core system
<lifeless> emma: in a given branch you know that '10' came before '11', which is kinda useful :)
<thecookie> You push/pull between branches, and commit/update between.. working trees?
<thecookie> Not sure about the term.
<lifeless> thecookie: yup, spot on
<lifeless> thecookie: merge goes from a branch to a working tree
<thecookie> Great, starting to get a hang of it I think.
<kfogel> lifeless: so revision numbers are essentially sequence numbers along a branch?
<kfogel> (i.e., meaningless without the context of the branch to give them meaning?)
<lifeless> kfogel: yes.
<kfogel> lifeless: that's what I thought, but it never hurts to sanity check.  Thanks.
<lifeless> 1234 in trunk is a useful statement
<lifeless> 1234 isn't
<kfogel> hmmm
<kfogel> bzr nightly builds are via PPA only?
<lifeless> kfogel: I think so
<kfogel> lifeless: mrmrm.  Will ask on list; would be great (and probably just as easy) if they were also in source .tgz.
<Necoro> if I have a lightweight checkout - and I want to export it ... why does it (with 0.12) take quite some time? - if (especially if the co is up2date) it could more or less simply to a "cp" ?
<Necoro> with "quite some time" I mean: longer than creating a complete new checkout
<lifeless> Necoro: its copying from the server
<Necoro> why? - if it notices, that the co is unchanged and up2date, it could do a simple copy
<thecookie> What is the current recommended way of duplicating the svn external feature?
<lifeless> Necoro: well, the code as written just pulls from the repository; it makes it very small and clean; you are right that we we could add a check in the working tree when there is a working tree to copy content from it
<lifeless> Necoro: please do file a bug that we don't take advantage of the local data in this case
<lifeless> thecookie: config-manager, which is a bit clumsy but works, or I think bialix (Alexander Belchenko) is working on a GUI doing a very similar thing
<Necoro> lifeless: ok - not now but later on
<thecookie> Alright, I'll check those out
<LarstiQ> thecookie: bialix's project is http://launchpad.net/bzr-scmproj
<thecookie> Thanks :)
<thecookie> You juse check out those plugin rather than using the donwload button from there?
<thecookie> plugins*
<mwhudson> kfogel: i guess you can just wget the orig.tgz from ppa.launchpad.net :)
<LarstiQ> thecookie: yeah, cd ~/.bazaar/plugins ; bzr branch lp:bzr-scmproj scmproj; bzr plugins | grep scmproj
<thecookie> Sweety
<thecookie> Heh. -y ;P
<mwhudson> kfogel: eg http://ppa.launchpad.net/bzr-nightly-ppa/ppa/ubuntu/pool/main/b/bzr/bzr_1.13~bzr8.10-4098-1.tar.gz
<LarstiQ> mwhudson: which date is that for?
<mwhudson> well, only the latest will be present i guess
<LarstiQ> ah
<LarstiQ> kfogel: did the fresh branching get rid of the xml5 serializer error?
<thecookie> Seems I need a newer version of bzr to do that. Is there a .deb repo somehwere?
<thecookie> Or maybe I just need a format plugin or something?
<thecookie> bzr: ERROR: Unknown repository format: 'Bazaar RepositoryFormatKnitPack6 (bzr 1.9)\n'
<lifeless> http://bazaar-vcs.org/Download
<lifeless> (yes there is a deb repo)
<LarstiQ> thecookie: you'd need bzr 1.9 or newer for that format
<thecookie> using the default one in ubuntu now, 1.6.1
<thecookie> I guess I'll get it updated
<LarstiQ> thecookie: https://edge.launchpad.net/~bzr/+archive/ppa for ubuntu
<mwhudson> so who do i have to hound to get my branch_implementations patch into 1.13 and my no-LockableFiles.__del__ into bzr.dev and 1.13?
<lifeless> mwhudson: I'll land it in .dev for you; bob tanner is the 1.13 rm
<lifeless> aka BasicOSX
<mwhudson> lifeless: thanks, and ok\
<mwhudson> BasicOSX: hi :)
<LeoNerd> I don't suppose there's such a thing as bzr ununcommit  is there? ;)
<LeoNerd> I accidentally uncommitted a commit
<Peng_> LeoNerd: "uncommit" gave you the command to run to restore the revision.
<LeoNerd> It does?
<Peng_> LeoNerd: In recent versions, at least.
<LeoNerd> Oh.. well.. no. I had local modifications before I started
<LeoNerd> So now if I were to  ci   I'd commit a combination of the uncommitted and new changes
<lifeless> https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/317781
<ubottu> Error: Could not parse data returned by Ubuntu: The read operation timed out (https://launchpad.net/bugs/317781/+text)
<lifeless> LeoNerd: so, bzr pull . -r revid:<uncommittedid> will put it back
<Peng_> LeoNerd: If you've lost the "uncommit" command, but it wasn't that long ago, you can grep ~/.bzr.log for "bzr pull . -r".
<LeoNerd> Ah. But how do I know the revid?
<lifeless> LeoNerd: if you don'tknow the revid, 'bzr heads --somethingoother' will tell you
<LeoNerd> Ahyes
<LeoNerd> I recall doing this last time
<Peng_> Otherwise, yeah, "bzr heads". "--dead-only", I think.
<LeoNerd> $ bzr heads --dead-only
<LeoNerd> That got it
<Peng_> :)
<LeoNerd> Woo. Marvellous. Thanks guys.
<lifeless> our pleasure
<zanaga> is there a prebuilt plugin that allows me to bind a simple command to a local repository as a postcommit script?
<lifeless> zanaga: I believe jelmer wrote a shell-hooks plugin, to allow running shell scripts on such events
<zanaga> ah.. so it seems..
<zanaga> thanks, that saves me a lot of typing
 * mwhudson waves towards brisbane
<lifeless> hi mwhudson
<lifeless> so, loggerhead on chk; please test :)
<mwhudson> um
<mwhudson> i've actually forgotten how many things i'm doing _right now_ :)
<mwhudson> but ok
<lifeless> the sprint is only this week; its why I'm emphasising this
<mwhudson> yes ok
<lifeless> I have your no-LockableFiles.__del__ cycles queued
<mwhudson> thanks
<lifeless> mwhudson: I'm confused though, your branch has _LockCounter, but you say your bundle changes it; did you not push ?
<mwhudson> um, no i probably didn't push
<lifeless> no worries, I'll pull from bb
<mwhudson> i have now, but whatever's easiest
<mwhudson> lifeless: um, your bzr.dev.chk branch has a .bzr in it's .bzr
<mwhudson> lifeless: you may wish to stab rsync?
<lifeless> mwhudson: one of them will work :P
<mwhudson> lifeless: nope
<mwhudson> lifeless: https://pastebin.canonical.com/14842/
<mwhudson> oh hm
<mwhudson> and the other .bzr fails differently!
<mwhudson> lifeless: http://pastebin.ubuntu.com/129985/
<aedan> Hi There.
<lifeless> mwhudson: I'll rsync it up again
<aedan> I have two branches, one of my core PHP framework, the other is a branch of that framework will application specific files added.
<aedan> Is it possible to sync a change to the framework made in the app branch back to the framework branch?
<schmichael> is there a way to get syntax highlighting of `bzr diff` output (like hg) other than to run it through pygments: `bzr diff | pygmentize -l diff`
<schmichael> if not i may try to work up a patch
<bob2> is it possible to set BZR_REMOTE_PATH per-server?
<bob2> setting it globally makes any authenticated lp access splode
<bob2> aedan: not easily
<bob2> schmichael: adding that to bzrtool's cdiff would be awesome
<aedan> bob2: Hrmph.  Thanks for the reply though. :)
<bob2> schmichael: unless what that does is the same as what cdiff already does
<schmichael> bob2: ah, looks like it.  thanks
<aedan> bob2: So in that instance, I'd be best off moving the file over manually?
<bob2> aedan: no
<aedan> bob2: oh?  What'd the best solution be?
<lifeless> bob2: yes, ~/.locations.conf
<lifeless> bob2: see the list today :)
<bob2> aedan: I don't know
<bob2> lifeless: oh, cheers
<lifeless> so, I need to go from "foo.bar.baz" to foo.bar.baz, are there stoill no easy eays to do this?
<bob2> in python code?
<aedan> bob2: Is there perhaps an entirely different layout that'd make it easier?  Basically it's just that I have a framework and an app using the framework.
<spiv> lifeless: twisted.python.reflect.namedAny("foo.bar.baz")  :P
#bzr 2009-03-12
<bob2> aedan: only make framework changes on the framework branch.  or at least put the changes you want to send the other way in self contained commtis.
<bob2> I dunno how smart bzr is about cherrypicking these days
<aedan> bob2: Ooh, so you're saying, if possible, commit only the changed framework files, then I can pull from that revision?
<lifeless> spiv: ugh
<lifeless> mwhudson: its rsyunc
<marianom> lifeless: thanks for the suggestions you provided me earlier today. already migrated and all issues fixed.
<lifeless> marianom: excellent
<bob2> heh, bzr.dev is too old to work with bzrtools.dev
<mwhudson> spiv, lifeless: did my no-LockableFiles.__del__ patch fail tests?
<lifeless> mwhudson: no it was pending a prior patch, one sec
<mwhudson> k
<mwhudson> lifeless: i still get
<mwhudson> error: Error -5 while decompressing data
<mwhudson> on the bzr.dev.chk
<mwhudson> i have a 64 bit install, could that be related?
<jelmer> lifeless, did you see my reply about default-rich-root ?
<lifeless> mwhudson: from what? (I have a 64-bit install too)
<lifeless> jelmer: no
<jelmer> lifeless, http://article.gmane.org/gmane.comp.version-control.bazaar-ng.general/53957
<mwhudson> lifeless: bzr log --short -l 10
<mwhudson> lifeless: brisbane-core @ 3875
<mwhudson> bzr-groupcompress @ 47
<lifeless> rollback to 43
<mwhudson> lifeless: ah, now we're go
<lifeless> jelmer: you want a new format, default-rich-root, which should be an alias for another format right?
<jelmer> lifeless, Yes, but what format it is an alias for will change in the future
<jelmer> just like --default does
<lifeless> jelmer: right, which is what aliases are all about
<jelmer> lifeless, right
<lifeless> jelmer: so just register an alias
<jelmer> lifeless, that's what I'm doing afaik
<lifeless> no, you're adding a new method
<jelmer> well, a new method to maintain the alias
<lifeless> you just need to register a new format that is an alias
<jelmer> lifeless, so you basically want me to move the contents of set_default_rich_root() to the top-level of bzrlib/bzrdir.py ?
<jelmer> lifeless, imho it's cleaner having that stuff in a separate method
<lifeless> uhh
<mwhudson> lifeless, jam, etc: bzrlib/_chk_map_pyx.pyx seems to have an error in brisbane-core
<mwhudson> /home/mwh/canonical/repos/bzr/brisbane-core/bzrlib/_chk_map_pyx.pyx:232:25: Expected an identifier or literal
<lifeless> jelmer: no; I'm suggesting you do what the other alias formats do
<lifeless> jelmer: which would be consistent :)
<mwhudson> oh
<mwhudson> my pyrex does'
<jelmer> lifeless, which means duplicating the branch format / repo format in a couple of places
<mwhudson> n't support ++
<mwhudson> +=
<jelmer> lifeless: anyway, if it's consistent I'll fix my patch but the way the aliases work seems suboptimal to me
<lifeless> jelmer: one place only. You could also put in a patch to make alias formats easier to manage; I object to the patch you have put in because it widens the registry interface specially rather than generally
<lifeless> when the thing that is needed is already in  general use.
 * mwhudson is thinking that delta computation must be a little tiny bit faster in chk repos: http://pastebin.ubuntu.com/130001/
<mwhudson> strangely though log --short -l 10 still takes 3 seconds
<mwhudson> and heck
<mwhudson> *-l 1* takes 3s
<lifeless> spiv: (Pdb) ll = bzrlib.registry._LazyObjectGetter('bzrlib.branch', 'Branch.hooks')
<lifeless> (Pdb) ll.get_obj()
<lifeless> *** AttributeError: 'module' object has no attribute 'Branch.hooks'
<mwhudson> something is killing "start up" time on chk branches
<lifeless> spiv: I am not liking this :(
<lifeless> spiv: I would like a hand, otherwise I will feel that the code I have that works is better
<jam> mwhudson, lifeless: the startup time could easily be the time to unpack the one large group for all of the revision texts.
<jam> we have a couple ideas of how to make that better
<jam> and I'll go ahead and work out a fix for broken old pyrex versions :)
<lifeless> jam: we might want to do something about that
<glyph> 'bzr visualize' is a completely awesome thing
<glyph> thank you all
<lifeless> mwhudson: --lsprof on log --short -l 10 might be useful
<glyph> for making it possible
<lifeless> glyph: you're welcome
<glyph> suggestion though: "bzr glog" might be a good alias for it
<mwhudson> jam: http://pastebin.ubuntu.com/130009/
<glyph> is 'dvc' the generally preferred emacs integration mechanism for bzr?
<mwhudson> lifeless: http://pastebin.ubuntu.com/130010/
 * mwhudson not feeling so good, biab
<lifeless> glyph: glog would be an awesome alias
<jam> mwhudson: what is the 'iter_inventory_xml_keys' change?
<lifeless> glyph: vila: will know
<jam> otherwise, I understand the += => = a + change
<mwhudson> jam: something lifeless gave me yesterday, i didn't mean to give that to you :)
<jam> and it is committed to brisbane-core 3876
<mwhudson> jam: the .pyx fix is all i needed to make it compile
<mwhudson> cool :)
<jam> mwhudson: try setting _NO_LABELS = True
<jam> in groupcompress.py
<jam> and see how that changes "bzr log --short" time
<jam> mwhudson: ah, that won't actually make a difference, as it parses the labels if they are there
<jam> I can give you a one-line change to the parser, though, just a sec
<jam> mwhudson: you can cherrypick revno 48, or use: http://pastebin.ubuntu.com/130013/
<jam> (sorry it isn't 1 line, but it was cleaner this way)
<jam> mwhudson: that patch has some typos, this one is better: http://pastebin.ubuntu.com/130019/
<jam> it drops off about 300ms for me on 'bzr log --short -r -10..-1'
<jfroy> vila: quick fyi: new patch is up
<mwhudson> jam: it gets me back to "error: Error -5 while decompressing data"
<mwhudson> jam: oh no, pebkac; it just doesn't apply cleanly to r43 of groupcompress
<mwhudson> so my branch of loggerhead is less of a dos attack on servers, i hope
<mwhudson> it still does a pretty good job on firefox if you ask for it...
<lifeless> mwhudson: cool
<mwhudson> oh and the code is horrible beyond all belief
<lifeless> :*(
<lifeless> why
<mwhudson> because i've been hacking
<mwhudson> now i know it works and feels ok, it's time to do it right
<lifeless> wat have you done
<mwhudson> some ajaxy loading
<mwhudson> play, if you like: bzr+ssh://bazaar.launchpad.net/~mwhudson/loggerhead/finite-revision-pages
<lifeless> what does it do though
<lifeless> mwhudson: like, is it just skipping html rendering on the server?
<mwhudson> lifeless: it's more about not including stuff in the initial page sent to the browser
<mwhudson> lifeless: so for example, in the changelog view, not sending the list of changed files until the disclosure triangle is clicked
<lifeless> mwhudson: cool
<gotgenes> I'm having difficulty figuring out when one branch originated from another. I thought bzr viz would show it but I don't see anything obvious. Is there some other way?
<SamB> glyph: I have no idea if it's preferred, but if you find any bugs please report them on launchpad ;-)
<SamB> re: dvc
<poolie> jml, http://imgs.xkcd.com/comics/not_enough_work.png
<spiv> mwhudson: your patch landed
<jml> poolie: yeah, I've seen it.
<jml> glyph: welcome to #bzr :)
 * SamB wonders why *bzr-status* is in dvc-diff-mode
<poolie> lifeless: thanks for the hooks registry :)
<SamB> is there a way to get structured information out of bzr status ?
<poolie> SamB from another process? you can try the bzr-xmloutput plugin
<SamB> but then I'd have to parse the XML ... no json?
<SamB> (just because it's a heck of a lot simpler to parse than XML, not that I'm writing AJAX or anything)
<james_w> not currently I believe
<james_w> extending bzr-xmloutput could be extended to provide json I guess
<abentley> LarstiQ: Hi there, I've started work on nested trees, starting with merging bzr.dev into your latest.
<poolie> spiv, not to interrupt you too much, but did you already fix something like bug 341535?
<ubottu> Launchpad bug 341535 in bzr "hpss SmartMedium doesn't handle eintr" [Undecided,New] https://launchpad.net/bugs/341535
<spiv> poolie: I did, for the TCP client medium
<spiv> poolie: there's a osutils.until_no_eintr helper
<poolie> thanks
<poolie> i don't think i care quite enough to do it right now
<poolie> maybe when fetch progress is a bit more cooked
<SamB> is there a way to cancel a bzr rm ?
<jml> SamB: if you mean undo, then 'bzr revert filename' works
<SamB> jml: well ... I have files still
<jml> SamB: I don't follow.
<SamB> they had gotten moved away from where they should have been, is all
<SamB> and then I foolishly ran "bzr rm" with no arguments
<spiv> SamB: so you have a change in your working copy you want to revert, the change being that some files were unversioned; "bzr revert filenameA filenameB ..." as jml says is the way to undo that.
<bob2> hm, should upgrading a bzr.dev mirror to --development take like hours and spin at "checking repository format 1/1" for 2 or so?
<lifeless> bob2: possibly :P you'reusing bzr.dev?
<bob2> lifeless: yeah
<poolie> rfc: there should also be a 'connecting' activity indicator to show that's what we're waiting for
<poolie> activity as opposed to a progress thing
<SamB> i.e. a spinner
<spiv> poolie: it would be nice, although a little bit hard to implement accurately perhaps?  I'm thinking of when bzr+ssh delegates the connecting to an openssh subprocess...
<poolie> spiv, i'm basically saying it should do
<SamB> spiv: what would it mean for it to be accurate in that situation?
<poolie> > report_activity(self, 'connecting')
<poolie> before running openssh
<poolie> so it won't spin but at least it'll show that rather than just '0kB'
<SamB> oh
<SamB> you just want a message
<SamB> "hey this is what's I'm about to do, just hold on, I'll be right back!"
<spiv> poolie: ah, right.  +1
<poolie> SamB, exactly
<spiv> SamB: Well, there's arguably a significant difference between "waiting for SSH to connect" and "waiting for remote bzr to reply to my first request"
<spiv> I'm not sure it really matter too much in practice.  At least at the moment our first requests don't require much processing time on the server.
<SamB> spiv: well, it would at least tell you that bzr wasn't ransacking your local storage ...
<SamB> though I guess if you're actually sitting at your computer you'd know anyway ...
<poolie> spiv, doing something for the hello would be good too
<spiv> poolie: when probing for bzr+http?
<poolie> or on the first request to the smart server
<poolie> just an idea
<poolie> it might take a while to get going
<poolie> spiv, remote.py has
<poolie> 1509         if not resume_tokens:
<poolie> 1510             # XXX: Ugly but important for correctness, *will* be fixed during
<poolie> 1511             # 1.13 cycle. Pushing a stream that is interrupted results in a
<poolie> 1512             # fallback to the _real_repositories sink *with a partial stream*.
<poolie> 1513             # Thats bad because we insert less data than bzr expected. To avoid
<poolie> 1514             # this we do a trial push to make sure the verb is accessible, and
<poolie> 1515             # do not fallback when actually pushing the stream. A cleanup patch
<poolie> 1516             # is going to look at rewinding/restarting the stream/partial
<poolie> 1517             # buffering etc.
<poolie> is that true?
<stefanlsd> Can i push a branch i was working on to another server? I did a push and i just get the .bzr directory on the other side (no files)
<beuno> stefanlsd, right, remote pushes don't create working trees
<beuno> so you have the branch, but not the actual files
<beuno> if you want the files, you need to run:  bzr co .
<beuno> but subsequent pushes won't update them
<beuno> you need the push-and-update plugin for that
<beuno> unless you *only* care about the actual files remotely, then you can use bzr-upload
<stefanlsd> beuno: mm. im trying to setup that another guy in my office can work on some of the projects with me. So i made a place on a remote server. I wanted to take my local bzr stuff and get it there.  Would it be better to just scp it to the central server now?
<beuno> stefanlsd, no, he can just branch from that
<stefanlsd> beuno: its not there yet. I have it all locally. i wanted to get it there first by pushing.. should I rather go central and branch it from me?
<beuno> stefanlsd, it *is* there
<beuno> if you pushed it, and there's a .bzr directory
<beuno> that's the branch
<beuno> you don't need the working tree (actual files)
<stefanlsd> beuno: oh. interesting. wasnt aware of that
<stefanlsd> beuno: thanks. so my understanding now is, if i want the working tree there also i need the push and update plugin. will look into that. thx!
<beuno> stefanlsd, you're welcome
<cristi_an> what is the diff between bzr push and bzr up
<cristi_an> ?
<beuno> cristi_an, one is used for checkouts, and one is used for branches
<beuno> (there's more to it, but let's start with that)
<cristi_an> beuno: thx...i did not find this in the 5 min tut :)
<cristi_an> which one i sfor checkouts
<beuno> cristi_an, how did that question pop into your head?
<cristi_an> well...i explain
<cristi_an> i get a project called openerp from launchpad
<hmeland> The help for up probably ought to mention the term "checkout" somewhere.
<cristi_an> but after a few day since i was i cvs user before
<cristi_an> i did bzr up
<cristi_an> but it did not bring any of the changes done by others
<beuno> cristi_an, did you branch it, or did you make a checkout?
<cristi_an> beuno: i run a script that get all those projects for me...
<cristi_an> http://paste.pocoo.org/show/107535/
<beuno> cristi_an, ok, so you branch them
<beuno> 'bzr update' won't come into play at all for now
<cristi_an> in terms of using cvs
<cristi_an> i checkout them...
<cristi_an> :)
<beuno> well, you can do a checkout with bzr as well
<beuno> and then it's basically the same
<beuno> when you commit, it will commit directly to the online branch
<beuno> "update" brings in new changes, etc
<beuno> a checkout is bound to it's parent
<cristi_an> but can you tell me what that script does
<beuno> branches, on the other hand, are independant
<cristi_an> i seee
<beuno> yes, it creates branches
<cristi_an> so i have c copy locally
<cristi_an> and i work local
<cristi_an> then i can merge with some server branch
<cristi_an> ?
<cristi_an> somthing like commit will commit on my local branch
<cristi_an> not on server ?
<hmeland> cristi_an: Your script takes a --checkout option.  Supply that option with your launchpad username to make the script do "bzr checkout" and "bzr update" instead of "bzr branch" and "bzr pull".
<cristi_an> i have to read about this more....
<cristi_an> :)
<cristi_an> but i got the picture....
<cristi_an> thx
<nick_> Can anyone help me with setting up a bug tracker within Bazaar? The documentation I've found tells me about it, but not how to do it
<hmeland> nick_: What kind of bug tracker are you talking about?
<nick_> hmeland: a custom made one - I basically want to know what things I need to put in the bazaar.conf file in order to get it working with --fixes
<hmeland> You've seen http://doc.bazaar-vcs.org/latest/en/user-reference/bzr_man.html#bug-tracker-settings already?
<nick_> hmeland: yes, but it seems to be lacking explanation
<nick_> hmeland:  for example, I don't know what parameters Bazaar passes my bug tracker when I mark a commit as --fixed
<nick_> I'm assuming it HTTP POSTs by default?
<beuno> nick_, no, it's metadata on the branch
<beuno> no http communication at all
<nick_> beuno: ahhh, so how does the tracker get this information, through a post commit hook?
<beuno> nick_, well, it's up to the tracker
<beuno> tip-change
<beuno> cronjob
<beuno> whatever
<nick_> beuno:  I see
<nick_> beuno:  are you familiar with the shell_hooks plugin at all?
<beuno> nick_, not really, no
<nick_> beuno: ah, just I can't get it to work :)
<nick_> beuno: I'm not well versed with Python
<nick_> does anyone know of a post commit hook that can HTTP POST to a URL?
 * SamB wishes bzr-gtk didn't have that unintended seahorse dependancy :-(
<kfogel> When I bring in changes from someone else's branch via 'bzr merge', I have to write a new log message when I then do 'bzr commit', even though the other person already wrote a log message.  I can even see the original log message when I do 'bzr status' ("pending merge tips: ...", or with -v, "pending merges: ...").  Is there some way to commit the merged change(s) locally such that they automatically get the same author and commit message as
<kfogel> the originals?
<beuno> kfogel, not atomatically, no
<kfogel> beuno: hmrm.  Okay, thanks.  So it sounds like there isn't really a way to say (in a non-mirror branch) "Just bring in these changes, I don't want to have to specify anything more about them, I just want them incorporated into my local branch."
<kfogel> ?
<beuno> kfogel, right, the merge is always explicit
<kfogel> *nod*
<kfogel> beuno: thx
<beuno> :)
<kfogel> beuno: is there at least some way (immediately after 'bzr merge') to get the full information about all merged-but-not-committed changes?  Specifically, I want to list their source branch and revision number, in my commit message.
<kfogel> beuno: or is that pointless, because bzr will already record those when I commit?
<beuno> other than bzr status?
<kfogel> (in which case, great, but I'd still want to *see* the pending revs before committing)
<kfogel> beuno: bzr status -v shows committer, date, and msg, but not source branch or rev num
<beuno> right, so there's not way that I know of to see those
<beuno> that may be useful
<beuno> so it sounds like you're cooking a bug there
<kfogel> :-)
<kfogel> Yeah, it would be nice to be able to see the exact identity of what I'm about to commit.  For an especially paranoid developer, that might be part of a sanity check.
<SamB> high in protein!
<kfogel> SamB: breakfast of champions!
<SamB> but at least you know their descriptions -- darcs isn't even capable of telling me what revisions have conflicted
 * kfogel looks at bzrlib/status.py:show_pending_merges()
<SamB> (apparantly it's not even easy in theory!)
 * awilkins is totally awesomed out by how awesome uploading things to a PPA is
<awilkins> Why the hell does it build fricking Atom builds of things though.....
<kfogel> beuno: crimminy, don't even have the information available in bzrlib/revision.py:Revision, as far as I can tell.
<SamB> Atom ?
<SamB> you mean it converts them to RSS feeds?
<SamB> (Yeah, I know Atom isn't actually named RSS -- but then basically no two versions of RSS expand to the same name either)
 * SamB wonders how glyph found out about dvc
<rocky> jelmer: bzr svn-import is currently failing for me (after a few mins of running) on htps://dev.serverzen.com/svn/cluemapper
<rocky> jelmer: that's with bzr 1.13rc1 and bzr-svn 0.5.3
<kfogel> policy question: when bzr can receive a setting from either an environment variable or the bazaar.conf file, which overrides which?  Does the env var dominate the config setting if both exist, or the other way around?
<kfogel> (this is for implementing a new thing -- if it were an existing feature, I'd just test)
<SamB> kfogel: well, usually the env var, I hope
<kfogel> SamB: that's what I picked
<SamB> might depend on the setting a bit, but for instance if I have an emacs package that wants to turn off the progress bar ...
<SamB> ... then I'm going to be annoyed by https://bugs.launchpad.net/bzr/+bug/339385
<ubottu> Ubuntu bug 339385 in bzr "bzr: BZR_PROGRESS_BAR is ignored" [Medium,Confirmed]
 * SamB wishes ubottu would get it right and say "Launchpad bug"
<kfogel> SamB: well, that's just because of the bug, right?  It doesn't change the correct ordering.
<SamB> yeah
<SamB> I was just being silly with that last message
<SamB> going to a conclusion unrelated to the premise
<SamB> (the premise that the env var should override the conf file, that is)
<SamB> (I don't think there is a conf setting for this?)
<SamB> I certainly don't see a progress bar setting in my bazaar.conf
 * SamB wonders if there's some sort of script to manually convert an svn:ignore property to .bzrignore
<SamB> jelmer: is there a way to query SVN revision properties from bzr-svn ?
<SamB> no, wait, this would be a file property
<SamB> well, both things would be good anyway
<SamB> and the way should be mentioned in "bzr help svn", of course
 * SamB wonders if there's a way to get launchpad to build and serve docs
 * SamB re-opens https://bugs.launchpad.net/bzr-svn/+bug/174947
<ubottu> Ubuntu bug 174947 in bzr-svn "Commands for changing/viewing file properties" [Wishlist,In progress]
<SamB> does anyone know how to get word-wrap in emacs (without altering the buffer data)?
<SamB> i.e. yes, I know how to use M-q, that's not what I want ;-P
<SamB> oh, emacswiki says LongLines
<jelmer> SamB, I think we did have them at some point but they got removed, since they were just aliases for "svn propset / svn propget"
<SamB> jelmer: how's that going to work in a bzr-native format checkout/branch/etc?
<jelmer> SamB: there's no way that can work in a bzr native format
<SamB> oh
<jelmer> SamB, but with a bzr-specific command it can't work in a bzr native format either
<jelmer> since the bzr native format can't store custom file properties
<SamB> wait, I din't need an answer to how is "svn foo" going to work in a bzr-native directory ;-P
<SamB> that was rhetorical
<Leon_Nardella> leon@bespin:~/Documents$ bzr update scrip/
<Leon_Nardella> Permission denied (publickey).
<Leon_Nardella> bzr: ERROR: Connection closed: please check connectivity and permissions (and try -Dhpss if further diagnosis is required) <-- What does this usually mean? I know it's something to do with my messing around backing up the branch to Dropbox and changing keys, but I'm not sure what I can do to make it work now. This branch is hosted on Launchpad and I can check it out without problems.
<SamB> I thought you were giving the second (bzr format can't handle that) answer already ;-)
<jelmer> SamB, I also mean "bzr svn-propset" can't work in a bzr-native directory
 * Leon_Nardella sorry for the multiple lines
<jelmer> SamB, since there's no place it can store the properties
<SamB> jelmer: oh
<jelmer> SamB, the way you've changed the bug report right now indicates I'm working on it.. that's not the case :-)
<SamB> jelmer: well, you can change it to something more appropriate
<SamB> I thought maybe you'd somehow hidden it where I couldn't see it :-)
<SamB> given it a funny name or something
<jelmer> SamB, are you still interested in it if it's just going to be an alias for "svn propset" / "svn propget" ?
<SamB> not if it requires a .svn dir, no. but some documentation about the uselessness of such a thing would be good.
<jelmer> SamB, I'll comment in the bug report
<SamB> and I would be interested in extensions to bzr to allow it to be useful, as well
<SamB> jelmer: how about adding it to the FAQ?
<jelmer> SamB, that's the sort of documentation you meant, right?
<SamB> in addition, I mean
<SamB> like: "Q: How can I look at my file properties?" "A: If you're in an svn checkout, the usual way. If in a bzr native tree, there aren't any to see."
<jelmer> SamB, Care to send a patch ? :-)
<sohail> how can I take the difference of two branches?
<sohail> one has a bug, one doesn't :-)
<sohail> ah --old
<sohail> hmm... well that is lying
<jelmer> SamB, just curious, what sort of properties would you want to set ?
<Odd_Bloke> sohail: How so?
<sohail> Odd_Bloke, bzr switch buggy-branch; bzr diff --old non-buggy-branch -> no diff which is not true
<sohail> oh do I have to give the full path to the old branch?
<sohail> that's annoying but ok
<Odd_Bloke> sohail: Yeah, that'll be it.
<Odd_Bloke> sohail: Though there should probably be an error message if there isn't a branch at non-buggy-branch...
<sohail> Odd_Bloke, I'd agree with that
<sohail> ok I need to binary search where this bug was introduced... how do I do that with bzr? is there an equivalent to svn up -r $FOO ?
<sohail> sorry if my question is ignorant :-)
<Kinnison> you can either make new checkouts at given revisions, or bzr revert might help you since you can pass that -r $FOO
<Kinnison> but I'm not a power-user, so I could be wrong
<sohail> I just found the bzr bisect plugin
<sohail> lets hope it doesn't screw up my repo :-)
<glyph> how does one unbind a bound branch
<jelmer> glyph, bzr unbind :-)
<glyph> jelmer: I figured that out a split second before you said it, and felt appropriately foolish :)
<jelmer> glyph, :-)
<sohail> haha... bzr bisect: 1115 no, 1118 yes, 1116 yes, 1116, 1116, 1116, 1116, explode
<sohail> lol!
<sohail> screw this, I'm going ot exercise
<Kinnison> heh
<ripps> Does anybody here know how to mirror a git repository into a launchpad branch?
<SamB> ripps: jelmer might?
<SamB> then again maybe you can't
<SamB> I think it will involve a cron job on a system you have a shell on, though
<jelmer> ripps, small repositories should be convertable with git-import from bzr-git, alternatively you can use git fast-export/ bzr fast-import
<jelmer> ripps, there's nothing in launchpad to have it mirror for you automatically (yet)
<ripps> jelmer: so, back to manually uploading it
<SamB> or if you control the git server you could use some kind of post-hook
<SamB> ripps: cron!
<SamB> hmm, how come you can't just give launchpad svn:// URLs to mirror the bzr way, anyway?
<SamB> why does it have a special vc-import thing for that?
<jelmer> SamB, hysterical raisins
<jelmer> SamB, vcs-imports predate bzr-svn
<SamB> I suppose it's good for the users anyway
<SamB> jelmer: oh. how does it work then?
<jelmer> SamB, there has been talk about using bzr-svn on lp
<jelmer> SamB, but the problem is it will cause disruption for users of the existing mirrors
<SamB> I mean, it would be kind of confusing to expect users to just enter an SVN url as if it was a BZR url
<jelmer> SamB, it use cscvs
<jelmer> SamB, what would be confusing about that?
<SamB> jelmer: well, for new users anyway
<jelmer> SamB, there are mirrors of "regular" bzr branches too
<jelmer> SamB, In general the format of a branch shouldn't matter, whether it's Subversion or native Bazaar
<SamB> anyway ... the obvious way to go to bzr-svn would be to allow people to start entering those SVN urls in the field, then tell them about it after a while ...
<SamB> and just keep doing vcs-import the same way as before
<jelmer> SamB, yeah
<jelmer> SamB, unfortunately there's no shared history between stuff imported with vcs-imports and bzr-svn
<jelmer> SamB, so users can't really migrate from vcs-imports to bzr-svn
<SamB> yeah
<SamB> but giving new users the option is good
<SamB> does bzr-rebase share git-rebase's "no revision 0" flaw?
<jelmer> SamB: well, it means that if somebody you work together with happens to do a commit based on a bzr-svn branch and your branch is a vcs-improts branch it breaks
<SamB> jelmer: oh
<SamB> it breaks?
<jelmer> SamB, "breaks" in the sense that it doesn't have any shared history
<SamB> it doesn't just ... not show up nicely?
<SamB> vcs-imports doesn't grok SVK attributes?
<SamB> anyway, that doesn't sound much worse than using SVN in the first place ...
<jelmer> SamB, and will attempt to merge from rev 0 as it doesn't see common revisions
<SamB> jelmer: huh?
<jelmer> SamB, I'm not sure I understand what SVK has to do with it
<SamB> what do you mean?
<jelmer> SamB, it will attempt to merge *all* revisions from the bzr-svn branch as none are present in the vcs-imports branch
<SamB> oh
<jelmer> SamB, bzr-rebase doesn't have any "no revision 0" flaws
<SamB> you mean if you try to pull a commit across via bzr!
<SamB> apparantly git-rebase can't really rebase between branches with different roots :-(
<SamB> I read somewhere a proposal for a special 00000... commit
<jelmer> SamB, bzr already has such a thing
<SamB> I thought probably
<SamB> sounds better than git-svn, anyway ;-)
<jelmer> SamB, so the main reason bzr-svn isn't supported at the moment yet is because it would cause confusion for existing vcs-imports users and problems merging
<SamB> git-svn users are encouraged not to share git commits!
<jelmer> SamB, whoa, wasn't aware of that
<SamB> since it doesn't roundtrip too well
<Odd_Bloke> Yeah, bzr-svn is just a ridiculous amount better than git-svn.
<SamB> so having two incompatible tools doesn't sound nearly as bad
<Odd_Bloke> In terms of actual functionality.
<SamB> yeah
<SamB> now if only it didn't spend so much time apparantly doing nothing ...
<jelmer> SamB, are you running 0.5.3 yet?
<Odd_Bloke> Maybe not so much in terms of speed, but <insert tired argument about features &gt; speed here>
<SamB> svn 0.5.4dev
<jelmer> SamB, and what in particular is slow?
<SamB> hmm.
<SamB> it's stopped doing it.
<SamB> typical!
<SamB> hmm, maybe that's because that branch was bound to the SVN repository ...
<SamB> bzr-svn just seems to spend an inordinate amount of time looking at svn revisions it's already seen
<SamB> even when there are no revisions to pull
<SamB> but apparantly not when your working directory is a heavyweight bzr-native SVN checkout
<SamB> is there a way to dump the progress output?
<jelmer> SamB, Not really
<jelmer> SamB, you can run with -Dtransport and see what sort of protocol requests it's doing
<jelmer> SamB, what progress bar phase is it spending the most time in during pull ?
<SamB> it skips back and forth
<SamB> there ought to be a way to dump either a trace or at least a sampling of the progress bar phases ...
<jelmer> SamB, skips back and forward between what?
<jelmer> SamB, what texts in the progress bar I mean
<SamB> I know, that's what I'm saying should be traceable
<SamB> discovering revisions and determining changes
<SamB> Pull phase
<SamB> and the SVN revnums are all over the place as it does that
<SamB> hmm, gotta go to school now
<jelmer> SamB, might be looking at tags
<jelmer> SamB, That should hopefully be fixed in the next version
<SamB> why does bzr not being able to delete a non-empty directory count as a conflict?
<jelmer> SamB, because upstream has removed a directory and locally that directory can't be removed
<SamB> I know what it means
<SamB> but why's that a conflict?
<SamB> it should be something more like a sticky warning or ...
<SamB> I mean it's just object files, probably ...
<jelmer> SamB: Well, I was stating it like that to hopefully clarify that the operation that happened remotely can't happen locally
<SamB> I know but conflict seems a bit harsh a status for it
<jelmer> and that's basically what a conflict is about
<SamB> in that case
<SamB> the directory can just be removed from version control, can't it?
<jelmer> SamB, if there's only ignored files in it, sure
<jelmer> SamB, but in that case the user probably won't be aware of it
<SamB> oh. is ignoring that important?
<SamB> well, it still seems slightly less urgent than a warning
<SamB> er. s/warning/conflict/
<jelmer> SamB, so you think a directory should become "unknown" at that point?
<jelmer> SamB, in that case you risk that a user runs "bzr add" to add their other unknown files and ends up re-versioning the directory
<SamB> hmm.
<SamB> maybe I'd just like it to be easier to say "okay, go ahead and unversion that"
<jelmer> SamB, right
<SamB> could be something to add to dvc
<jelmer> SamB, I think it would be reasonable to automatically mark a conflict as resolved if the remote removed a file/directory but it was changed locally
<jelmer> SamB, and the user then removed the local files
<SamB> hmm.
<SamB> well, I didn't remove it yet actually
<SamB> I'm so lazy
<jelmer> join the club :-)
<SamB> I still don't get why bzr-status and bzr-conflicts use dvc-diff-mode ...
<mwhudson> jelmer: hello
<BasicOSX> We still on track for 1.13final on 03/13 or should I push a 1.1.3rc2? I've posted to bazaar general about it.
<ovnicraft> hi, i see in lauchpad trac-bzr is part of bzr if anyone can help me here?
<mwhudson> BasicOSX: how many changes have hit bzr.1.13 since rc1 ?
<mwhudson> BasicOSX: i was going to nag you about sneaking some patches in, but i don't think it's worth it any more
<BasicOSX> mwhudson:  do not know the number of changes, don't have ability to check right now, and I don't control the freeze, I just do the work of pushing the release :-)
<mwhudson> BasicOSX: do you know what revno 1.13rc1 was?
<BasicOSX> bzr log, look for 'Release 1.13rc1'
<LarstiQ> bzr log -m Release\ 1.13rc1
<mwhudson> hm, there have been two landings
<LarstiQ> ovnicraft: do you have an actual question?
<mwhudson> (vila) Fix non ascii symlink handling
<mwhudson>       (spiv) Fix bogus 'Source format does not support stacking' warning
<mwhudson>         when pushing to smart server
<BasicOSX>     revno: 4104.1.1, should be PQM submission
<LarstiQ> abentley: ok, how is that going?
<mwhudson> both look reasonably minor
<mwhudson> though i guess the non-ascii one could potentially cause problems
<ovnicraft> LarstiQ, i have problems with trac-bzr i get the output
<ovnicraft> can you help me about that?
<lucypher> Hi , I can't branch a project from launchpad , here the result: http://pastebin.com/m41156b8b
<lucypher> I'm on Ubuntu jaunty
<LarstiQ> ovnicraft: I can try, but so far I don't know what problem you are experiencing
<LarstiQ> lucypher: Permission denied (publickey) is the important part
<mwhudson> hmmm
<awilkins> Ah, he's defined launchpad-login but either hasn't uploaded a key or doesn't have it available to the local bzr process
<mwhudson> why isn't the non-ascii symlink fix in bzr.dev
<mwhudson> vila: hi :)
<lucypher> LarstiQ : I did...     bzr lp-login
<awilkins> lucypher: Did you upload a public key, and is it available in your local ssh-agent
<awilkins> Or even in ~/.ssh/id_rsa
<awilkins> (the private key to go with that public key)
<LarstiQ> lucypher: have you followed a process like https://help.launchpad.net/YourAccount/CreatingAnSSHKeyPair ?
<LarstiQ> lucypher: the ssh server on launchpad is complaining it doesn't know the key you are trying to log in with
<lucypher> I've moved my Home partition recently and did some cleanup... ;-)
<LarstiQ> lucypher: that might explain it ;)
<ovnicraft> LarstiQ, any pastebin to this channel?
<ovnicraft> LarstiQ, http://pastebin.com/m35bd5f39
<ovnicraft> my error
<lucypher> LarstiQ , awilkins : thanks
<jelmer> mwhudson, hi
<mwhudson> jelmer: so, bzr-svn vs codespeak currently breaks because of that svn bug
<mwhudson> jelmer: i can probably remove the problem revprops
<mwhudson> jelmer: if you explain how :)
<mwhudson> (i can probably figure it out myself, but my brain is on go-slow today)
<awilkins> AFAICR if you set them to an empty value they will be removed
<awilkins> Ah, or propdel
<awilkins> svn propdel PROPNAME --revprop -r REV
<jelmer> mwhudson, the problem is it isn't not the revprops
<jelmer> mwhudson, it's fileprops
<mwhudson> jelmer: grunk
<mwhudson> jelmer: i guess committing a change that deleted the file props wouldn't help?
<mwhudson> i mean, i have root on the box, all things are possible :)
<mwhudson> but i'd rather not knacker the repo
<jelmer> mwhudson: fixing it will require a svndump + edit of the svn dump + reload
<mwhudson> jelmer: if i manage to do an import over svn+ssh:// or even file:/// will updating it over http: work?
<jelmer> mwhudson, I think so
<vila> mwhudson: hi (still syncing my clock so unsure if *your* was minutes or hours ago :-)
<mwhudson> vila: minutes :)
<mwhudson> vila: you landed a change to bzr.1.13 wrt unicode symlinks
<mwhudson> vila: it doesn't seem to be in bzr.dev
<mwhudson> vila: any deep reason for that?
<jelmer> mwhudson, alternatively, you could add a hack to bzr-svn to assume an empty set of properties if it can't retrieve them
<mwhudson> jelmer: hm, that sounds interesting
<jelmer> mwhudson, there should only be one place where it's called
<vila> mwhudson: check again, it should have been merged back
<jelmer> mwhudson, I'd rather not have it in mainline bzr-svn though, since the error that is raised is a generic "RA request failed"
<mwhudson> vila: oh right. r4124
<jelmer> LarstiQ, perhaps in changelog
<awilkins> Have we gone gpl2 ?
<LarstiQ> awilkins: bzr-svn
<LarstiQ> jelmer: I'm mimicing debian unstable now
<jelmer> awilkins, GPLv2 or later specifically, it was GPLv3 or later
<awilkins> Righto
<jelmer> LarstiQ: Yeah, in hindsight I probably should've mentioned it
<ovnicraft> LarstiQ, did you check my error with trac-bzr?
<LarstiQ> ovnicraft: ah yes, it wasn't familiar, I then went to look if there was a bug filed for it but trailed off
<LarstiQ> ovnicraft: what version of trac integration are you using?
<ovnicraft> trac 0.11.2.1 - plugin from branch
<LarstiQ> ovnicraft: which version of trac bzr?
<ovnicraft> 0.2
<LarstiQ> ovnicraft: https://bugs.launchpad.net/trac-bzr/+bug/318839 and https://bugs.launchpad.net/trac-bzr/+bug/341916 look similar
<ubottu> Error: Could not parse data returned by Ubuntu: The read operation timed out (https://launchpad.net/bugs/318839/+text)
<LarstiQ> ovnicraft: oh, that latter one is by you :)
 * LarstiQ wonders how to track his ppa upload status
<LarstiQ> aha! A view build records link, sneakily hiding out of view.
<abentley> LarstiQ: Well, I've got the physical merge done, but I haven't got it logically updated so that all the tests pass.
<abentley> LarstiQ: It's at http://code.aaronbentley.com/bzr/bzrrepo/nested-trees
<LarstiQ> abentley: thanks for the heads up btw
<abentley> LarstiQ: np
<LarstiQ> gah, even in a short time the diff ratchets up :/
<EnCuKou> Hello. Does anybody know about a bzrlib transport that simulates network failures, for testing?
<EnCuKou> It shouldn't be too hard to write a simple one, I'd just like to reuse if one's floating around somewhere.
<Peng_> EnCuKou: There might be stuff in the test suite.
<EnCuKou> Peng_: Thanks. I didn't find much there though.
<vila> EnCuKou: Hi !
<vila> EnCuKou: There is no such thing as transport simulating failures, you want test servers simulating failures instead
<EnCuKou> vila: Hello!
<EnCuKou> vila: Okay, I'll look for that.
<vila> EnCuKou: As a starting point you can have a look at bzrlib.tests.http_utils.py I think or http_server.py
<loffe> Is there a way to ignore files when using "bzr upload"? (For example I don't wan't to upload my test cases but I want them in my repo)
<vila> loffe: not yet, but  we're thinking about it
<EnCuKou> vila: Okay, thanks
<vila> loffe: filtered views may also be a way to address that, but again nothing works out of the box right now
<loffe> vila, "thinking" as in "has not written it yet" or "not sure if it's needed" ?
<vila> loffe: "thinking" as in "beuno kicked my ass enough that it will be written" :)
<loffe> hehe
<vila> EnCuKou: the closest server for what you're after may be test_http.TestWallServer
<loffe> Is there any "smart" way of adding my testcases now?
<vila> loffe: adding testscases *is* smart ;)
<loffe> yeah, that was my idea, but I don't want to upload them (and then delete from webserver)
<vila> loffe: seriously, if you want to use bzr-upload yet have test cases, write them in a different branch
<vila> as in separate branches
<EnCuKou> vila: Okay. I'll need some time to grok how it works, but I think I'll manage with your hints ^^
<loffe> ok. So how do I create a "sub"-branch within my working tree?
<loffe> bzr: ERROR: No repository present: "file:///media/windows/Users/Eloff/Documents/src/jobb/www/timjack.se/trunk/tests/"
<loffe> when doing "bzr init tests/"
<vila> EnCuKou: you may also want to have a look at lp:~vila/bzr/local-test-server, search for and install pyftpdlib (code.google.com/p/pyftpdlib/ ) and start a test server with failure from there
<vila> loffe: better create your branch *outside* of the initial one for now, later on, there will be better ways to manage that setup, but for now, that's the best I can think of
<vila> loffe: I understand it sub optimal as you will need to commit in both though....
<EnCuKou> vila: OK
<loffe> vila, yea, how long till upload ignore is working? weeks, months?
<vila> loffe: not years :-) But patches welcome !
<loffe> vila, Maybe I'll look into it. Have just fallen in love with python :)
<vila> loffe: The main blocking point is the lack of a good and easy to modify ftp test server, and that will be available RSN
<cyberix> I received a patch that was created with bzr send, but for some reason that persons commit did not appear in my bzr log
<cyberix> Only my own commit, which I did after merging the patch in, is shown on the log
<james_w> cyberix: how did you merge the patch?
<bob2> lifeless: still upgrading to --development after 20 hours - should I ctrl-c and file a bug w/backtrace?
<cyberix> bzr merge ../foo.patch
<james_w> cyberix: that should work, does "bzr --no-aliases log" show it?
<bob2> did you commit right after merging?
<cyberix> james_w: no
<cyberix> bob2: yes
<james_w> odd
<cyberix> http://www.cs.helsinki.fi/u/froblom/Kunquat/kunquat-photos.patch
<cyberix> This is the patch
<cyberix> It is huge
<cyberix> It cointains a few jpgs
<cyberix> Is there something wrong with it?
<cyberix> You could try merging it yourself
<cyberix> how this actually work
<cyberix> she did her send against the lp trunk branch
<cyberix> should I still be able to merge it in?
<cyberix> to my own branch
<cyberix> or can it only be merged to lp trunk?
<cyberix> i.e. Is it at all possible to send a patch to someone, without having access to his branch?
<cyberix> or
<cyberix> Should anyone be able to apply that patch after doing "bzr branch lp:kunquat"?
<lifeless> bob2: is strace showing activity?
<AirBender> Hello
<bob2> lifeless: yes, and it's eating 95% of a cpu
<AirBender> I'm looking for a simple way of tracking the current version of my source code inside my code, and also with autotools, in order to show the current version automatically
<AirBender> may be a header file generated by bzr like config.h of autotools?
<Peng_> AirBender: bzr help version-info
<lifeless> bob2: hit ctrl-\ and get a backtrace :)
<bob2> lol debuggerry
<SamB> Peng: but doesn't that vary branch-to-branch?
<bob2> SamB: isn't that the point?
<bob2> (you want the revid not the revno)
<SamB> ah
<AirBender> thanks Peng_ that's what i'm looking for, but still don't know how to integrate it with my configure.ac file in order to keep the version at make dist time
<AirBender> but I think this is more likely an autotools question
<lifeless> spiv: I've audited bzr.dev for missing patches
<igc> morning
#bzr 2009-03-13
<nekohayo> hey there, has anyone managed to get pre-commit hooks (such as pep8.py to inspect the code) to work?
<nekohayo> I spent a day and couldn't figure it out
<bob2> were you doing a very simple test (ie hook, repository and checkout all on the same machine and owned by the same user)?
<mwhudson> oh for heavens sake
<mwhudson> the hook changes in bzr.dev break launchpad :/
<mwhudson> is there an api for uninstalling a hook now?
<SamB> jelmer: how infeasible would it be for bzr-svn to support creating SVN-format commit bundles ?
<mwhudson> hm, i think this change isn't in 1.13; good
<SamB> hmm, wait, that wouldn't work since the SVN user who applied it wouldn't be able to create the BZR merge commit
<nekohayo> bob2: well basically, I would like that before commit, http://svn.browsershots.org/trunk/devtools/pep8/pep8.py gets run over recursively over the .py files in my branch, and if errors arise, it prevents the commit
<rocky> nekohayo: i would imagine you'd prefer it only ran against the .py files that were added/modified in the commit
<SamB> jelmer: can bzr bundles be merged into plain-old SVN checkouts?
<nekohayo> rocky: right, not a bad idea
<bob2> nekohayo: right, but make sure you try the simplest case to begin with
<nekohayo> well, to me there are no simple/hard test cases, they're all hard as a newbie :)
<jelmer> SamB: well, the question really would be, is there such a thing as a svn-format commit bundle?
<bob2> nekohayo: mkdir blah ; cd blah ; bzr init ; do the hook stuff ; bzr commit
<jelmer> SamB, the svndump format mentions specific revision numbers for example
<jelmer> SamB: Yes, in theory it should be possible to merge bundles into plain old svn checkouts
<jelmer> SamB: The infrastructure is there, I've just never tried it
<jelmer> SamB: If it doesn't work, I'd be interested in hearing about it
<lifeless> mwhudson: ?
<lifeless> bob2: did you get a backtrace?
<mwhudson> lifeless: oh never mind, i'll whine about it next week
<lifeless> mwhudson: what does lp need, I can file a bug for you
<nekohayo> bob2: oh yeah, well that's what I was doing basically. The problem is that pep8.py is a tool that prints the errors to the terminal
<nekohayo> not meant to talk to bazaar directly, from my vague understanding
<bob2> nekohayo: sure, so you need to write a hook script to call it
<bob2> lifeless: yeah, pastebin or bug report?
<lifeless> pastebin is a good start
<mwhudson> lifeless: i already did https://bugs.edge.launchpad.net/bzr/+bug/301472
<ubottu> Ubuntu bug 301472 in bzr "need a way to uninstall a hook" [Low,Confirmed]
<bob2> lifeless: http://pastebin.ubuntu.com/130410/
<SamB> jelmer: I meant more "svn apply" style ... except the command I was thinking of doesn't seem to exist ???
<SamB> wierd
<lifeless> bob2: hit continue
<lifeless> bob2: and try again a few seconds later
<bob2> lifeless: oneline traceback: -> signal.signal(signal.SIGQUIT, _debug)
<lifeless> heh
<lifeless> file a bug, no idea bout how to reproduce though
<lifeless> do you have something funny in the working tree?
<bob2> lifeless: unchanged, just a branch of bzr.dev (--1.9 format) at r4119
<lifeless> mwhudson: ah, why do you need that? ['m worried iti will lead to folk trying to use hooks oddly]
<mwhudson> lifeless: well, transform_fallback_location is an odd hook anyway, it arguably should be an argument to Branch.open or something
<mwhudson> lifeless: but for tests, basically: install the hook, run the test, uninstall the hook
<mwhudson> though come to think of it, bzrlib's testcase resets hooks, doesn't it?
<lifeless> mwhudson: tets run with no hooks anyway, they get reset in setUp
<mwhudson> hmm
<mwhudson> lifeless: ok, will see if we actually need it
<lifeless> (and put back to before-the-test in runCleanups())
<jfroy> vila: thanks for the review. New patch coming soon.
<jelmer> SamB: yeah, I'm not aware of anything like that either
<jelmer> SamB: as far as I have seen svn people always work with plain unified diffs
<SamB> I wonder how I came to think there was one?
<jelmer> SamB: never with anything that includes multiple revisions
<jelmer> SamB: git has an apply commands
<jelmer> s/commands/command/
<SamB> jelmer: well, it would be posible to bundle together unified diffs ;-P
<jelmer> SamB: :-)
<jfroy> Oh hey
<jfroy> I just noticed that Sourceforge added Bazaar, Git and Mercurial to their list of supported / integrated / provided VCSs
<jfroy> Good to know bzr didn't get left out :)
<jelmer> jfroy: ah, neato
<lifeless> jfroy: cool
<jelmer> lifeless: speaking of 1.13 blockers..
<jelmer> lifeless: a lot of people seem to be hitting the bug about texts with lhs parents that are ghosts
<jelmer> lifeless: I've tried looking into it, but I'm not really familiar enough with that code
<lifeless> is there a bug ?
<jelmer> lifeless: yes, one sec
<jelmer> lifeless: bug 336749
<ubottu> Launchpad bug 336749 in bzr-svn "reconcile raises a KeyError on a fresh branch" [High,Invalid] https://launchpad.net/bugs/336749
<lifeless> jelmer: you claim to have a fix; is that right?
<jelmer> lifeless, oh no, that's more a workaround for one of the places where the problem appears
<jelmer> it makes reconcile happy but then fails later
<lifeless> jelmer: so the LHS parent should be fine to be a ghost, the _delta_ parent isn't.
<jelmer> lifeless, right, but I'm not specifying the delta parent unfortunately
<lifeless> jelmer: you don't, thats internal
<jelmer> lifeless, so it would be a bug in the pack code right?
<lifeless> yes,
<lifeless> there are two vectors of parents
<jfroy> jelmer: eh, didn't know about that check command. Ran it on my main work svn repository, and it caused bzr-svn to thrown an error :p
<lifeless> vector[0] is the parents
<lifeless> vector[1] is the delta parents
<jelmer> jfroy, please file a bug
<jfroy> doing just that :p
<jelmer> lifeless, anyway, the problem isn't really in reconcile, it seems to be because add_lines() stores parents[0] as the delta parent even though it's not present
<SamB> jelmer: but I guess it would be hard for them to refer to eachother when the revision numbers aren't known ...
<jelmer> SamB, right, but a svndump isn't really a patch format
<jfroy> jelmer: https://bugs.launchpad.net/bzr-svn/+bug/342065
<ubottu> Ubuntu bug 342065 in bzr-svn "KeyError due to missing file id while running bzr check on SVN repository" [Undecided,New]
<lifeless> jelmer: are you sure?
<lifeless> jelmer: if it stores a fulltext the delta parents should be empty
<lifeless> jelmer: quick details to reproduce
<jelmer> lifeless, I'm not sure, but that's what the symptoms suggest
<lifeless> 13:15 < lifeless> jelmer: quick details to reproduce
<jelmer> lifeless, checking now if there's a public repo I'm aware of that has it but not as big as inkscape
<jelmer> lifeless, found one I think, I'll put up a tarball of the repo
<lifeless> jelmer: svn url would do, then I can breakpoint in add_lines
<jelmer> lifeless, so I think https://mnemosyne-proj.svn.sourceforge.net/svnroot/mnemosyne-proj/trunk should trigger it as well
<jelmer> hmm, actually
<jelmer> lifeless, that now fails in a different way
<jelmer> lifeless: so, the other repo with which it should be reproducable is inkscape
<jelmer> and some private repositories :-/
<lifeless> jelmer: do you pass in the parent_texts dict?
<jelmer> lifeless, yes
<jelmer> in this particular case it should be empty though
<lifeless> jelmer: ok, so - look in knit.py
<lifeless> at def _add
<lifeless> I'll walk you through
<jelmer> ok
<jfroy> vila: new patch in
<lifeless> jelmer: so, look in th efunction for present_parents
<lifeless> and the variable delta
<jelmer> lifeless, yeah, I've looked at this function before
<lifeless> if you can see any way that delta = True when the LHS parent is absent, I'd love to know
<lifeless> if delta is False we won't delta
<lifeless> and if we don't, we know we write [] as the delta parents, or text reconstruction wouldn't work :P
<jelmer> lifeless, yes, this bit seems to work ok
<jelmer> lifeless, A repository created this way is fine
<lifeless> right, I thought so
<lifeless> so its a bug/issue in packer
<jelmer> lifeless: does reconcile use packer as well?
<lifeless> yes, a subclass
<lifeless> jelmer: one thing that may help you is to know htat in a non-stacked repo, reconcile will eliminate all references in the per-file graph to texts that are not acessible
<lifeless> -> you would probably be better not putting them in the first palce
<jelmer> ah, hmm
<jelmer> lifeless, so if a text revision had two parents
<lifeless> test_reconcile explains I think
<jelmer> one of which would be inaccessible, what would it do?
<jelmer> store neither?
<lifeless> text_parents =[inaccessible, acceislbe] => [accessible]
<lifeless> lunching
<jelmer> lifeless, so couldn't add_lines() just do that immediately?
<jelmer> lifeless, and doesn't that cause inconsistent parents errors?
<jfroy> vila: netrc test patch is now in
<lamalex> rockstar: ping, re: bzr autoreview
<rockstar> lamalex, hi
<lamalex> rockstar: hey, i get an error when i try and load your plugin, someoneleft a coent on your blog post with the same error
<rockstar> lamalex, the wadllib one?
<rockstar> bzr branch lp:wadllib
<lamalex> ah ok
<lamalex> thank you
<rockstar> lamalex, bzr-autoreview is dependent on launchpadlib, and launchpadlib is dependent on wadllib
<lamalex> can't wait to try it
<rockstar> lamalex, make sure you're tracking trunk.  I made some big changes a few days ago.
<lamalex> rockstar: yeah, i was planning on playing with it and hopefully contributing
<lamalex> same with tarmac
<lamalex> both look like awesome tools
<rockstar> lamalex, patches are always welcome.
<emmajane> Um. Question: http://identi.ca/notice/2758847, "have they fixed line-ending handling in #bzr yet?"
<rockstar> emmajane, I get those alerts.  I was just looking into that.
<emmajane> yay :)
<emmajane> thanks, rockstar!
<fullermd> Hey, line endings in #bzr work just fine   :p
<emmajane> fullermd, yeah, I resisted from replying, "I have new lines, what's your problem?"
<fullermd> Sadly, all my lines are really old...
<emmajane> heh
<rockstar> emmajane, after fighting a hellacious bug line ending bug today, I wonder if it's ever really fixed.
<emmajane> :/
<emmajane> Hopefully by the end of the weekend I'll have wrapped my head around a useful way to make this "social" without "flamewar"ish http://www.bzrvsgit.com/
<rockstar> emmajane, neato.
<emmajane> rockstar, Hopefully. :)
<emmajane> rockstar, I'm curious to know how people make the decision on which VCS is the best for their workflow. I picked based on community and how awesome this channel is. :)
 * fullermd wouldn't bet overly long odds on it...
<emmajane> fullermd, odds on which?
<fullermd> I suspect, based purely on sheer mean-spiritedness, that most people don't.  They pick which workflow is best based on their VCS, which they ended up with via one of a handful of processes, practically none of which are deep personal comparisons...
<lifeless> jelmer: no, having the parents when reconcile will strip them -> inconsistent
<lifeless> emmajane: I think you picked on great things :)
<emmajane> lifeless, thanks :)
 * emmajane nods to fullermd 
<fullermd> emmajane: Avoiding flaminess.  It's possible I guess, but IME those sort of things end up being one of contentious or bland-cum-useless.
<lifeless> line ending stuff is getting there; the basic stuff is in final review
<fullermd> (which isn't to say that 'both' doesn't happen too, of course.  But ending up with 'neither' is a real eye-of-a-needle)
<emmajane> fullermd, I want this site to be "what questions should I ask" and then link into the git/bzr/whatever sites. Not the actual answers to the questions. I might be wishing for the moon, of course. ;)
<lifeless> poolie: I really want a bzr+http server on bazaar-vsc.org
<rockstar> lifeless, emmajane, about the time of Guadec last year, SOMEONE on Planet Gnome wrote a blog post about picking technology based on community.  I'd love to find that post again.
<vila> jfroy: Can't you just make a single patch ?
<emmajane> lifeless, kay. I'll reply to the dent with pseudo authority now. ;)
<lifeless> poolie: ok with you if I look into making that happen next week
<jfroy> vila: thought from your comments you waned 2
<fullermd> The questions can get pretty contentious all by themselves.
<jfroy> one to add a test to netrc to show its bug
<fullermd> Actually, the difference between Brand X and Brand Y can almost be described as "what questions are important"...
<jfroy> and one to add the additional keys in AuthenticationConfig
 * emmajane nods.
<lifeless> emmajane: http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C49B91135.2070700%40internode.on.net%3E and http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C494A0260.5000706%40internode.on.net%3E are the two remaining branches
<emmajane> fullermd, totally agreed. e.g. I don't care about speed for my work so I really don't care if git is faster or not.
<emmajane> lifeless, excellent, thanks.
<vila> jfroy: sorry, I wanted you to add a single test, which is enough to exhibit the problem, but as part of your submission (so it can be approved at once)
<jfroy> vila: I merged the netrc test branch in the AuthConfig branch, so huh... bzr send-ing away :p
<jfroy> (to test the netrc test :p)
<lifeless> vila: could you send it up again please, with a clearer message :)
<vila> lifeless: Respect bzrlib.tests.test_osutils.TestWalkDirs.test_walkdirs_os_error intent sounds better ?
<lifeless> vila: 'restore the test that OSError raised from walkdirs includes the file the error occured on in its str()'
<lifeless> vila: respect per se isn't the point :
<lifeless> )
<vila> jfroy: the review was about reverting your previous changes to the existing tests and adding the new one which covers your fix
<jfroy> vila: yeah, that was not a good move in retrospect
<jfroy> New patch sent
<vila> jfroy: ok
<lifeless> james_w: check IRC logs for 2009-02-10
<lifeless> james_w: thats when the chat with oddbloke happened
<lifeless> james_w: 11:56 #bzr: < lifeless> 11:37 < Odd_Bloke> OK, so go for: '(y)es, (N)o, (a)lways shelve remaining, ne(v)er shelve remaining, (q)uit'?  With a '(d)iff' option to come later.
<lifeless> james_w: ^ that was the end of the discussion
<james_w> thanks
<thumper> lifeless: got a minute?
<lifeless> somehwat
<thumper> lifeless: I was just wondering if I could have a two line summary of the week ?
<thumper> lifeless: going well?
<lifeless> yup
<thumper> lifeless: are we going to have a chk/gc format for 1.14?
<lifeless> we've finalised the choice of gc with chks
<lifeless> looking on track for that
 * thumper nods
<fullermd> Sweet.
<lifeless> if its not in 1.14 it will be definitely in 1.15;
<thumper> what about a unified format for nested trees/rich root/normal?
<lifeless> as a beta format
<lifeless> the new chk format will be in only a single flavour
<thumper> lifeless: one single flavour that supports nested trees and rich root?
<lifeless> there is no guarantee that we'll not find further things to change; but it will support the current nested trees data and rich roots; we won't be doing a non-rich-root version
 * thumper nods
<thumper> cool
<thumper> lifeless: I take it abentley is happy with the format for potential next-gen nested trees?
<lifeless> yes
<schmichael> just upgraded to bzr 1.3 ... whats this bzr upgrade --subversion feature?
<lifeless> a lot of packaging branch stuff has happened too
<schmichael> 1.13
<schmichael> sorry
<thumper> has --subversion been added as a latest rich-root alias?
<lifeless> thumper: no
<thumper> ah
<lifeless> schmichael: I'm not sure, I suspect its autogenerated and not intended
<schmichael> !
<lifeless> schmichael: subversion is one of the formats bzr supports
<schmichael> via bzr-svn right?
<lifeless> yes
<schmichael> k
<lifeless> which you have installed :)
<schmichael> whats rich root?
<lifeless> rich roots are a bit of metadata that makes bzr repositories more capable; its not currently the default and you shouldn't use it unless you have instructions to do so from somewhere
<lifeless> schmichael: if you want to upgrade your branches and repositories in 1.13, the latest format is still 1.9
<schmichael> oh i'm not worried about upgrading
<schmichael> just wondering what rich roots do
<schmichael> i've seen them mentioned a lot
<lifeless> yah, everything will be rich roots eventually
<schmichael> but couldn't really tell you what they do
<schmichael> so this magical piece of metadata does what now? :)
<lifeless> well directories are versioned in bzr
<lifeless> the root of a tree is a directory
<lifeless> but in the very early code it was special cased rather than being versioned like the rest
<schmichael> interesting
<schmichael> so what does tracking the root allow you to do?
<schmichael> thanks btw
<lifeless> join two trees together, so that the root of A becomes a directory in B
<schmichael> i'm a lone bzr user in a sea of git & hg fanboys here in portland, or :)
<schmichael> hm
<schmichael> so you can have a repo of branches?
<lifeless> roughly yes
<lifeless> this is the nested trees feature
<schmichael> ah
<schmichael> does bzr have or is it planning to add switching branches within a tree?
<schmichael> like git branches or hg named branches?
<lifeless> we have that already, via 'bzr switch' and checkouts
<fullermd> Tracking the root would also allow pivoting it, presumably.
<lifeless> we'd like to make it more friendly and accessible though
<lifeless> fullermd: not a useful use case generally though
<fullermd> Probably not, but it's one of those things that you'll need to do pretty soon if the tool can't (Murphy winz).
<fullermd> mtn has a special command for it.
<schmichael> hm, haven't used switched before and only used lightweight checkouts a bit... very interesting
<schmichael> switch*
<schmichael> mtn?  that still exists?! ;-)
<lifeless> schmichael: it does :)
<schmichael> http://upsilon.cc/~zack/stuff/vcs-usage/
<schmichael> ^ barely
<lifeless> fullermd: it does allow it, yes
<lifeless> schmichael: you should meet up with the ubuntu folk in portland :)
<fullermd> Well, it did last time I used it.  Which should be a lot more recent than it is.  freetime--.
<schmichael> lifeless: i'd love to!  active in the python group, but thats it
<schmichael> new to the area
<schmichael> well, and i'm a silly old debian user too
<schmichael> i always recommend ubuntu to others, but for some reason keep using debian myself
<fullermd> Usage in general matters less than in specific.  Frex, I've not yet _had_ to use git, but I have had to use mtn.  Funny ol world.
 * schmichael is addicted to debian unstable
<fullermd> Linux?  That still exists?!  ;-P
<schmichael> heh, barely.  portland python meetups are 99% macs
<schmichael> i hear rubys the same
<lifeless> schmichael: I'm still a DD - nothing silly about it :)
<schmichael> lifeless: excellent!  always dreamed of learning debian packaging but those damned docs always scare me off
<fullermd> Really?  Huh.  Is that just 'cuz the techie population is 99% macs, or is there actually a growing affinity there?
<schmichael> *shrug*
<lifeless> schmichael: some large number may be running Ubuntu on those macs :)
<schmichael> lifeless: some do, but afaict not many
<schmichael> speaking of communities and portland, somebody needs to do a bzr talk at osbridge: http://opensourcebridge.com
<schmichael> i'm sick of hearing about git ;-)
<james_w> emmajane: aren't you giving one?
<emmajane> james_w, who? what? where? huh? :)
 * emmajane reads up.
<emmajane> ah.
<emmajane> schmichael, www.bzrvsgit.com
<fullermd> You, with the lead pipe, in the study.
<schmichael> emmajane: ha, i know selena!
<emmajane> schmichael, selena is 50% of the selection committee. I think we have a good chance of having our talk accepted. ;)
<emmajane> schmichael, she's made of awesome.
<schmichael> true
<schmichael> and good at killing chickens ;)
<emmajane> omg!
<emmajane> yes.
<emmajane> you know stacey and amy too then?
<emmajane> or maybe you're not actually in PDX.
<schmichael> just moved here this fall
<schmichael> i know a stacey
<emmajane> woo!
<schmichael> staceyanderson?
<emmajane> She and I met at DrupalCon. I talked her ear off about how to run a local/sustainable/green conference. There may have been alcohol involved.
<fullermd> It's a good thing I'm so antisocial, or it might grate on me how all these interesting things happen way the heck away from me   :p
<emmajane> stacey with the purple scarf? I'm sure she has a last name.
<schmichael> ha
<emmajane> fullermd, I live in Canada. I assure you I do a LOT of travelling. ;)
<schmichael> ha, perhaps has a purple scarf, not sure.  but the stacey i know uses drupal :)
<emmajane> schmichael, do you know andy (thesethings) too?
<schmichael> fraid not
<schmichael> <--pdxnoob
<emmajane> she's a sys admin. Also made of awesome.
<emmajane> and Gab?
<schmichael> someday :)
<schmichael> no gabs either
<emmajane> I don't think I actually know the names of any PDX men. How odd.
<emmajane> selena took me on the Tour De Coop last summer.
<schmichael> nice
<emmajane> stacey ==> http://twitter.com/stacybird
<schmichael> i think i need the tour :)
<schmichael> ah that stacey!  heard of her, but i haven't met her
<emmajane> you get a map of pre-approved chicken farmers. And then you get to listen to them talk about how to kill rats.
<emmajane> it's ... well ... crazy.
<schmichael> hahaha
<emmajane> and you know about Flavour Spot?
<schmichael> god i love this town
<emmajane> go there for waffles.
<schmichael> no!
 * schmichael takes notes
<emmajane> DUDE!
<emmajane> and the distillery with really good gin?
<emmajane> dragn something, maybe?
<schmichael> bah
<fullermd> Funny, there was a rat-killing discussion at the liquor store a month or so back...
<schmichael> who has time for gin?
<schmichael> so much good beer!
<emmajane> omg. it's LOCAL gin.
<schmichael> good point
<emmajane> fullermd, which method won? pillow case? or just beating them?
<schmichael> but still, i think the local beer could keep me happy for multiple lifetimes
<fullermd> Apparently there's been a rash of them showing up in attics recently.  No chickens, though.  I hope.
<fullermd> I think machete was popular.
<emmajane> schmichael, http://www.slideshare.net/emmajane/version-control-for-mere-and-freelance-mortals-presentation <--- has photos of Flavour Spot in PDX
<fullermd> Of course, farther away from the house shotgun is always popular.
<emmajane> fullermd, where do you live?
<emmajane> fullermd, and how far away can I get? ;)
<fullermd> MS, US
<fullermd> I think you're probably far enough   ;)
<schmichael> emmajane: so thats the talk you're giving at osbridge? ;)
<emmajane> schmichael, not those slides, selena and I have been talking about doing a bzr vs git smack down for a while though.
<emmajane> I completely stole her git slides to do my bzr talk.
<fullermd> No, that's a backward strategy.  You need to _replace_ her git slides with the ones for your bzr talk.  That's how you win.
<emmajane> LOL
<schmichael> emmajane: the smackdown would be *amazing*
<schmichael> i'm trying to come up with a talk myself
<emmajane> schmichael, ultimately she and I don't really care what people choose as long as they choose something. So the talk will just be ... well .. I'm hoping it's as good as her how to kill four chickens in three years talk.
<schmichael> that will be tough, but i have faith
<emmajane> :)
<emmajane> I watched the talk while someone else was giving a talk at SCaLE. Ihadn't realized they'd started.
<emmajane> I was *howling* with laughter and selena had to tap me on the shoulder.
<emmajane> (I had ear buds in)
<schmichael> heh
<emmajane> james_w, do you think that answered schmichael's question? ;)
<thumper> emmajane: I've noticed that some of Matthew Revell's blog posts, like http://blog.launchpad.net/projects/shutter ask why people use bzr and lp
<thumper> emmajane: I think it may have been that one where they said
<emmajane> thumper, thanks for the link!
<thumper> emmajane: we looked at git but not all the devs could get their heads around it, but bzr was easy as it fit with the commands they knew from svn
 * emmajane nods.
<thumper> emmajane: didn't have to "re-learn" a bunch of stuff
<thumper> emmajane: it seems that git is good for those that can think like linus
<emmajane> yah
<thumper> emmajane: but it isn't for everyone
<emmajane> thumper, nothing is for everyone.
<thumper> emmajane: personally I really like bzr
<emmajane> thumper, except maybe breathing?
<thumper> emmajane: except perhaps oxygen
<emmajane> snap
<thumper> emmajane: hey, new name for bzr -- oxygen
<thumper> emmajane: although I think that is taken already
<emmajane> thumper, yeah...
<emmajane> thumper, for me it's about support and community. Lenz Grimmer gave a really great talk at DrupalCon in Szeged. He was my first non-Ubuntu person that was completely excited about version control. And generally I've found the git people I know what me to be some l33t scripting genius and say "it's easy" a lot.
<fullermd> Man, we had the discussion the other night about difficulty typing 'bzr'...   I don't want to think about where that would end up if it were called oxygen   :p
<emmajane> thumper, maybe people will outgrow bzr and move to git, but i'd rather get people using something than thinking all version control is too hard to bother with.
<thumper> emmajane: I'd rather people don't outgrow bzr
<thumper> emmajane: why would they?
<emmajane> thumper, people move on to different projects and the community changes.
<thumper> emmajane: it seems we'll have some people at the mysql conf in CA next month
 * thumper nods
<thumper> I was thinking for a particular project
<thumper> people move and change
<emmajane> thumper, some say "speed" was a factor for them. But 9/10 it turns out that LP was slow, not bzr. :(
<thumper> hopefully people that go from bzr -> git realise what bzr offers them :)
<thumper> emmajane: well, speed is a factor
<thumper> especially with LP
<emmajane> I also know a fair number of fence sitters in the drupal community.
 * emmajane nods.
<thumper> many people's first exposure is getting a branch
<emmajane> drizzle was the project that selena brought up.
<thumper> this should change greatly soon
<emmajane> she thought it was bzr being slow, but it was LP.
<thumper> lifeless and spiv have done great work recently with the smart server
<thumper> emmajane: you can beat me with the LP stick
 * emmajane nods. I think Selena will retry. Of course I'll have to try git so that I can actually comment with some kind of experience instead of just gushing about bzr. ;)
<fullermd> And many beers to them for that.  That's been one of my sore spots for a long time   :|
<emmajane> thumper, yeah, I know. :) I prefer not to beat people though.
<thumper> fullermd: agreed
<thumper> emmajane: well, how about tickle me with the LP feather then?
<emmajane> LOL
<emmajane> that's more likely to get results, I bet. ;)
 * thumper resists getting more lewd
<emmajane> yes, do resist.
<thumper> beer-o-clock
<emmajane> you'll just end up regretting it.
<thumper> I do
<thumper> every time
<thumper> :)
<fullermd> The scars fade in 15 or 20 years.  Sometimes.
<emmajane> beer-o-clock at 4? y'all start early down there.
<thumper> emmajane: it is 18:38 here
<thumper> pizza's are arriving shortly
<thumper> emmajane: I'm in NZ
<emmajane> thumper, not sprinting this week?
<thumper> emmajane: not me, we did one last week
<emmajane> ahhhh
<emmajane> right.
<emmajane> fabian pinged me about translation stuff.
 * thumper steps away from the computer
<emmajane> thumper, enjoy the pizza? :)
<emmajane> ok. I think it might be sleeping time for the east coast of north america. night all!
 * fullermd waves to emmajane.
<liw> I installed bzr-gtk to get "bzr viz"; I now seem to have something permanently stuck to my gnome panel notification area that pops up balloons when I commit stuff. How do I get rid of that?
<Peng> Hmm, I just hit paste in this channel. I wonder what I pasted?
<Peng_> Nothing, apparently. Anyway, it seems SourceForge now supports bzr, hg and git. :D http://arstechnica.com/open-source/news/2009/03/sourceforge-adds-support-for-new-version-control-systems.ars
<lifeless> liw: turn it off in options
<liw> lifeless, where are these options?
<liw> lifeless, also, what are they called in Finnish :-P
<fullermd> Inneresting.  I heard about git, but not the other two.
<james_w> liw: System->Preferences->Session I believe
<fullermd> That saves me wondering what to do when I get around to picking back up a project I have on SF that I don't wanna keep using CVS for   :)
<liw> james_w, oh, right; let's hope that sticks
<mwhudson> fullermd: hg and bzr are very new on sf
<fullermd> Well, I only heard about git in their email earlier this week.
<jml> ja1: https://pastebin.canonical.com/14928/
<poolie> ja1: "$0& $0&"
<lifeless> ah the internets
<asabil> jelmer: I had to make some changes to bzr-git to get it to work with bzr.dev
<asabil> is that a known issue ?
<asabil> I also get: bzr: ERROR: Tags not supported by <bzrlib.plugins.git.remote.RemoteGitBranch object at 0x9e0cbcc>; you may be able to use bzr upgrade.
<VSpike> Is there a workaround for the +x/-x permissions hell of using bzr in cygwin?
<VSpike> This stuff just adds confusion to my already easily confused brain :) http://pastebin.com/m19743912
<VSpike> Also, I don't get why the local copy is renamed to ".OTHER".  Surely ".THIS" would make more sense?
<Odd_Bloke> james_w: I have a branch for the shelve stuff somewhere, let me look for it.
<Odd_Bloke> james_w: http://bzr.daniel-watkins.co.uk/bzr/shelf-prompt/
<VSpike> I think Windows is the culprit .. it keep setting executable perms on everything, including data files
<VSpike> Perhaps I just need a commit script that does:- find -type f -print0 | xargs -0 --no-run-if-empty chmod a-x; bzr commit -m "$@"
<james_w> Odd_Bloke: thanks, I'll take a look
<Odd_Bloke> james_w: I will _hopefully_ have some time this weekend to look at it.
<Odd_Bloke> But I also have some Debian packaging to do, and a personal project to (hopefully) deploy.
<james_w> sounds fun :-)
<Odd_Bloke> As far as I'm aware, it's ready to be merged.
<Odd_Bloke> But I can't remember exactly where it is.
<Odd_Bloke> I'm really a little confused as to where the last month has gone. :p
<Kazade> hi all, is there an easy to to alter the commit message of the last commit in bzr?
<LeoNerd> Only by uncommit / commit
<Kazade> ok thanks
<LeoNerd> Which will have a different revid when it's finished, so it'll look like a branch divergance if other people have used it
<jelmer> asabil, hmm, that should already be fixed
<domas> Hello, how do I make xmlrpc requests use http_proxy ?
<LarstiQ> BasicOSX: should the rcs be in the bzr-ppa?
<CrashTest_> Why didn't I think of coming here first?  Heh.  Is there any sort of issue tracking system that works with bzr like unfuddle, or even trac?
<Tak> trac does
<LarstiQ> CrashTest_: trac, but it doesn't match very well. Redmine has a better domain model fit
<LarstiQ> CrashTest_: launchpad of course to
<LarstiQ> CrashTest_: and Bugs Everywhere
<CrashTest_> LarstiQ: Awesome!  Are these free?
<CrashTest_> launchpad is, as I understand it.
<LarstiQ> jelmer: I uploaded 0.5.3, but it's bzr 1.13~ dependency wasn't satisfied, though :)
<domas> hehe, 'bzr branch' takes 200m already
<CrashTest_> don't mind me, I will look them up from here, thanks for the pointer!
<LarstiQ> CrashTest_: all but launchpad are available right now as Free Software
<LarstiQ> CrashTest_: launchpad is free to use, and in the process of being released
<CrashTest_> Ah, so I was exactly backwards :)
<LarstiQ> domas: from what to what?
<CrashTest_> LarstiQ: Thanks!
<domas> LarstiQ: "bzr branch lp:something" connects to some canonical xmlrpc box directly
<domas> hold on
<davidstrauss> CrashTest_pie: If you're working on Intuit stuff, we should discuss bzr-based deployment strategies for testing, staging, and production for your clusters.
<davidstrauss> CrashTest_pie: Or anything serious, Intuit or not.
<CrashTest_pie> davidstrauss: Actually, I am considering this for everything in the future.
<domas> LarstiQ: connect(4, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("91.189.90.218")}, 16
<CrashTest_pie> davidstrauss: Intuit wanted their site done in 4 days, and I basically didn't do anything in the way of versioning for their theme job.
<domas> LarstiQ: thats xmlrpc.edge.launchpad.net
<CrashTest_pie> shame on me, I know.  I am trying to change my workflow right now, so that everything I do is versioned.
<CrashTest_pie> So yes, davidstrauss, I would VERY much like to talk to you about this.
<CrashTest_pie> but now, pie.
<CrashTest_pie> I will be right back.
<domas> LarstiQ: if I specify https:// paths directly, it works via proxy
<asabil> jelmer: not with the latest code from launchpad
<jelmer> asabil, from my branch?
<Tak> what's the bzrlib way of dealing with authentication (e.g. for commits?)
<asabil> jelmer: yes
<asabil> jelmer: self._lock_count = 0
<asabil> trying to set an unsettable attribute
<domas> hehe, bzr branch taking 500M
<domas> I really need to upgrade my desktop
<asabil> Tak: commits can have a Testament attached iirc
<CrashTest_> davidstrauss: let me tell you that I am super pleased that fourkitchens has the Drupal repo in bzr.  And you blog posts have made things nice and easy for me to start picking up bzr.
<Tak> asabil: looking at Testament, either I'm misunderstanding you, or I don't see how that will help
<asabil> Tak: the testament can be used to prove that a commit has been made by someone
<CrashTest_> davidstrauss: if you didn't pick up on this, I am a VCS noob.
<Tak> oh - I mean for committing to a repo that requires authentication
<Tak> like something on an sftp transport that requires a password
<asabil> Tak: ah ok, this is not really handled by bzr itself, it is generally delegated to a lower level (bzr+ssh for example uses the ssh authentication means)
<asabil> Tak: launchpad uses a different approach from what I understood
<Tak> so if I wanted to handle the authentication programmatically, I'd have to special-case each transport?
<asabil> they have a bzr plugin overriding LocalTransport which does various checks
<LarstiQ> Tak: what is the aim you are going for?
<Tak> I want to be able to accept authentication details in advance from a gui, then perform a commit(/push/merge/whatever) using bzrlib
<LarstiQ> aha
<LarstiQ> Tak: have a look at how qbzr does it, and at credential stores
<LarstiQ> Tak: the netrc plugin too
<Tak> aha, I think AuthenticationConfig may be what I was looking for
<luca> Hi, if someone updates a branch in launchpad, how do I get the updates?
<luca> cd branchfolder -> bzr update??
<asabil> luca: if it is an unbound branch, then use bzr pull
<luca> it's this one https://code.launchpad.net/~pyreved-devtm/pyreved/main
<asabil> luca: the fact that it is bound/unbound depends on how you did get the branch in the first place
<luca> I got it using this command: bzr branch lp:~pyreved-devtm/pyreved/main
<asabil> luca: if you did a bzr branch lp:pyreved then bzr pull is what you want
<asabil> then bzr pull :)
<luca> ok thank you very much!
<asabil> you're welcome
<DavidLeon> anyone would change bazaar to C#?
<Kinnison> How do you mean?
<Kinnison> Rewrite it? I doubt it.
<DavidLeon> C# crossplatform issue is being solved. mono works on *nix, and C# IDE is much better than python, so the C# performance
<DavidLeon> from the maintaining and getting more developers aspect, it's good to move to C#
<BasicOSX> LarstiQ:  about rcs being in the ppa, good question, since I'm new, I don't know. I'll ask.
<Toksyuryel> it doesn't solve that fact that C# is a god-awful language
<DavidLeon> Toksyuryel: why python is so much non-awful than C#?
<Toksyuryel> there is no good reason to switch from python to C#
<OllieR> is it possible to convert a heavyweight checkout into a leightweight checkout
<OllieR> ?
<asabil> DavidLeon: I think implementing bzr in c# could be a good idea
<asabil> DavidLeon: at least from an experimentation pov
<DavidLeon> yah, a light weight yet user friendly bzr can be developed because the rich .net framework
<Toksyuryel> .net is horrid
<lamalex> Toksyuryel: have you ever used C#? "horrid" is probably one of the last things I'd call it
<asabil> DavidLeon: do you have any plans on working on it ?
<lamalex> I mean if robust, typesafe language make you wet your pants, then I can see why you'd call it horrid
<lamalex> but if you enjoy clean syntax, and a powerful standard library, it should get you wet in other ways
<DavidLeon> asabil: not yet
<DavidLeon> asabil: just some brainstorm idea
<Toksyuryel> Why do you come into a channel for a software that is officialy a GNU project, and developed by Canonical, to advertize proprietary microsoft products?
<LeoNerd> The language doesn't always matter...
<LarstiQ> DavidLeon: other implementations of bzr are fine
<asabil> DavidLeon: I am pretty sure many people would like to see a parallel implementation in c#
<LeoNerd> I use a window manager written in Scheme, and a file sync daemon written in OCaml
<LeoNerd> Neither of these facts bother me. Both programs Just Work
<LarstiQ> DavidLeon: but I don't think the current developers will switch to a C# bzr project
<asabil> gtg, ttyl
<lamalex> .net/mono, whatever
<luks> bzr is more a framework than an application, you can't just switch or have parellel implementations
<LarstiQ> luks: the data formats, however, can be read and written by others
<LarstiQ> as can speaking the bzr protocol
<luks> the data formats change every few months
<DavidLeon> how's the bzr protocol compared to mercurial's?
<luks> and you want write better data formats if you are going to write a vcs from scratch
<LarstiQ> DavidLeon: I don't know mercurials
<DavidLeon> web benchmark seems show more favour of hg than bzr
<Kinnison> luks: "better" ?
<luks> Kinnison: faster to access
<LarstiQ> luks: let me put it another way, I have no objection to .net bindings, wether they os.system or implement some things again
<DavidLeon> yet i find bzr most comfort to use
<Kinnison> luks: Given what constraints? Under which conditions. It's hard to satisfy "fast to read" "fast to write" "fast to traverse for annotations" "small on disk" and "small in memory"
<luks> LarstiQ: I don't disagree with that, I was just pointing out that bzr can't be simply seen as an "application"
<luks> Kinnison: sorry, I can see where this is leading :)
<Tak> the issue with parallel implementations is that there's always lag among the branches
<Tak> so they're only ever parallel some (often large) delta behind the edge of development
<luks> that's not a problem in general
<luks> for example the git formats will unlikely change any soon, so the dulwich or jgit guys can safely work on their implemenations
<luks> but bzr it based around it's API, not it's formats
<luks> *is
<Tak> sure, it becomes less of a problem if you push the amount of work being done in parallel down to e.g., interpreting a common file format
<mtaylor> lifeless: there are times when 1.9 format and bzr 1.12 feel slower...
<mtaylor> lifeless: when pushing a branch to lp, I seem to spend a lot of time in "Transferring:Walking content." now
<LarstiQ> mtaylor: could you -Dhpss that and look at the log?
<mtaylor> LarstiQ sure
<LarstiQ> mtaylor: I think I'm seeing the same thing
<mtaylor> LarstiQ: going to lunch right now - will do when I get back
<LarstiQ> mtaylor: np, I just had dinner :)
<Tak> oh man
<Tak> so does anybody know how I manipulate an AuthenticationConfig with bzr 1.5?
<Tak> __dict__ says I only have _filename, _config, and _input
 * LarstiQ looks at the source of 1.13
<Tak> ugh, it looks like I have to directly populate and set the ConfigObj
<LarstiQ> Tak: no get_credentials and set_credentials?
<LarstiQ> if so, then 1.5 is significantly different from 1.13
<Tak> it has get_credentials, but no set_credentials
<LarstiQ> Tak: (for 1.13, construct it with _file=None to the constructor)
<LarstiQ> Tak: you can't upgrade?
<Tak> I want/need to support what's in debian
<LarstiQ> which Debian?
<LarstiQ> lenny?
<LarstiQ> and no backports?
<Tak> sid
<LarstiQ> ah, I see.
<LarstiQ> jelmer: time to push stuff from experimental to sid now that lenny is released?
<LarstiQ> jelmer: ah, you already did
<LarstiQ> Tak: packages.qa.debian.org/bzr says 1.13 is in sid
<LarstiQ> Tak: which would make your life a bit easier if you can depend on that
<Tak> wth, is my mirror out of date?
<glyph> huh, I guess this won't be automatically announced: https://bugs.launchpad.net/bzr/+bug/342474
<ubottu> Ubuntu bug 342474 in bzr "bzr help push (or bzr push --help) results in a traceback" [Undecided,New]
<glyph> Oh
<glyph> yay
<glyph> I guess it will
<glyph> I can't believe I'm the first person to report that bug, I just couldn't find the duplicate :)
<Tak> that's weird; it give the help message in my ancient 1.5 package ;-)
 * LarstiQ grins at Tak 
<LarstiQ> glyph: could yoy try to disable the push-and-update plugin?
<LarstiQ> glyph: and try again?
 * Tak give up, make note to try again later with 1.13, go home
<glyph> LarstiQ: OK
<LarstiQ> Tak: you might be able to do it without an AuthenticationConfig perhaps
<LarstiQ> Tak: I'd need to look at the code a bit, but if all calls go through a credential store, you could just plug yours in and make it the default
<LarstiQ> Tak: which would save you from dealing with ConfigObjs
<LarstiQ> glyph: I'm reasonably sure that plugin is wrapping cmd_push and/but not providing a docstring
<glyph> LarstiQ: I don't even need to disable it.  I just updated it, and it fixed the bug.
<glyph> I guess I'll go close that :)
<LarstiQ> glyph: or turn it into "less scary warning on undocumented command"
<LarstiQ> glyph: does it actually give a traceback?
<glyph> LarstiQ: I dunno
<LarstiQ> (by itself)
<glyph> LarstiQ: Yes.  The traceback's in the bug report
<LarstiQ> glyph: I think that should be changed then
<glyph> A less scary warning would be good, but it should still list plugins or at least note the responsible plugin or soething
<glyph> otherwise it would have been mysterious why I didn't have help for push
<glyph> (the traceback itself was completely unhelpful)
<LarstiQ> glyph: yeah, setting internal_error=false on the NotImplementedError gets rid of the traceback at least
<LarstiQ> glyph: arguably, it shouldn't raise NotImplementedError to begin with
<thecookie> Howdy.
<thecookie> I have a workflow question.
<thecookie> Working on a web project, which will have a document root and is set up in an IDE. How do I use it smoothly with bzr and branching? Read somethign about a switch ?
<LarstiQ> thecookie: yes
<LarstiQ> thecookie: most IDEs have difficulties with thinking outside of their working directory
<thecookie> I have everything else working. A checkout from my main server. Branching that checkout. commiting/updating/pushing/pulling. But not sure where to fit in that switch (or any other method)
<LarstiQ> thecookie: so with switch, you keep 1 working directory (usually a Bazaar 'lightweight checkout') and `bzr switch` between branches, it then updates that one working directory with the difference
<thecookie> Yeah, that sounds like the thing I want. Atm I have ~/dev/main and ~/dev/some-branch
<LarstiQ> thecookie: http://doc.bazaar-vcs.org/latest/en/user-guide/index.html#id57
<thecookie> Would I have ~/dev/working-branch ?
<LarstiQ> thecookie: 5.5.3, Switching a leightweight checkout
<LarstiQ> thecookie: it wouldn't be a branch so that's slightly misleading, but yeah
<thecookie> Yeah, was just about to say that the URL fragment thingy didn't work :)
<thecookie> What would be a better name?
<thecookie> I'll test it out
<LarstiQ> thecookie: ~/dev/work :)
<thecookie> Thanks for the insight. :)
<thecookie> I guess I have to redo my repo then
<thecookie> with the --no-trees flag
<LarstiQ> thecookie: you can use `bzr reconfigure`
<thecookie> Thanks, I will try that
<jelmer> asabil, unfortunately that breaks 1.13~rc1
<asabil> jelmer: well I sort of fixed it, but now I am stuck with an error related to tags
<jelmer> asabil, running my trunk?
<asabil> jelmer: yes
<asabil> lp:~jelmer/bzr-git/jelmer
<asabil> wait I just pulled
<asabil> jelmer: I pulled from your trunk, and reverted the commit in revision 251
<asabil> it works for now, but I will hit a traceback related to tags soon
<thecookie> LarstiQ: Would the best solution to not having to type tha password on each time using sftp:// to add a key and use ssha?
<thecookie> Or can bzr store passwords?
<LarstiQ> thecookie: ssh keys are a good idea anyway. But with authentication.conf you can configure other credential stores, like .netrc
<asabil> jelmer: AttributeError: 'RemoteGitRepository' object has no attribute '_git'
<asabil> in File "/home/asabil/.bazaar/plugins/git/branch.py", line 46, in get_tag_dict
<schmichael> thecookie: seahorse on linux and putty on windows make setting up ssh keys fairly easy
<jelmer> asabil, what are you trying to deo exactly?
<asabil> jelmer: just cloning from a git repository
<thecookie> I'll check out seahorse
<asabil> bzr clone git://github.com/jimweirich/rake.git
<solarion> is there a way to have heavyweight checkouts automatically sync to local on commit if no net access and then master when re-connected to the net?
<LarstiQ> solarion: instead of doing commit --local, you want `bzr unbind; bzr ci; bzr ci; bzr ci; bzr bind`?
<LarstiQ> solarion: `bzr update` then will pivot your local changes
<jfroy> jelmer: the bzr check KeyError bug I reported yesterday also occurs when I do a bzr diff --old <remote branch> command.
<jfroy> And it happens for more than one branch stored in that repository, maybe even for all branches stored there (hard to verify that).
<lamalex> rockstar: how do I set my public branch with bzr-autoreview?
<jelmer> jfroy, is this a branch on which older versions of bzr-svn were used?
<jfroy> I've tried with two branches, and in both cases, yes.
<jfroy> And I've seen the error for 2 different files so far.
<lamalex> actually this is a generic bzr question, how do i set my public branch?
<jfroy> lamalex: through branch.conf (inside the branch) or through localtion.conf in ~/.bazaar/localtion.conf
<jfroy> *location.conf
<lamalex> jfroy: thank you
<jfroy> All the details in http://doc.bazaar-vcs.org/bzr.dev/en/user-reference/bzr_man.html
<jfroy> And it's locations.conf :p
<jfroy> Third time's the charm, I guess
<mrooney> Is there a way to get the size of a commit?
<mrooney> such as in KB
<mrooney> I guess for non-binary files getting the size of the diff works, although I may have binary files
<mrooney> well if anyone sees this and has an answer, please do email me @ubuntu.com :)
<rockstar> lamalex, did you get your help?
<lamalex> rockstar: yes thank you :)
<lamalex> works awesome, but is there a way to change what editor it uses
<rockstar> lamalex, I think it uses the $EDITOR environment variable.
<rockstar> lamalex, it uses the bzrlib mechanism for handling all that.
<lamalex> hm ok
<lamalex> i set  that to emacs, ill keep messing with it
#bzr 2009-03-14
<rockstar> Wow.  Just, wow.  http://github.com/guides/completely-remove-a-file-from-all-revisions
<Pieter> ool huh
<Pieter> *cool huh
<rockstar> Pieter, I hope you just forgot your sarcasm tags.
<Pieter> no
<Pieter> why?
<rockstar> Pieter, you should never be changing revision data.  Revisions should be immutable.
<Pieter> revisions are also immutable in git
<Pieter> there are valid use cases, like having a plaintext password as the guide says... that's very difficult to do in bzr
<rockstar> Pieter, if you commit a plaintext password, you change your password.
<Pieter> or you just edit it out like in the guide, that's a lot easier :)
<Pieter> there are other use cases, like going public with some code but having to remove some company-sensitive information before publishing it
<rockstar> Pieter, do what launchpad is doing and create a fresh branch.
<Pieter> and then how are you going to remove that info?
<thecookie> I wont have any local history with --no-tree?
<rockstar> There is no info to remove.  It's bzr init.
<Pieter> and loose all your history just because there's some sensitive information in it?
<Pieter> that's kinda lame
<rockstar> Pieter, so you're going through all 100,000+ revisions making sure that EVERY bit of data is clean for the general public?
<Pieter> you don't have to have 100,000 commits ;)
<Pieter> but if you have, say 100, but there are a few files in it you rather wouldn't have public
<Pieter> sure, you do stuff like this
<Pieter> why not? it's easy
<rockstar> Pieter, okay.  You change your revision data.
<Pieter> everybody will thank you for publishing the full history :)
<sohail> one time some people on my team said the team lead was hairy and wrestled bears on his free time
<sohail> the checked that into svn
<sohail> I thought it was pretty funny but when I left the company, removed it :-)
<Pieter> why?
<Pieter> (At first I thought that with 'team' you meant 'baseball team' or something, and then started to wonder why they'd use svn)
<sohail> lol
<sohail> why remove it?
<Pieter> yes
<Pieter> and why remove it when you left?
<sohail> I was still involved but in a more authoritative capacity
<sohail> wanted to make sure that I didn't encourage that type of thing against others
<sohail> I left the company but was consulting sorry if that wasn't clear :-)
<Pieter> ah, right, I was thinking "why would you care?"
<sohail> it's a tricky thing
<sohail> it was actually quite clever
<sohail> the person responsible checked it in as a Python pickled. should have saved it.
<jkakar> Is there an equivalent of 'bzr cp SRC DEST'?  I want to copy a file and make changes to it with its own history, after the copy, but if possible, to capture that a fork occurred.
<Peng_> jkakar: No.
<jkakar> Peng_: Thanks.
<Peng_> Sorry. :\
<glyph> jkakar: wow
<glyph> jkakar: what an odd omission!  I must be really good about not duplicating code, since I've never needed that :)
<Peng_> glyph: Heh. One use is when splitting a file into two. OTOH, I suppose if you organize your code well enough from the beginning, you won't need to..
<glyph> Peng_: I can definitely see uses for it
<jkakar> glyph: Heh.  I'm implementing a new skin and want to use the CSS file from an existing skin as the base for the new one.
<BasicPRO> Anyone know what's going on with launchpad? After gw0-0-gr.canonical.com latency skyrockets for me
<Peng_> BasicOSX: WFM. Is it still happening to you?
<Peng_> (Just trying launchpad.net.)
<BasicOSX> Peng:  yes, semi-intelligent discussion about it on #launchpad
<Peng_> BasicOSX: Oh, right.
<AfC> Hooray for distributed revision control systems and not depending on a single point of failure like that.
<wgrant> I'm not sure that bazaar.launchpad.net is actually broken.
<BasicOSX> $  bzr branch lp:bzr
<BasicOSX> bzr: ERROR: xmlrpc protocol error connecting to https://xmlrpc.edge.launchpad.net/bazaar/: 503 Service Temporarily Unavailable
<wgrant> Ah, forgot about the XML-RPC server.
<Peng_> Heh.
<wgrant> But using bzr+ssh directly might well work.
<BasicOSX> I'd prefer not to step out of the documented and trusted release procedure :-)
<Peng_> Eh, nothing will go wrong if you do. Probably. :-D
<LKRaider> question: can I branch a launchpad project to my local machine, and bind that branch to a hosted launchpad project on my account, so that when I bzr update, it retrieves from the original trunk and bzr commit sends to my hosted project?
<LKRaider> I was trying it like this:
<LKRaider> bzr init
<LKRaider> bzr branch lp:project
<LKRaider> bzr branch project mybranch
<LKRaider> cd mybranch
<LKRaider> bzr push lp:~(account)/project/mybranch
<LKRaider> bzr bind lp:~(account)/project/mybranch
<BasicOSX> I think you just want to do a bzr push --remember your-repo
<LKRaider> without the bind command?
<RexEast> Hi! I'm new to Bazaar (and version control in general), and am looking to find whether this tool is suited to my project. I'm working on a Django project solo. I would like to run the public version of my web app on mysite.com, and meanwhile be working on new features on mysite.com/test. Once I've tested a new version, I want to be able to update the main version with my development branch. What would be the simplest way to d
<RexEast> By the way, for more context, the precursor to this question is here: http://stackoverflow.com/questions/625256/how-do-i-run-one-version-of-a-web-app-while-developing-the-next-version
<LKRaider> btw, uncommit rocks :)
<BasicOSX> LKRaider:  sorry only 20% here, monitoring the outage on launchpad
<LKRaider> oh, yeah, launchpad comes first :)
<LKRaider> I believe the --remember flag is what I want. testing right now
<RexEast> (...alternately, let me know if another tool like SVN would be better suited for this task. Someone originally recommended SVN to me but I figured bzr could do it as well.)
<BasicOSX> RexEast:  I use bzr under turbogears and works very well, use a similar strategy, except I have a production server and development server
<LKRaider> BasicOSX: doesnt seem to work as I want it. if I do bzr update, it returns as up-to-date, even tho I have branched from a middle revision from the original trunk
<BasicOSX> LKRaider:  after you branch don't do update to merge
<BasicOSX> bzr merge --remember upstream
<BasicOSX> make changes
<BasicOSX> bzr push --remember your-repo
<RexEast> @BasicOSX: neat! How would I get started with something that works like yours? Note: I don't need separate servers; this is a very small-time operation for now. The dev version can be on the same server as the production version.
<BasicOSX> RexEast:  create your dev repo, then bzr push it to a central area
<BasicOSX> Then bzr branch from the central area into your production
<BasicOSX> work all you want in your dev repo. bzr committing as you wish
<BasicOSX> when happy with the work, bzr push dev to central area
<BasicOSX> then bzr merge in your production
<BasicOSX> If you have to tweak things in product, just bzr commit and push to a different report if need be, at least that is how I do it
<BasicOSX> There is probably some way if doing series and whatnot, but what I do is pretty simple
<RexEast> Thanks! I'm going to read over that for a minute and try to figure out which commands I'd use to set that up on my Linux box.
<LKRaider> BasicOSX: thanks, your idea seem to work fine for me now :)
<LKRaider> can I use bzr bind, after the push, so that commits go to the hosted branch automatically? or would that break something?
<RexEast> @BasicOSX: why do I need to have the central area? Couldn't I just push my changes directly from my dev repo to the production server? (Sorry, I'm new to all this :)
<BasicOSX> generally there's a few difference between production and development, like what database or tables you use, debug, logging, etc. The split allows for both code bases to live in the central area but branches to live in production and development
<BasicOSX> My reasons for it are more simple, I was my repository on a different box so have code in multiple places incase hardware crashes and burns
<BasicOSX> also production has live access to the Internet, development restricted access, still to the Internet, I put my repo that is not on the box incase there is a compromise
<adelie421> Anyone free to help a noob? Do I need to register a branch before I use bzr send -o foo.patch?
<adelie421> I am feeling a bit overwhelmed here trying to properly submit a patch. I have been following http://doc.bazaar-vcs.org/latest/en/mini-tutorial/index.html
<LKRaider> I think this will create a patch file that you'll have to email to the upstream project somehow
<LKRaider> if you are using launchpad, there is a merge button that you can use to request your branch to be merged on the parent trunk
<LKRaider> but I am a noob too :P
<Peng_> adelie421: If your branch is public, it would be easier to say "hey, merge my branch at http://whatever"..
<Peng_> adelie421: But no, you don't need a public location when using "bzr send".
<Peng_> adelie421: You should make sure the public_branch is set properly on your copy of the target branch, though.
<adelie421> Peng_: sorry, was afk. So wanted to fix some bugs in example-content. I used bzr branch (site), bzr merge, added my pieces, then bzr add, bzr commit -m "details", bzr send -o details.patch. it uploaded and said successful. Thats it, right?
<BasicOSX> lifeless:  ping? Did you PQM 1.13-cherrypicks?
<Peng_> adelie421: ...More or less, probably.
<Peng_> adelie421: It's good to have the proper public_branch value set, to make it easier for people merging it.
<Peng_> adelie421: I'm not sure if that would happen automatically or not.
<adelie421> I got an email from the maintainer seperately, so hopefully they will let me know if I did id right. I figure given the time I should just take a break for now and follow up on that tomorrow
<savvas> hello, does anyone know how to set a server-side variable in bzr branches?
<savvas> specifically: cia_project = timekpr
<savvas> ( in .bzr/branch/branch.conf )
<LarstiQ> mtaylor_: r4142 of bzr.dev looks like it might adress our push problem
<SamB> man, I wish there was a MIME registration for diff-style patches :-(
<jelmer> SamB: bzr-gtk registers bzr-handle-patch for one of the mime types I think
<SamB> hmm, three different types
<SamB> mime_types=text/x-diff,text/x-patch,application/x-bazaar-merge-directive
<LarstiQ> Spaz: saw http://bazaar-vcs.org/BzrFileCopieshttp://bazaar-vcs.org/BzrFileCopies ?
<LarstiQ> Spaz: the last one being what `bzr send` produces
<pigmej> hmm
<pigmej> how to get touching revisions for file
<pigmej> not a file_id ?
<pigmej> for file_id there is method
<pigmej> log.find_touching_revisions(branch, file_id)
<pigmej> how to do the same but without file_id ?
<pigmej> or how to generate file_id ?
<pigmej> I know only revtree.inventory.revision.path2id(file_path)
<jelmer> pigmej, in order to find the file id for a particular path, you need to retrieve the inventory first
<pigmej> jelmer: right, but I'm looking for touching revisions...
<pigmej> so I don't know with inventory is correct...
<pigmej> I need to make "list of revisions for file"
<jelmer> pigmej, that sounds like a chicken-egg problem
<jelmer> pigmej, in order to refer to a particular file you need to find its file id
<jelmer> pigmej, since there may be different files with the same name in different revisions
<pigmej> jelmer: but not the same file path
<jelmer> pigmej, yes, with the same file path
<jelmer> pigmej, e.g. if you have a revision in which path "foo" exists
<pigmej> jelmer: right... delefe, add and that's it...
<jelmer> then the next revision could rename "foo" to "bar" and add a new file "foo"
<pigmej> Yes you're right jelmer..
<jelmer> the fileid of "foo" would stay with the original file
<jelmer> and the new "foo" that is added would have a new file id
<pigmej> So, I need to rewrite one class... :)
<pigmej> To avoid problems with renamed files ;)
<pigmej> jelmer: thanks I forgot about that possibility :d
<Spaz> <LarstiQ> Spaz: saw http://bazaar-vcs.org/BzrFileCopieshttp://bazaar-vcs.org/BzrFileCopies ?
<Spaz> <LarstiQ> Spaz: the last one being what `bzr send` produces
<Spaz> LarstiQ, hadn't heard of it
<Spaz> hm.
<LarstiQ> Spaz: oh bah, I tab-completed wrongly on that second line
<LarstiQ> Spaz: the first was for you though :)
<Spaz> hm ok
<LarstiQ> SamB: in case you didn't get it at the time, the `bzr send` comment was supposed to be direct at you ;)
<LarstiQ> Spaz: anyway, it seems Ian is looking at it recently
<Spaz> hmm
<LarstiQ> Spaz: so providing feedback/coordinating with him seems like the thing to do
<Spaz> i could do that
<Spaz> unfortunately, i'm moving atm. will be semi-difficult for a week or so.
<LarstiQ> Spaz: that's fine, I'll bother you again in a weeks time :)
<Spaz> i'll find time still
<Spaz> :p
<cody-somerville> I've tried to make my repository smaller by using bzr pack and bzr reconcile but instead it made it over three times bigger (its now at 3.2GB).
<Peng_> cody-somerville: Right. "bzr pack" doesn't make it much smaller. However, it *does* create a complete backup of the entire repo. :D
<cody-somerville> joy
<cody-somerville> how do I delete that?
<cody-somerville> is there a bzr clean ? :P
<Peng_> cody-somerville: Well, the backup is created for a reason: so if you lose power before the new pack hits the disk, you won't lose your repo.
 * cody-somerville nods.
<Peng_> cody-somerville: rm .bzr/repository/obsolete_packs/* (but *don't* delete the directory itself!)
<cody-somerville> Peng_, okay, so that brings it down to 1.6GB
<cody-somerville> what is launchpad/.bzr/repository/upload ?
<Peng_> cody-somerville: Temporary storage while creating new packs (e.g. when running "bzr pull" or even "bzr pack").
<cody-somerville> It is 647M and I'm not doing either.
<Peng_> cody-somerville: If there are any six-month old files in it, bzr probably crashed during the middle of a pull and didn't clean up for some reason.
<Peng_> cody-somerville: I'm sure it's safe to clean it out, but I've never done it, so don't sue me if something goes wrong... :P
<cody-somerville> There seems to be a lock file in there so I'll leave it be for now
<LarstiQ> BasicOSX: http://pqm.bazaar-vcs.org/ for the current queue
 * LarstiQ falls asleep
#bzr 2009-03-15
<gioele> hello
<gioele> is "public location for branch XXX" a synonym for "public branch for branch XXX"?
<LarstiQ> gioele: context?
<gioele> LarstiQ: lp-open
<LarstiQ> gioele: yeah
<gioele> can we say that in general "{push,pull,public,parent,bound} location" and "xxx branch" have the same meaning?
<LarstiQ> gioele: branches are usually addressed by their location/url. The two aren't exactly the same things (in bzrlib one is a str, the other a Branch)
<LarstiQ> gioele: but that's semantic nitpicking
<LarstiQ> gioele: for the bzr cli, yeah, that should be the case
<LarstiQ> gioele: location of the {push,pull,public,parent,bound} branch
<gioele> what is the purpose of the 'submit location'. What is the submit branch used for?
<gioele> I jot down my findings at http://bazaar-vcs.org/Locations Thoughts?
<LarstiQ> BasicOSX: replied to your mail
<BasicOSX> ok
 * LarstiQ goes to bed
<BasicOSX> haven't gotten your email :-)
<LarstiQ> BasicOSX: basically, the failure is harmless, don't let it block 1.13
<BasicOSX> ok
<LarstiQ> BasicOSX: ok, good luck :)
<lifeless> BasicOSX: no I didn't do the cherrypicks, I was offline - sorry
<BasicOSX> I got it, good lesson to learn, wasn't sure how PQM worked, but figured it out, just putting the finishing touches announcements
<lifeless> BasicOSX: cool
<BasicOSX> IRC op please update the /topic to 1.13 release 15 Mar
<BasicOSX> Thank you
* lifeless changed the topic of #bzr to: Bazaar version control system | 1.13 released 15 Mar | http://bazaar-vcs.org | http://irclogs.ubuntu.com/ | http://planet.bazaar-vcs.org/
<cody-somerville> Is it possible to selectively revert revisions?
<cody-somerville> ex. revert changes that occurred revision #3
<cody-somerville> oh bloody hell, my nose is bleeding again. brb.
<spiv> BasicOSX: thanks for the release!
<BasicOSX> I aim to please
<BasicOSX> I also jabber to please
<mwhudson> yay bzr 1.13
<lifeless> spiv: shall the two musketeers ride today?
<spiv> lifeless: sure.  Alright if I head down to Epping?
<lifeless> sounds great
<jfroy> yay!
<cammoblammo> I'm sure I'm missing something... How do I install bzr (from source) to /usr/local/bin instead of /usr/bin ?
<BasicOSX> pretty much anywhere you want it installed
<BasicOSX> Just need to make sure bzr is in your path
<BasicOSX> I put it into /usr/local/share/ and symlink /usr/local/bin to /usr/local/share/
<BasicOSX> meaning I symlink /usr/local/bin/bzr to /usr/local/share/bzr.dev/bzr
<cammoblammo> How do I tell it where to go though? By default it goes into /usr/bin
<BasicOSX> From tarball?
<cammoblammo> From the bzr repo.
<BasicOSX> how are you getting it from the repo?
<BasicOSX> don't understand if you don't have bzr installed how are you getting bzr from a repo?
<cammoblammo> I pulled http://bazaar-vcs.org/bzr/bzr.dev/ and update it once in a while with bzr pull.
<BasicOSX> Just mv the bzr.dev to where you want it to live
<lifeless> cammoblammo: are you running setup.py ?
<cammoblammo> Yes.
<lifeless> cammoblammo: setup.py install --home=/usr/local
<lifeless> cammoblammo: BasicOSX is talking about an alternative where you don't really install it; just run 'make' and then symlink $(src)/bzr into your path somewhere
<BasicOSX> yes, I am, sorry
<Peng_> I use --prefix, not --home. :O
<cammoblammo> Ah. I thought it'd be something like that. There isn't somewhere I can set it permanently?
<lifeless> Peng_: either is fine, I think.
<lifeless> cammoblammo: not as far as I know
<cammoblammo> Oh well, I can live with it. Thanks for your help folks!
<cammoblammo> Hmm. Is there a setup.py uninstall command?
<lifeless> No ><. setup.py is a poor replacement for packaging [there are packages of bzr for most platforms..]
<cammoblammo> Yeah, Debian took too long to give me something recent. I can use the --record option on install and use that to delete what doesn't need to be there.
<jml> I'm reading my notes from last week
<jml> and I've got one that says "Gotchas w/ progress reporting in bzr 1.13"
<jml> does anyone have a clue what I meant? :)
<lifeless> yes, I do
<lifeless> bzr 1.13 does much less ('no') progress reporting during large fetches, instead the network activity reporting is the whole thing
<jml> lifeless: but it still does fairly granular activity reporting, right?
<lifeless> jml: I don't know what you mean
<lifeless> so perhaps I can phrase it differently
<lifeless> a local-disk new clone operation will output perhaps 1 seconds worth of progress bar stuff right at the start, then nothing until the tree building at the end
<lifeless> a over the network new clone will output perhaps 1 seconds worth of progress bar stuff at the start, and then the network activity when data is being read/written to the network, then the tree building progress bar at the end
<lifeless> fin
<lifeless> does anyone know who yoboy is?
<Peng_> BasicOSX and everyone else: Congrats on the release. :)
<lifeless> igc: you can move bugs by clicking on the status, and then typing in a new product in the box
<igc> lifeless: sure
<lifeless> igc: :P - perhaps I was wrong to move that bug to qbzr that you'd closed?
<igc> lifeless: And you're reminding me because?
<lifeless> igc: because I thought you closed something that was better moved
<igc> lifeless: I closed it because the person raising it wasn't sure how to close it
<lifeless> erm syntax, because you closed something I thought was better moved
<lifeless> ah
<lifeless> my bad
<igc> lifeless: ah - ok
 * lifeless is a little twitchy on bugs today, after an unknown marked four unrelated surface-related-unicode bugs as dups
#bzr 2010-03-15
<sivang> just wanted to say thanks to bzr.
<sivang> it enabled me to pull from qt.gitorious when git itself cannot.
<lifeless> lol, nice
<sivang> lifeless: :)
<sivang> lifeless: ah, but how do I use the git plugin? in svn it works ootb
<sivang> odd, I've done that already and forgot...
<sivang> ahh stupid git
<sivang> why can't everybody just use bzr...life would be so much simpler.
<luke-jr> dunno, I kinda like git
<luke-jr> but I use both
<sivang> luke-jr: so it was me who was stupid
<sivang> luke-jr: s/http/git/
<sivang> luke-jr: can't expect every DRCS to do hg/bzr guggling of urls.
<sivang> anyway, back to hacking
<thumper> lifeless: do you know if there are any presentation on the bzr wiki that are up to date(ish) that I can base my talk on?
<duckx_> Hello
<poolie> hi duckx_
<duckx_> I was wondering what was the current state of nested trees in bazaar
<poolie> i'd recommend you use the bzr-externals or scmproj plugins
<poolie> see the plugin guide
<duckx_> Ok I will have a look, thx
<duckx_> I played with bzr-loom this WE
<duckx_> Nice plugin, very easy to use
<duckx_> Well I tried to find out what could be the best Workflow to get debian python-modules in sync in ubuntu
<duckx_> Using the debian repository ;)
<duckx_> That is using svn with merge mode ...
<duckx_> That fun,  make me play a lot with bzr
<duckx_> Thx poolie
<duckx_> I will see what I can do with bzr externals
<igc> hi poolie
<poolie> hi there
<thumper> poolie, igc: I'm looking for a big bzr image for my presentation
<thumper> know where to find one?
<poolie> meaning a big screenshot?
<thumper> igc: how are you feeling today?
<thumper> poolie: just the bzr image for the slide master background
<igc> hi thumper - I'm ok today thanks
<poolie> the logo?
<thumper> igc: up for a skype call?
<thumper> poolie: yes
<igc> thumper: sure
<igc> thumper: let me fire up my laptop first
<thumper> poolie: we should have links to the images somewhere of the front web page I reckon
<thumper> s/of/off/
<igc> thumper: http://wiki.bazaar.canonical.com/LogoOptions
<igc> thumper: I have Skype up but it doesn't think you're online
<duckx_> poolie, thx again
<duckx_> the externals plugin was exactly was I was looking for !
 * duckx_ : my  english is really crappy today
<AfC> So, someone just asked me if there was a continuous integration server that integrates nicely with a DVCS (bzr, obviously)
<AfC> I know lifeless was playing with Hudson recently, but I don't know whether that was Canonical internal, or a customer of theirs, or...
<lifeless> we're using hudson at canonical
<lifeless> for bzr (vila's test environment - I think he posted a url to it), for some dx stuff (internal builds - not public)
<lifeless> drizzle use hudson, its where I was introduced to it
<poolie> igc is bug 537387 something that was fixed in a later installer?
<ubottu> Launchpad bug 537387 in bzr "Bazaar crash on update of (bzr-svn) checkout" [Undecided,New] https://launchpad.net/bugs/537387
<poolie> it looks familiar
<igc> poolie: he's using the latest installer already
<igc> poolie: it certainly includes the latest explorer
<igc> poolie: maybe the problem is fixed in 2.1.1 or a more recent bzr-svn?
<sili> Is it possible to mirror repositories?
<lifeless> yes
<dcoles> Is bzr git-serve part of the bazaar package these days?
<dcoles> I just noticed the 'server' module in the git plugin and was trying to see how it worked.
<lifeless> dcoles: I'd expect it to hook into 'bzr serve --protocol='
<dcoles> Ah! I misread the wiki page
<dcoles> Yes, `bzr serve --git` will do it
<poolie> lifeless: your thoughts wanted on bug 185211
<ubottu> Launchpad bug 185211 in bzr "renaming out of directory with unicode name fails with InconsistentDelta" [High,Confirmed] https://launchpad.net/bugs/185211
<lifeless> poolie: well, looks like I created a shell demo for it
<poolie> yes, it's fine as an open bug
<poolie> if that's all it is that's fine
<poolie> i just wondered if you knew more about it than is described there
<lifeless> ENOENT :P
<poolie> also, does https://bugs.edge.launchpad.net/bzr/+bug/337455 look like something that might have been fixed with bug 397705?
<ubottu> Launchpad bug 337455 in bzr "Unexpected error message about inconsistent delta ." [Undecided,New]
<ubottu> Launchpad bug 397705 in bzr "inventory delta consistency checks are missing known problems and not universally applied." [Critical,Fix released] https://launchpad.net/bugs/397705
<lifeless> no
<lifeless> I suspect dirstate corruption there, but we should have fixed that too.
<lifeless> I'd be fine with closing it as 'we think it works now'.
<spm> igc: and others. bzr-explorer? <3 that is all. :-)
<RAOF> How do you spell âbzr missingâ in git? :/
<mwhudson> apt-get install bzr-git ? :)
<RAOF> You'd make me a happy man if you could tell me that (a) that now has some way to specify non-master branches, and (b) I can use it on the kernel tree :)
<bob2> 'git log origin/master...' or so
<mwhudson> for (a) ah, um, for (b) i think revgraph stuff /might/ be ok on the kernel?
<RAOF> bob2: Imagine, if you will, that there are some 6400 commits in the last couple of weeks of git history :)
<RAOF> Hm.  I think I want âgit branch --containsâ.  That's not totally insane.
<stewart> hi! how dho i recover from BranchInTheWay when using pipes? basically, i want to overwrite whatever is on launchpad (because it is wrong)
<lifeless> stewart: I don't know. delete the one on lp perhaps?
<stewart> lifeless, trying... had fail because of that in the past...
<stewart> lifeless, now get a "Not a branch" error.
<bob2> RAOF: pretty sure it will find all unmerge commits
<bob2> (note /3/ dots)
<RAOF> bob2: Oh!  I thought that was an elipsis, rather than a part of the command.
<bob2> ah
<RAOF> That's impressively arcane.  Makes up for git branch --contains!
<igc> spm: ?
<igc> spm what does <3 mean?
<spm> igc: <3 == is love :-)
<lifeless> its a heart
<lifeless> turn your heard to the right
<lifeless> or your screen to the left
<igc> aha
<igc> spm: thanks!
<spm> igc: for someone (me) who spends all day staring at grey text on a black screen in consoles; a gui that makes life easier on less used tasks is a truly *wonderful* thing. magic stuff!
<igc> spm: I'd love it more myself if it stopped crashing all the time. One day soon I really need to fix that
<spm> ha. obvioulsy I haven't hit a crash yet. I'll revise my love for the tool and send a hate message when that happens
<stewart> lifeless, but then, if i go to launchpad and create the branch... i get the "Not a branch" error still. if i push into that branhc, i get the BranchInTheWay error. so it seems that i'm a bit screwed...
 * stewart notes this wouldn't happen with quilt.
<stewart> lifeless, so tried to avoid syncing that pipe.... by adding a new pipe (with a new name) and removing the old one. I still get the "not a branch" error. so there's something on LP.... any idea what? or how?
<stewart> hrm.. ~/.bazaar/pipeline-cachedir can go away.... let's hope that does something.
<stewart> wtf...
<poolie> stewart: i think you'll find the config inside .bzr/branch/branch.conf
<poolie> you can break the pipeline there probably
<stewart> poolie, i'm getting "bzr: ERROR: Not a branch: "bzr+ssh://bazaar.launchpad.net/~stewart-flamingspork/drizzle/embedded-innodb-configuration-table-function/"."    yet grepping for "configuration" in .bzr reveals no results
<stewart> i could go and try deleting the 29 branches on launchpad...
<stewart> potentially screwing up everything i have linked to them...
<lifeless> stewart: try grepping in .
<stewart> lifeless, still nothing...
<lifeless> try ~/.bazaar
<lifeless> and try .bzr of the branches you have on lp
<stewart> lifeless, nope. not on my system at all.
 * stewart is not gonig to grep / as that'll probably take 3 hours
<lifeless> reminder: bzr your mai
<lifeless> l
<stewart> lifeless, i'll wait until some point after i can upload my work and propose merge reqs of it...
 * stewart sees what damage deleting all 29 damn branches on lp may cause.
<stewart> not especially nice UI that... 29 times several page loads... urgh.
<stewart> oh wait... there's merge requests with comments on them.
<stewart> now trying deleting the single empty branch... eep.
<stewart> fuck.
<parthm> hello. i was writing some tests for bzr-grep and noticed that some tests were not seen. changing the name from test_something to test_somethingelse made it ok.
<parthm> are there any rules to test naming?
<lifeless> parthm: the function name?
<parthm> lifeless: yes the function name. e.g. "def test_version_something" was not seen. If I changed it to "def test_ver_someting" the test count went up by 1.
<lifeless> parthm: did you perhaps have another function with the same name?
<parthm> lifeless: hmm. could be. i will check again.
<lifeless> parthm: so yes there are restrictions, but both test_version_something and test_ver_something pass the them
<parthm> lifeless: you are right. i think it was duplicate names. does bzr use pyunit or its own test framework. maybe such a thing can be an error?
<parthm> as the number of tests go up (51 in this case) we can end up with duplicates.
<lifeless> parthm: python itself does the compilation
<jelmer> moin lifeless
<lifeless> parthm: and its at that stage that you'd want to catch it.
<lifeless> hi jelmer
<lifeless> parthm: we use a derivative of pyunit
<parthm> lifeless: ok. thanks. i will need to be more careful with the names :-)
<vila> hi all !
<lifeless> hai
<jelmer> hey Vincent
<lifeless> so, lost+found :)
<lifeless> EODing
<vila> lifeless: have a nice evening
<thumper> where are the API docs?
<lifeless> p.c.c/~mwhudson
 * vila @dentist
 * igc dinner
 * vila back
<lifeless> vila: so, lost + found?
<vila> lifeless: hehe, not yet on the top of my TODO graph but I'm targeting the related tests in test_conflicts already
<vila> lifeless: I will also start implementing the basic feature so I can *then* plug it in the right places
<vila> basic feature: moving an unversioned file in some trash with a bare-bones handling and how it was called and when it was trashed (to address the likely collisions)
<vila> lifeless: does a '_trash' method on the wt sounds fine ? (AIUI we need it only for unversioned files right ?)
<lifeless> vila: lost_and_found please, trash is explicitly discarded
<vila> trash (or recycle bin) are more mainstream than lost_and_found IMHO, besides, what is 'lost' in our case ? (found as 'found' in bzr way can fly but requires a bit of explanation
<lifeless> they are diferent concepts
<lifeless> I don't see how one can be a mainstream version of the other
<vila> well, to me, lost+found in the unix way to store... 'garbage' found when errors occurred at the fs level, I don't clearly the connection here,
<vila> I'm fine with not using trash, so maybe 'quarantined' or something ?
<vila> err
<vila> well, to me, lost+found *is* the unix way to store... 'garbage' found when errors occurred at the fs level, I don't clearly *see* the connection here,
<Kamping_Kaiser> i dont like to think of my files as garbage >.>
<vila> Kamping_Kaiser: well, we are talking about files like .pyc, .o etc, as far as versioning is concerned, how would you like them to be called ?
<Kamping_Kaiser> vila: i was refering more to your comment 'lost+found *is* the unix way to store... 'garbage''
 * Kamping_Kaiser heads off
<vila> Kamping_Kaiser: ha, right, well, the ellipsis was intended to carry my lack of precise wording here :) My experience is that the files or directories found in lost_found are not always in good shape :0
<lifeless> vila: so, lost+found in ext* fs's caries files that the filesystem has recovered because they no longer had a directory to belong in.
<lifeless> vila: the connection is that lost+found in a bzr tree would carry files that bzr no longer has a directory to put them in.
<vila> lifeless: wow, yeah in that case there is a 1-1 match, but who knoes that ?
<vila> orphans ?
<lifeless> no value judgement is made about the files - they might be databases or temp files - we don't know
<lifeless> 'trash' is a value judgement
<vila> I got that
<lifeless> orphans would be fine
<lifeless> recovered
<lifeless> lost + found would be bad because folk that do know what it is might think their file system is insane if bzr makes such a dir ;)
<vila> recovered is slightly misleading as there aren't lost today :)
<vila> recoverable ?
<lifeless> uhm
<lifeless> I don't get what you mean
<vila> anyway, I'll outlight all this naming issues in my proposal so we can find a consensus
<lifeless> *foo*-able would imply some way that the user can *foo* files.
<vila> yes, that's the idea
<lifeless> foo-ed or foo-s implies that bzr has done foo for the user, and they can now decide what do to.
<vila> I don;t intend to propose commands for that but at least a naming scheme that allows once to find back these files
<vila> s/once/one/
<vila> there will be cases where an unknwon file was really a not-yet-added but precious file
<vila> but the general case should be that the user can cleanup all of them on a regular basis
<lifeless> indeed
<lifeless> I don't really like recoverable
<lifeless> can't articulate why
<lifeless> recovered I could cope with
<lifeless> or orphans
<lifeless> oh, I suggest a bzr- prefix
<lifeless> bzr-recovered
<lifeless> bzr-orphans
<vila> then I'll start with orphans
<vila> you mean in as a first-level directory in the wt ?
<vila> I thought it will be in .bzr/checkout... but no strong feeling,
<vila> I'm still unclear about how the user should restore from there...
<vila> ...and how to avoid the content growing out of control if it's not noticed...
<lifeless> vila: I don't think we should hide it
<lifeless> it should be in-your-face if this happens, but not in-your-way
<lifeless> and yes, I mean a sibling of .bzr
<vila> hmm
<vila> That makes sense. At least for me, I can imagine I will promptly delete it as soon as I discover it...
<vila> after a quick content check of course
<lifeless> exactly
<vila> So that raises the question of the content naming, reproducing the full relpaths (with some anti-collision scheme added) doesn't look very good, using fully random names requires some way to translate back to a (date, relpath)
<vila> the later requires an additional command (or two)
<vila> namely: list, recover <xxx> <here>
<lifeless> vila: huh, using the full relpath is great.
<vila> lifeless: not if you have tenths or hundreds of them
<lifeless> uhm
<lifeless> I think you're over designing
<lifeless> we expect folk to clean this up regularly and promptly.
<vila> and I'm a bit concerned about max-length paths
<lifeless> we can merge the directories
<lifeless> and we only add len(bzr-orphans) to the max length
<vila> I was thinking about adding yyyymmdd-hhmmss stamps
<vila> but if folks clean it regularly, that may be useless
<lifeless> so don't do that
<lifeless> thats ugly
<lifeless> it would stop people trivially moving them back into place
<lifeless> and the files will have a mtime of their own already if we don't break it
<vila> well, they can't move them back normally since that's why the files end up here in the first place
<lifeless> sure they can
<Peng> Might be good to add an incrementing number to the end of the first directory in the relpath, like with backup.bzr.
<vila> yeah, mtime, good point
<Peng> (Or similar to it, anyway; I don't remember exactly how backup.bzr works.)
<lifeless> we delete the directory - but now we'll preserve the directory in this tree
<lifeless> lastly
<vila> lifeless: right, but AIUI that's why the merge can't complete successfully
<lifeless> I think it might be fine to just overwrite existing files in this dir: if the user has the same precise file generated + not versioned twice, then they very likely are autogenerating it
<vila> or re-create it in which case the last one is as good as the previous one
<vila> yeah, that's certainly sounds like a good first implementation anyway, I'll go that route
<Oli``> Is there an export function that could upload version controlled files up to another location but didn't write any .bzr (et al) files?
<Peng> Oli``: "bzr export" or the bzr-upload plugin if it's remote.
<Oli``> Peng: doh - thank you
<jml> hi
<jml> I got these errors when trying to use --lsprof-file: http://paste.ubuntu.com/395662/
<Peng> jml: Try 'bzr --lsprof-file grep.callgrind' instead of using an =. Maybe it will like that.
<jml> Peng: ahh yes, it does. thanks
<Peng> Global options use really basic parsing. It's like 5 'if' statements.
<Peng> No optparse or anything./
<jml> Peng: good to know, thanks.
<kareeser> hello everybody :)
<kareeser> I'm a bzr newbie... and I have some silly questions to ask... anyone interested in humouring me?
<rubbs> fire away
<rubbs> that's what the channel is for ;)
<kareeser> awesome.
<kareeser> so, I use svn, and am trying out bzr for the first time
<kareeser> whenever I delete a folder in svn, svn treats it as being accidentally deleted, and recreated it on the next update
<kareeser> in bazaar, it treats it as being removed from versioning
<kareeser> is that correct?
<rubbs> if you mean bzr rm filename then yes.
<kareeser> nope...
<rubbs> it will remove it from versioning
<kareeser> just "rm filename"
<kareeser> when I run bzr status, it reports it as "removed"
<rubbs> gotcha.
<kareeser> is this just a byproduct of using bzr-svn?
<rubbs> I could be wrong, but IIRC anything "removed" from the repo is automatically detected by bzr as removed from versioning.
<rubbs> this can be reversed
<rubbs> if you are using bzr with as SVN repo, I'm not entirely sure, but others here are bigger experts with bzr-svn than I am
<kareeser> right.. I thought so
<kareeser> I'm in the process of uploading my code to launchpad anyway, so I probably won't have to use bzr-svn for too long...
<rubbs> btw that wasn't a stupid newbie question ;)
<rubbs> sorry i couldn't answer it with more authority :(
<kareeser> haha... sorry
<kareeser> I guess you were expecting something more along the lines of "what's a checkout?!"
<kareeser> okay, then, answer me this
<kareeser> trunks are branches, yes?
<kareeser> then... branches are not trunks?
<kareeser> the trunk*
<rubbs> haha
<rubbs> best way to look at it is a trunk is just the central focus on where the development will take place
<rubbs> every branch is a copy of that trunk
<rubbs> so you have a branch on your computer, the "branch" you make as your focus/target for others to develop to is the "trunk"
<kareeser> and the trunk is the one hosted on a central server (arbitrarily determined) for others to checkout/branch from?
<kareeser> i.e. Launchpad?
<rubbs> most of the time yes. For our purposes in this example that is exactly correct
<rubbs> any branch can be a trunk. in distrubited version control like bzr "trunk" is more of a social thing than a technical difference
<kareeser> okay...
<kareeser> so when I "pushed" my code onto launchpad... and it called it a branch (both on my computer and on LP)... that's fine?
<rubbs> yes
<kareeser> even if the branch is named "trunk"?
<rubbs> correct
<kareeser> this is all very confusing. :P
<kareeser> I see.
<rubbs> it gets better once you use it a little more
<kareeser> I sure hope so, heh.
<rubbs> bzr makes not technical distinctions between branches and trunks. Most people make the distinction themselves by naming a branch "trunk" like you did.
<kareeser> I see, that makes sense.
<rubbs> LP also helps because you can make the specific branch as the "focus of development"
<rubbs> this tells other LP users that "trunk" is the one to branch from
<kareeser> right
<kareeser> okay, next...
<rubbs> ready
<kareeser> in my app, I have a check in index.php to see if ../install is present. If so, it halts the script and tells the user to go to the install script. Makes sense, I hope.
<kareeser> once the install script finishes, the user is instructed to delete the /install folder.
<kareeser> got the idea from mediawiki, I think...
<rubbs> ok, I'm following so far
<kareeser> anyways, if the user maintained their program using bzr, then wouldn't bzr automatically recreate ../install every time?
<kareeser> basically, I'm asking, the way I designed my program, is it "anti-bzr"? :P
<kareeser> I don't mind having to rely on .tar.gz releases, I'm just wondering.
<rubbs> well, two things to think about with that issue. 1) bzr isn't really designed for distribution of the final product, but most people work around that.
<kareeser> okay, that's what I thought...
<rubbs> 2) there are ways around it but it could require some work from either you or your "customers"
<rubbs> one way I would think about doing it is having a "trunk" for development
<rubbs> and having a "distrubtion" branch
<rubbs> in the distribution branch you pull from the trunk and delete the install directory
<rubbs> that way when people update from the dist branch they dont' get a new install dir every time
<abeaumont> kareeser: to workaround that, suppossing that newer versions never need reinstalling, use a .installed file or similar, instead of removing your dir, bzr will ignore that file
<kareeser> and if development continues in trunk, then distribution is updated periodically?
<abeaumont> (just an idea)
<kareeser> abeaumont, elegant, I like it.
<rubbs> kareeser: yes, but you'd have to do that manually
<rubbs> but I think abeaumont's idea is better than mine
<kareeser> hm..
<kareeser> okay, thanks rubbs, abeaumont, for your help :)
<kareeser> A+.
<rubbs> np.
<abeaumont> you're welcome :)
<rubbs> come back and ask more questions if you have any. most of the time someone knows where to look if they don't know the answer outright.
<kareeser> I only ask, because I do development on three computers, one of which is the actual implementation (with real data)
<kareeser> and with bzr being unfamiliar, I'm afraid I'll accidentally delete the repository with a stray rm command ;)
<dolphinling_> I have some files I need version controlled with filenames that match bzr's default ignore rules. How can I get bzr to not use its default ignore rules?
<rubbs> dolphinling_: I might not remember this right, but there should be a global config file you can edit. What system are you using?
<rubbs> er Operating system I meant
<dolphinling_> gentoo linux
<rubbs> k... just as sec. I'm going to check before I tell you the wrong thing ;)
<dolphinling_> All right, I'm searching through system dirs to see if I can find this file
<dolphinling_> rubbs: heh, I found it, it's ~/.bazaar/ignore
<rubbs> ah, ok, sorry
<rubbs> I thought there was a global one too
<rubbs> but I could be wrong
<dolphinling_> This is fine for me.
<dolphinling_> I wish there were some way to just override it rather than editing it, but oh well.
<rubbs> dolphinling_: I'm sure there probably is, I'm just not remembering it right now
<IslandUsurper> dolphinling_, you should be able to just bzr add specific_filename
<IslandUsurper> of course, that's only useful if you have only a few of those files to unignore
<fullermd> 2.1 and later have support for negative ignore patterns.
<fullermd> It's definitely better to not edit the builtin ignore if at all possible.  That tends to have unpleasant knockon effects down the line.
<IslandUsurper> I have a website that I've been updating with bzr-upload, but I've recently gotten shell access. Is there a clean way to convert that folder into a branch without having to reconstruct all of those files again?
<IslandUsurper> maybe I should say, without having lots of conflicts that would disrupt the working of the site
<fullermd> I don't know, but I doubt it.
<fullermd> I can think of some unclean ways that might work.
<IslandUsurper> I've thought about making a new branch, doing one commit, and then pull --overwrite
<IslandUsurper> if the file content is the same, no one outside should notice...
<fullermd> If what you've uploaded is exactly what's in the branch, you could try making a throwaway branch somewhere, transplanting its .bzr/ over to the location, and seeing what 'stat' etc have to say.
<IslandUsurper> yeah. but I've read that Bzr compares file IDs first, and those will probably be different, especially for the directories
<fullermd> How?  The existing files from upload don't really ahve id's.
<fullermd> ID's are an internal bzr thing, they don't exist in the filesystem.
<IslandUsurper> hmm. ok
<IslandUsurper> I'll give that a shot then
<barry> hi folks.  i have a question about bzr-pipeline.  is it known/expected that renaming the top-level directory breaks the pipelines?
<fullermd> barry: Absolute paths used in cross-references?
<barry> fullermd: dunno.  it was weird though.  when i moved the dir back to its original name, the pipes below it showed up again (phew! :)
<mwhudson> jelmer: ping?
<mwhudson> another inconsistent sha bug :( https://code.edge.launchpad.net/~vcs-imports/fetchmail/master
<rbriggsatuiowa> I am having problems with bzr unshelve - i just get a dump of bzr metadata with the following error at the top
<rbriggsatuiowa> bzr: ERROR: The file id "workflow.html.erb-20100305150443-x3ac2am7beykb5dz-1" is not present in the tree
<rbriggsatuiowa> https://bugs.launchpad.net/bzr/+bug/253806 is the problem I am having
<ubottu> Launchpad bug 253806 in bzr "bzr: ERROR: The file id "foo-20080731224042-7ogu3b3hk0bwnpo3-1" is not present in the tree" [Medium,Fix released]
<rbriggsatuiowa> ubottu: any idea what release?
<ubottu> Error: I am only a bot, please don't think I'm intelligent :)
<rbriggsatuiowa> 1.13 it looks like
<rbriggsatuiowa> sigh - way to fail the reverse turing test
 * rbriggsatuiowa heads off to try a newer version of bzr
<jelmer> mwhudson, looking
<mwhudson> jelmer: i filed a bug btw
<jelmer> mwhudson, ah, merci
<parthm> hello. for bzr-grep, i am seeing UnicodeDecodeError while printing the output. whats the recommended way to handle this? http://pastebin.com/x7TLnMAV
<mwhudson> jelmer: the question of the uber-slow kernel import came up again in the stand up
<mwhudson> jelmer: do you know why it's as slow as it is?
<jelmer> mwhudson, one part of it is the indexes
<mwhudson> oh, the using bzr indexes thing?
<jelmer> mwhudson, s/indexes/cache/
<jelmer> mwhudson, yeah
<jelmer> mwhudson, that's about 25% I suspect; not sure how the other part could be optimized, we'd have to do performance analysis first
<mwhudson> jelmer: do you have any idea why the kernel is so much slower than everything else?
<mwhudson> just because it's a really big tree?
<jelmer> mwhudson, yeah, the size of the tree
<mwhudson> jelmer_: https://code.edge.launchpad.net/~vcs-imports/iso-codes/master failed in the same way :(
<ubuntujenkins> how do i slve this? bzr commit bzr: ERROR: Could not acquire lock "/home/luke-jennings/Projects/ubuntu-manual/.bzr/checkout/dirstate": [Errno 11] Resource temporarily unavailab
<ubuntujenkins> *solve
<kfogel> lifeless: ayt?
<lifeless> hai
<lifeless> ubuntujenkins: is that a fuse mount or something?
<lifeless> kfogel: hai
<ubuntujenkins> I did a bzr commit and exited badly which caused it.
<kfogel> lifeless: hey, so I'm trying to test out some of your recommendations for bzr+ssh in the proposed savannah.gnu.org setup.  If you have some time, I'd love your help -- I think I'm stumbling on perhaps basic ssh configuration issues.
<lifeless> ok
<lifeless> shoot
<lifeless> ubuntujenkins: what does fuser /home/luke-jennings/Projects/ubuntu-manual/.bzr/checkout/dirstate show?
<kfogel> lifeless: so I'm testing out your first recommendation: (one sec, I'll paste)
<kfogel> lifeless: this one: http://paste.ubuntu.com/395841/
<ubuntujenkins> lifeless nothing
<kfogel> lifeless: what I'm first trying to do is get the 'command="foo"' option working at all -- I just want to see it have an effect.
<kfogel> lifeless: so I've created a user ~jennifer on my machine, and given her a ~/.ssh/authorized_keys file, and put a new authorized key in there like this:
<kfogel> command="/bin/echo fish" ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAzvPivbVMjyzQTwEhCVuD+WinVw8rhIKY5k3PzH7HxFtarXZH/NAPkvYqDhKG0iJnHoxGIY5K6Of1V+D77+5Lyd+FtdRNneT4OATLDI/gRGWmrIJhYJr7Ag3eeVBjMZBsC6ty/jMAiBUfWs5GxF3ajKgwo4nZmbVJjEKwBmunFeoO7295qve++tgF8isDUwaZmpKwOr/Rxe8eJYmdbOHqOAu0dwnDNIf45daUurqlJaounjQVkrgLDQ/xLoNE2WnXfnAFmsNUF48acrXWeP6D3+fqh6HgnDttR6mbPY5ZxZx9jlTl1d/FkJZLaCUjDJbtOr3vaBxD69TRm6cDAJxfLQ== kfogel@kfogel-work
<lifeless> ubuntujenkins: thats odd
<kfogel> lifeless: then I substituted the corresponding (new, temporary) private key for my own ~kfogel/.ssh/id-rsa
<ubuntujenkins> hang on i know
<kfogel> and did 'ssh jennifer@localhost'
<kfogel> lifeless: and the result is that she just logs in successfully.  Not what I was expecting :-).
<kfogel> lifeless: am I doing something wrong, perhaps?
<ubuntujenkins> nope nothing, I think it would be quicker to copy the chnages to a new branch
<lifeless> ubuntujenkins: I hate to ask this in a unix environment, but have you tried a reboot?
<ubuntujenkins> nope I will be back
<stewart> abentley, hi! i'm having pipeline issues
<lifeless> kfogel: so the limit is per key
<lifeless> kfogel: do you have more than one key, or more than one authorised keys file?
<kfogel> lifeless: nope.  that's the only authorized key in the file
<kfogel> in ~jennifer/.ssh/authorized_keys, that is
<abentley> stewart, what's the issue?
<stewart> abentley, i think i need a --overwrite to sync-pipeline. as i've managed to get into a situation where the trees on lp reference a pipe that i don't have, and deleting the branch doesn't work.
<lifeless> kfogel: ok. does -vvv give any hints?
<kfogel> lifeless: not to my untrained eye, but let me take another look (and I'll paste if I don't see anything obvious)
<abentley> stewart, yes, sync-pipeline only adds pipes, never deletes them, because it can't tell whether a discrepancy is because side A added a pipe or because side B deleted it.
<ubuntujenkins> no difference lifeless
<stewart> abentley, so on sync-pipeline i get "Not a branch" for a pipe that used to exist.
<stewart> abentley, any way to override it....
<lifeless> kfogel: it works for me
<lifeless> kfogel: I bet you either have an authorized_keys2 file, or two keys in the same file
<abentley> stewart, there's nothing built in for that.  You'd need to edit the branch.conf file in the neighbour branches to fix it.
<lifeless> $ ssh localhost
<lifeless> foo
<lifeless> Connection to localhost closed.
<stewart> abentley, and that'd be on launchpad, as there is no reference to this pipe locally (grepped *everywhere*)
<abentley> stewart, correct.
<stewart> abentley, could i delete a few of the branches around it on launchpad and that would fix it?
<abentley> stewart, I think you'd need to delete all of them.
<stewart> abentley, hrrm.... all of them is problematic... there's 29 of them, and there's many links to merge requests, blueprints, bugs......
<lifeless> ubuntujenkins: oh
<abentley> stewart, perhaps you're thinking it's not possible to edit a branch.conf on Launchpad?
<lifeless> ubuntujenkins: run whatever is failing with '-Derror' you should get a backtrace
<kfogel> lifeless: definitely only one key in the authorized_keys file, and no authorized_keys2 file, but I think I see the problem (http://paste.ubuntu.com/395844/).  The fact that I was being prompted for a password (!) seemed wrong, and it looks like ssh is not reading the file as rsa2...
<lifeless> ubuntujenkins: pastebin that, we can look at it
<kfogel> lifeless: I mean, i should not get a password prompt, right?
<lifeless> ubuntujenkins: also, please include the output of 'mount'
<lifeless> kfogel: right, you want password auth disabled
<stewart> abentley, how do i do that?
<lifeless> kfogel: -v will have told you, but - chmod 0700 .ssh, chmod 0600 .ssh/keyfile
<abentley> stewart, you can use an sftp client or lp:hitchhiker
<ubuntujenkins> lifeless: I am quite happy to carry on if it interests you but I am quite happy to copy stuff to a new version of the branch. You seem like a busy person
<lifeless> ubuntujenkins: we should find out whats happening, so we can fix or document it
<kfogel> lifeless: in ~kfogel/.ssh ?
<stewart> abentley, let me try...
<lifeless> kfogel: yes
<ubuntujenkins> no problem I will get the information for you lifeless
<lifeless> kfogel: it will have said 'key foo has inappropriate permissions, ignoring' or something like that
<kfogel> lifeless: already are that way
<lifeless> kfogel: or, you haven't added the key to your agent - ssh-add .ssh/filename
<lifeless> or pass -i .ssh/filename when you invoke ssh
<kfogel> lifeless: note that's not in the -v output (see paste)
<kfogel> lifeless: ah, didn't know about -i, I'll try it
<kfogel> lifeless:  when you say .ssh/filename, you mean the private key?
<lifeless> yes
<kfogel> for kfogel, that is?
<lifeless> the one for jennifer
<kfogel> well, I'd already substituted it for my normal id_rsa
<kfogel> it is the standard filename right now
<kfogel> lifeless:  and it's chmod 600
<kfogel> too
<lifeless> I'd put it back to a different name TBH
<lifeless> could be caching effects
<ubuntujenkins> ok after the reboot lifeless the only error occurs with bzr commit the error and the output of mount is here http://paste.ubuntu.com/395847/
<lifeless> ok, thats a different error
<kfogel> lifeless: on phone, one sec
<abentley> stewart, I have to go, but you can email me if you get stuck.
<lifeless> you can run 'bzr break-lock' to fix that one
<ubuntujenkins> lifeless I did bzr break-lock but I now get this error http://paste.ubuntu.com/395849/ wehn doing bzr commit
<lifeless> this is really strange
<lifeless> we're calling fcntl.lockf(self.f, fcntl.LOCK_SH | fcntl.LOCK_NB)
<lifeless> where self.f is an open file on /home/luke-jennings/Projects/ubuntu-manual/.bzr/checkout/dirstate
<lifeless> do you have a view defined ?
<ubuntujenkins> whats a view?
<lifeless> ok, you don't ;)
<ubuntujenkins> cool
<ubuntujenkins> I guessed you were not talking about the one out of my window :-P
<lifeless> can you run '
<lifeless> 'fuser -ki /home/luke-jennings/Projects/ubuntu-manual/.bzr/checkout/dirstate'
<lifeless> ubuntujenkins: what version of bzr?
<ubuntujenkins> ok i did that and agreed to all of it and I now get http://paste.ubuntu.com/395852/
<lifeless> could you paste what it output as well ?
<ubuntujenkins> Bazaar (bzr) 2.1.0
<lifeless> you'll need to break-lock again
<ubuntujenkins> http://paste.ubuntu.com/395854/
<ubuntujenkins> i will do bzr break-lock
<lifeless> ok
<lifeless> now after the break lock, I expect it will fail again - thats ok
<ubuntujenkins> now it works again
<lifeless> ok
<lifeless> thats great
<lifeless> next time it fails
<lifeless> please run
<lifeless> fuser -v /home/luke-jennings/Projects/ubuntu-manual/.bzr/checkout/dirstate
<lifeless> we need to see what is locking it
<ubuntujenkins> thanks very much I have one more question, if i do bzr commit but don't want to commit how do i get out safley?
<lifeless> the easiest way is to let it finish, then do 'bzr uncommit'
<ubuntujenkins> ok thank you i did not know bxr uncommit existed
<lifeless> if bzr has popped up an editor, asking for a commit message
<lifeless> then you can just give it an empty message and it will abort
<ubuntujenkins> yep
<lifeless> otherwise you can also just hit ctrl-C and it will stop the commit cleanly.
<ubuntujenkins> cool
<ubuntujenkins> thanks again
<lifeless> kfogel: easiest test I know is: on your machine, make sure you can ssh in with keys; then edit your own authorized_keys to add the command, ssh in again
<mathrick> hi
<mathrick> http://pastebin.com/tAwdVyyL
<mathrick> a baffling crash I got
<mathrick> I've seen it before too
<mathrick> it was a push to a new branch, too
<mathrick> it doesn't happen when I go over sftp://
<kfogel> lifeless: will try, thx
<kfogel> lifeless: will test more later tonight, have to run right now.  Thanks for the time.  How much longer are you on?
<lifeless> kfogel: I'm here all wekk
<lifeless> boom-tish
<kfogel> lifeless: I mean today?
<lifeless> kfogel: its 0945 for me
<kfogel> lifeless: okay :-)
<lifeless> kfogel: I started before 7
<kfogel> lifeless: "I'm here all week.  Try the veal, remember to tip your waiters."
<kfogel> is the line I think :-)
<lifeless> so, abour 5 hours working, and more depending on $variables
<kfogel> lifeless: *nod* ok
<igc> morning
<mathrick> any eyeballs on that crash log I pasted?
<GungaDin> Hi
<GungaDin> How can I merge changes from a previous commit into the current version of a file?
<mathrick> GungaDin: what do you mean?
<lifeless> bzr merge -c commit filename
<GungaDin> I have a file x.cpp and there's another version of a file 3 commits before...
<mathrick> ah
<GungaDin> I need to merge some of the changes in the earlier version into the current one.
<mathrick> you probably want --interactive too if you only want some changes
<lifeless> "bzr merge -c commit filename ." then
<mathrick> lifeless: can you give two parameters to bzr merge?
<mathrick> if so, it's not listed at all in bzr help merge
<lifeless> oh, I mean
<lifeless> "bzr merge -c commit ./filename"
<mathrick> useful, I didn't know you could narrow it down to a path
<fossrox> hi Everyone :)
<dvheumen> hi
<stewart> abentley, i've edited the branch.conf files where needed... and still getting exactly the same error :(
#bzr 2010-03-16
<stewart> lifeless, is there any way to trace what bzr is reading from remote? basically i want to strace the stuff read from bzr+ssh
<lifeless> -Dtransport
<thumper> lifeless: does bzr handle utf-16 files?
<lifeless> if you are lucky :)
<lifeless> there is also log+lp:...
<lifeless> and trace+ I think - see bzrlib.transport/*
<lifeless> thumper: in what way
<stewart> lifeless, trying to trace what sync-pipeline is doing.
<thumper> lifeless: in storing them, diffing, normal stuff
<thumper> lifeless: so you can diff two utf-16 files
<thumper> at least that is what I think they were asking
<lifeless> uhm
<lifeless> broadly yes, but we can do better than we do
<lifeless> they may, at the moment, be detected as binary files some of the time.
<lifeless> our storage treats binaries and texts the same way, so no change to efficiency there
<thumper> hmm..
<thumper> lifeless: I'm writing up the result of my talk
<lifeless> however if they detect as binary, diff will just say 'binary changed'
<thumper> lifeless: on the whole it went well
<thumper> yeah, that is binary check is a big hammer
<thumper> utf-16 files have a specific header block don't they?
<lifeless> the BOM
<lifeless> sometimes
<thumper> oh?
<thumper> not all the time?
<lifeless> right
<thumper> BOM?
<lifeless> utf16 is an encoding
<lifeless> BOM (the byte order mark) is something you can put in any utf* document to let content sniffers figure the encoding out
<lifeless> you can have a BOM on utf8
<thumper> kk
<lifeless> http://en.wikipedia.org/wiki/Byte_order_mark
<lifeless> lol
<mathrick> it's almost always a bad idea though
<lifeless> 'The only solution is to hunt down the affected PHP file(s) and manually remove the BOM characters with another editor.'
<lifeless> I want to edit it and add 'or fix php'
<lifeless> mathrick: oh, I know.
<mathrick> lifeless: seriously, it's Win32 being idiotic here
<lifeless> mathrick: I know
<mathrick> BOM for UTF-8 is a dumb, dumb, dumb idea
<lifeless> the order is guaranteed in the encoding, its not needed. *I know*.
<stewart> lifeless, didn't do anything. trying every other -D option on the help page.
<lifeless> stewart: add trace+ to the start of your url
<lifeless> actually not
<lifeless> add log+
<stewart> lifeless, could bzr+ssh be having some sort of caching launchpad side?
<lifeless> no
<stewart> lifeless, where does the log go? or do i also need -D ?
<lifeless> ~/.bzr.log
<stewart> it seems much slower at least...
<stewart> i wonder if there's cache hiding or something.... eep.
<stewart> what. the. fsck...
<stewart> lifeless, it seems to be working now that i've specified log+ on the command line.
<stewart> abentley, ^
<thumper> igc: screenshots/windows/menu-Start.png seems to be missing on http://doc.bazaar.canonical.com/explorer/en/visual-tour-windows.html
<igc> thanks thumper: I'll take a look
<thumper> igc: I also sent an email about the talk to the internal list
<igc> thumper: so the file was called menu-start.png accidentally. Fix committed now. Should refresh on the website soon.
<thumper> igc: cool
 * igc lunch
<stewart> lifeless, abentley: after that magic (run with log+ and then it works better), then having to fix up branch.conf on an *old* pipe... things seem to be working again.
<lifeless> stewart: no idea why log+ would influence it
<lifeless> stewart: its a passthrough decorator
<stewart> lifeless, *weird*
<GungaDin> is it possible to turn a checkout into a branch?
<fullermd> Yes, you can use 'reconfigure' for that.
<parthm> hello, i am looking at bzr-grep bug #539258. any unicode experts here?
<ubottu> Launchpad bug 539258 in bzr-grep "UnicodeDecodeError while grepping emacs repo" [High,Confirmed] https://launchpad.net/bugs/539258
<parthm> the fix i had in mind was to simply "line = line.decode('utf-8', 'ignore')" before printing.
<parthm> is that reasonable?
<thumper> is there a bzrlib module for dealing with paths and filenames?
<thumper> like a special os.path thing?
<thumper> like getting the basename of a full path
<thumper> and such
<thumper> parthm: we do something similar in launchpad, let me look
<james_w> thumper: there's osutils
<james_w> and urlutils IIRC
<thumper> parthm:         try:
<thumper>             diff = preview_diff.text.decode('utf-8')
<thumper>         except UnicodeDecodeError:
<thumper>             diff = preview_diff.text.decode('windows-1252', 'replace')
<thumper> that seems to catch most issues
<thumper> james_w: thansk
<thumper> james_w: in bzrlib?
<james_w> IIRC
<james_w> yeah
<parthm> thump: thanks. so windows-1252 is used by windows?
<james_w> thumper: bzrlib.urlutils.basename seems like it might be what you want
<thumper> james_w: yeah, just looking at the pydoctor docs
<thumper> james_w: thanks
<thumper> parthm: yes, it is one of the standard windows encodings
<thumper> parthm: it is similar to the extended latin-1
<thumper> parthm: but with a few differences
<james_w> thumper: do you know if there is a request in the works to get more hardware for vcs-imports?
<parthm> thumper: thanks. that seems to be working fine. what does 'replace' do as compared to 'ignore'. the help(x.decode) isn't very clear.
<thumper> parthm: I don't remember
<thumper> sorry
<parthm> thumper: no problem. thanks for your help :-)
<parthm> got it. 'ignore' lets the bad chars be, 'replace' replaces them with '?'
<thumper> parthm: handy to remember
<lifeless> james_w: its early for you, isn't it ?
<james_w> lifeless: late, I'm out of timezone once more
<lifeless> ah
<lifeless> well when you're in $worktime, can you please mail me the stuff remaining for the watch-ppa bzr-builder branch to land
<lifeless> we're moving to UEC and I really need to be able to just install a package at this point, so I'll do whatever you want
<Peng> str.decode('replace') replaces them with the Unicode "I dunno WTF that was" character. unicode.encode('replace') replaces characters that the encoding doesn't support with '?' (or perhaps something else if that isn't supported?).
<parthm> Peng: yes. i am seeing the unicodes little white on black '?' as I am using str.decode :-)
<Peng> U+FFFD, to be specific,.
<james_w> I've just done annotate to get the revno of a change that I am interested in
<james_w> how do I get the log of all the revisions that were done between that branch diverging from LH ancestry and being merged back in there?
<james_w> the change I am actually interested in was done on that branch, but not in the indicated revision
<lifeless> do a log -r --show-ids to get the rh parent
<lifeless> uhm, and we don't have a good pithy-graph-operator, sorry.
<lifeless> bzr viz :
<james_w> how do I find that revision in bzr viz?
 * james_w does it the silly brute force way
<lifeless>  /revid
<lifeless> time for some wotw
<fullermd> Furrfu, SF is still on 1.10.
<lifeless> ,ee[
<lifeless> sorry
<lifeless> meep
<fullermd> Hm.  Or maybe not.  The shell service actually has 2.0.3.  The site still claims 1.10 though.
<lifeless> perhaps a 'min version'
<fullermd> 'd be nice if they at least said explicitly somewhere.  Then I'd know if I should bother trying to convert and upload a 2a branch of a project I don't have time to work on anyway...
<GungaDin> shouldn't commit push the history to the original repository I checked out?
<fullermd> Commit puts a new revision on the branch you're working on.  So it depends on what branch you're working on.
<GungaDin> it's a checkout.
<fullermd> If you ran a command like "bzr branch some/where here", your branch is 'here'.  If you ran something like 'bzr checkout some/where here', your branch is 'some/where'
<GungaDin> I have a checkout of a branch in linux
<GungaDin> and a checkout of the linux  checkout on windows
<GungaDin> I commited on windows and can't see the new commit on linux
<fullermd> Making a checkout of a checkout is unlikely to work well.
<fullermd> Regardless, check 'bzr info' to be sure you actually have what you think you have.
<GungaDin> yeah, like I described
<GungaDin> I committed on the checkout of a checkout
<GungaDin> and can't see it on linux
<fullermd> I have dark suspicions that checkouts of checkouts invoke nasal demons.
<GungaDin> so what should I do? try to push to the original branch?
<fullermd> But still, I suspect at least that first hop may work right.  How are you expecting to see it?
<GungaDin> in bzr log
<fullermd> Well, I can make all sorts of strange, bizarre, and unhygenic things happen with some local fiddling with co's of co's.
<fullermd> But after a commit at the tail of the chain, the next step up has the rev, at least until I 'update' it.
<fullermd> Somewhat annoyingly, all local links properly prohibit commiting in a co of a co, but across a network protocol it doesn't.
<vila> hi all !
<Peng> Good morning!
<jelmer_> moin vila
 * vila waves@jelmer (my god, already up ? Not at home ? :-P)
<jelmer> vila: Yeah, I'm in London :-)
<vila> jelmer: hehe, I spent the week-end there, that was nice :)
<thumper> why is workingtree.commit undocumented?
<thumper> not helpful
 * thumper reads the source
<tasslehoff> We use svn, and need to pull down an external git repo for our project. I don't think svn allows me to have a git repo as an external. Is this something bazaar can help me with?
<lifeless> thumper: its MutableTree.commit
<lifeless> thumper: and the guts are in bzrlib.commit
<thumper> lifeless: that isn't documented either
<thumper> lifeless: the source told me enough
<lifeless> thumper: the older the code is the less well documented. commit was _very_early
<thumper> lifeless: heh
 * igc dinner
<lifeless> thumper: hows the hacking
<persia> Good day.  I'm curious how well/badly bzr branches would deal with being hosted in ubuntu one.
<persia> I heard somewhere that bzr tracks inodes, which might break because of how ubuntuone copies files.
<lifeless> bzr has an inode concept of its own
<lifeless> it doesn't track fs inodes
<lifeless> however, given ubuntu one doesn't act like a posix file system, theres every chance of weird shit happening.
<persia> Ah, so if one just randomly copies a bzr branch, it ought still work?
<lifeless> I wouldn't do it.
<lifeless> oh yes
<persia> OK.  Why wouldn't you do it?  rye tells me svn works fine.
<lifeless> by doesn't act like a posix file system, I mean that unordered changes made on machine A are applied to machine B
<lifeless> an svn *repository* or an svn *checkout* - totally different things.
<lifeless> a bzr lightweight checkout (which is approx a svn checkout) would work fine, and only be buggered if you ran 'status' on two different machines, for instance.
<lifeless> persia: the problem is that if bzr writes to a file - any file; u1 tries to replicate that.
<persia> Seems it was just a checkout.
<lifeless> persia: but bzr is treating the fs as a place to do locking, and store a database.
<lifeless> would you put postgresql in u1?
<persia> That might be my next question :)
<persia> So it's a locking semantics thing?
<lifeless> thats part of it
<lifeless> the basic problem is that u1 writes to bzr's storage area.
<lifeless> only bzr or your 'I am restoring now' should ever do that.
<lifeless> everything else flows from this
<persia> Is this a structural issue or an implementation issue?
<lifeless> structural
<lifeless> applies to putting any DB or structured data in something like U1
<lifeless> postgresql
<lifeless> sqlite
<lifeless> bzr
<lifeless> git
<lifeless> svn (repo)
<lifeless> hg
<lifeless> they [probably] won't be a problem as long as you only ever have one machine signed into u1 at a time.
<lifeless> as soon as you have two, and have both active: *boom*
<persia> Right, which breaks the use case.
<lifeless> unless both the software in question is designed for cluster fs's, and u1 were to expose a cluster fs API
<lifeless> neither of which is the case for any of those AFAIK
<lifeless> I've seen one user lose a bzr repo to u1 so far
<persia> That's a cogent explanation, and an excellent data point.
<persia> Thanks a lot.
<lifeless> It would be nice if it worked better, but I don't think it can without a lot of effort, and I don't think it reflects *at all* on U1's quality.
<lifeless> databases syncing isn't their use case (note that they sync couchdb *totally differently*)
<lifeless> gnight
<persia> gnight.
<sttng359> hello
<sttng359> I'm looking for a way to replicate the behavior of svn:externals in bazaar.
<sttng359> or some method of easily pulling in changes for a large number of Bazaar projects at once.
<dvheumen> sttng359, I think there's a plugin called bzr-externals, I'm not familiar with the project though.
<sttng359> I found that project, but I also keep running into references of nested branches, but can't find much documentation on it.
<sttng359> If I do a branch into a subdirectory of another branch, does it automatically create a nested branch?
<sttng359> The main goal I am trying to achieve is nothing more than allowing users to easily update all checkouts up to date.
<beuno> sttng359, no, unfortunetely bzr doesn't support nested trees at the moment
<sttng359> was that a feature that was never completed or removed?
<parthm> hello. i am trying to optimize revision searching in bzr-grep. it seems "text = tree.get_file_text(..)" is taking most of the time.
<parthm> setting that to "text = random_block_of_text" makes the time go from 33s to 8s.
<beuno> sttng359, never completed
<parthm> is there a faster alternative to get_file_text?
<vila> sttng359: did you look at bzr-externals ?
<sttng359> vila: yes, I now have that installed and am testing it.
<sttng359> seems like it will satisfy my needs.
<sttng359> On a separate note, if I branch from a checkout made using bzr-svn, can I safely repoint the branch to the original subversion repository?
<sttng359> in other words, do branches retain all the meta-data used by the original checkout bzr-svn does?
<kfogel> It kind of worries me that if you go to http://bazaar.canonical.com/en/ and do a search (upper right hand corner search box) for the terms "bzr" and "ssh" together, you get no results.
<vila> kfogel: file a bug please, I get no results for 'bzr' alone either :-/
<kfogel> vila: whoa
<vila> that's so big the bug ought to be obvious...
<kfogel> vila: yup
<kfogel> vila: btw, do you have any experience setting up bzr+ssh:// access where users have only restricted logins on the server machine?  If you do, and can spare 5 min right now, I'd be grateful.
<dvheumen> I think it's a different problem: it seems that the search on the top-right expects a wiki pagename
<kfogel> vila: I've been running into some problems setting that up.
<kfogel> dvheumen: either way, it's a bug
<dvheumen> true
<kfogel> dvheumen: whether it's the intended behavior or not :-)
<dvheumen> well, it's certainly not expected behavior :P
<vila> kfogel: I've done it once, let me dig how
<vila> kfogel: right, I've done it in .ssh/authorized_keys by prefixing lines with: command="/bin/false",permitopen="localhost:nnnn"  to allow tunneling
<kfogel> vila: in authorized_keys?
<kfogel> vila: oh
<vila> kfogel: yup
<kfogel> vila: yes, you said that :-)
<kfogel> sorry
<vila> np
<kfogel> vila: interesting -- this is somewhat different from the advice lifeless gave, but I think he was speaking off the top of his head.
<kfogel> vila:  the behavior I'm seeing is that if I create a user 'kffsshtest', and give him /bin/false for shell in /etc/passwd, then when ~kfftest/.ssh/authorized_keys contains this:
<kfogel> command="/bin/sh -c 'echo fish'" ssh-rsa [...]
<kfogel> it will not echo the string fish when I ssh in.
<kfogel> But if I change shell to /bin/sh in /etc/passwd, it does echo fish.
<vila> hmm, too many possible explanations here :-/
<kfogel> Which strikes me as bizarre -- you'd think it would work to specify an exact command in authorized_keys
<kfogel> vila: yeah
<kfogel> vila: but I'm thinking: who cares if /etc/passwd lists /bin/sh for people's shells, if the only way they can get in is via ssh, and ssh runs a command?
<kfogel> command="/usr/bin/bzr serve --inet --allow-writes"
<kfogel> ...will be the actual command, of course
<kfogel> plus maybe a --directory option
<kfogel> vila: but anyway, that recipe seems different from what you've done, so I'd be curious to see what you've done.
<vila> kfogel: it wasn't for bzr use
<kfogel> vila: ah
<vila> kfogel: where I need bzr I already have shell access but I need to set bzr_remote_ssh in locations.conf
<vila> .. for ... various reasons (mostly not using the ystem-wide installed bzr)
<kfogel> vila: ok.  This is for a situation where the bazaar committers should *not* have true login access on the server, just bzr access.
<vila> then command="/usr/bin/bzr --inet..." sounds fine
<vila> kfogel: and you set up as many users as committers right ? (i.e. not a single shared one)
<kfogel> vila: that's the idea
<vila> then if the server is configured to refuse authentication by password you should be fine, the only way will be by the key and I don't remember an ssh option to work around that
<kfogel> vila: so I just filed bug 539587 about the search breakage.  It was a horrific experience -- total Launchpad fail :-(.
<ubottu> Launchpad bug 539587 in bzr "search broken on bazaar.canonical.com web site" [Undecided,New] https://launchpad.net/bugs/539587
<kfogel> vila: I went to launchpad.net/bazaar, thinking that was the product name.
<kfogel> It somehow decided I meant the Uninstaller for the Bazaar Macintosh Bundle project.
<kfogel> By the time I noticed I'd already filed the bug.
<kfogel> So I added a new bugtask for project 'bzr' (whose display name is "Bazaar"), and tried to delete the other task.
<kfogel> But nooooo, turns out what I was supposed to do was just *change* the task on the old one.  But when I try to do that, entering 'bzr' for the new task fails, and so does 'bazaar': "Too many matches; please try to narrow your search."
<kfogel> aaaaargh
<vila> bazaar is bzr + supporting tool, that was fine
<kfogel> vila: well, it's totally unrelated to the mac uninstaller
<vila> yeah, that one is more puzzling :)
<kfogel> vila: and that there's no way to delete a wrong task, or at least make it disappear (when "invalid", it is still listed on the bug by default)... sigh.
<kfogel> vila: anyway, bug filed.  I hope someone can fix it.
<vila> igc will certainly have a look at it
<Tak> can I not propose a junk branch for merging?
<Tak> (on launchpad)
<james_w> you cannot
 * Tak grumble, repush
<vila> Tak: lp use stacked branches, pushing in the right project should be *far* faster (and less bandwidth intensive) than pushing to a +junk branch
<Tak> yeah, I didn't have a project set up for this one
<Peng> FWIW, LP used to allow changing a branch's project through the website, and it may still allow it through the API.
<kfogel> vila: when I 'bzr push' up to my remote test project, I get this warning on the client side:
<kfogel> This transport does not update the working tree of: bzr+ssh://kffsshtest@sp.red-bean.com/projects/deepproj/. See 'bzr help working-trees' for more information.
<kfogel> vila: I did 'bzr help working-trees', but it wasn't clear from that whether I'm supposed to use remove-tree locally (???) to suppress the warning, or use --no-trees on the server side.
<kfogel> vila: i.e, use --no-tree when I had created the server-side shared repos
<vila> kfogel: do you want yo update the remote working tree ... use --no-trees is what you want I think
<kfogel> vila: no, no update of remote tree -- just want to not get the warning.
<kfogel> vila: I think remove-tree on the remote side is what I want
<kfogel> testing now
<vila> I think so, I'm pretty sure you got the warning only if a remote working tree exists
<kfogel> vila: yup, that was the answer
<kfogel> vila: oddly, you'll get the warning even when the remote tree *doesn't* exist, but only if it theoretically could -- that is, the remote branches were not created with --no-trees, and 'bzr remove-tree' has not been run on them.
<kfogel> pushing to those remote branches will not create a working tree, but you'll get the warning until you configure the remote side to stop thinking that it "ought" to have a working tree.
<vila> kfogel: if you don't configure the remote side with --no-trees, then you *want* to be warned that your working trees are not updated
<kfogel> vila: well, if you know bzr, sure :-).
<vila> even more if you don't IMHO, even knowing it, I keep running into out-of-date working trees :)
<kfogel> vila: however, experience teaches me that plenty of people create remote trees without that option, but this does not actually mean they "want" working trees on the remote side.  It merely means they didn't know they needed to tell Bazaar that they didn't want that.
<vila> kfogel: I'm pretty sure that a bzr push outside a repo creates just a branch with no working tree
<vila> if you have created a shared repo, that's another matter though... may be the default should be --no-trees... but on the other hand, most of the time when you create a repo that's because you have many wts....
<bialix> heya vila, kfogel
<vila> bialix: hey
<kfogel> bialix: hey
<NfNitLoop> Hrmm.
<NfNitLoop> Best-practice question with SVN:
<NfNitLoop> I tend to develop like this.   1) Create local branch.  2) Do work on local branch.  3) Merge from upstream as needed.
<NfNitLoop> when I'm ready to commit I merge back onto the latest upstream and push it back to SVN.
<NfNitLoop> which is cool from my perspective, but my commit message doesn't include any of the details of my inner commits.
<NfNitLoop> Unless I manually copy & paste them all.
<NfNitLoop> which is a pain.
<NfNitLoop> (I mean:  It doesn't include any of those details for SVN users.   I can see the merges in my logs, of course.)
<NfNitLoop> any better way to do that?
<NfNitLoop> Rebasing doesn't really work well, since having merged from SVN seems to break rebase.
<lifeless> you can use dpush
<lifeless> otoh I would say you should just write a clear summary commit on the merge
<NfNitLoop> Oh, I like push.  IMO keeping as much metadata is good.
<vila> lifeless: can't commitfromnews be tweaked for that ? (Or is it newsfromcommit ?)
<NfNitLoop> I just want to put more of it into the comment that SVN users can read.
<NfNitLoop> as much metadata as possible*
<lifeless> vila: its commitfromnews; I'd start by writing a new 'commitfrommerge' plugin or so
<spiv> Good morning
<poolie> hi all
<spiv> poolie: good morning
<dvheumen> hey poolie
<poolie> hi dan
<poolie> i just saw your mail
<dvheumen> poolie, okay. I hadn't expected you online so soon :P
<GungaDin> How can I remerge a directory from a branch I someone skipped in a previous merge?
<Peng> GungaDin: bzr merge -r 123..124 some_branch
<GungaDin> and how can I find out where it was left out exactly? during which revision?
<Peng> 'bzr log directory/' on the original branch, perhaps?
 * Peng /away (maybe)
<GungaDin> can I specify the directory I need to merge in so only the changes in it will be merged in?
<dvheumen> poolie, thanks for the info. I'll wait a few days so the FAQ + Contributor Agreement can be updated
<lifeless> GungaDin: yes
<GungaDin> how?
<lifeless> bzr merge -r x..y branch/directory
<GungaDin> what if I need the whole directory as it looks in the latest revision (not just the latest change to that directory)?
<GungaDin> x = 1 y = last revision?
<lifeless> x would be 0 then, I guess
<dvheumen> poolie, changed my mind, agreement is sent, since you've already updated me on the details.
<poolie> thanks
<poolie> i'm sorry it's so slow
<poolie> i don't understand why
<dvheumen> poolie, no problem. It's just that ... like I said ... it's lawyer stuff ... sigh
<dvheumen> but I understand why it's necessary :)
<lifeless> poolie: you have mail; would like to chat by voice today about it
<poolie> oh, you're going to recommend a bulk-delete?
<poolie> or some mail in particular :)
<lifeless> poolie: GNU meetup talk items
<poolie> ok
<poolie> i think that's a good list of things
#bzr 2010-03-17
<thumper> abentley: yay for DTRT for pipes
<thumper> abentley: switch-pipe :prev, then merge --uncomitted :next :)
<lifeless> thumper: see, I'd prefer that to just be 'switch :prev' like it is in loom :)
<thumper> lifeless: actually if I just did a switch :prev, then that would have worked too
<lifeless> ah!
<thumper> lifeless: but since I had already typed `bzr prev` which I have aliased to `switch-pipe :prev`
<thumper> it seemed easer
<thumper> easier
<igc> hi all
<poolie> hi igc
<poolie> i forgot what i was going to ask you :)
<igc> :-)
<igc> poolie: was it about bug 539587?
<ubottu> Launchpad bug 539587 in null "search broken on bazaar.canonical.com web site" [Undecided,Invalid] https://launchpad.net/bugs/539587
<poolie> yes! i just realized that too :)
<igc> or maybe about the RT request?
<poolie> no, about the site search
<igc> poolie: I can't recall changing anything about search search fwiw
<jderose> http://jderose.s3.amazonaws.com/clouds_450p_5.ogv
<jderose> whoops, wrong tab.  ;)
<lifeless> poolie: so if you're totally happy with my sketch we can skip talking about it
<poolie> i am happy actually
<poolie> i don't have any objections and i think they would all be great things to do
<poolie> and we will do at least some of them
<poolie> i wouldn't say it's an exhaustive list of everything we will do, or be asked to do
<poolie> btw do you have any brilliant ideas about https://bugs.launchpad.net/bugs/522637
<ubottu> Ubuntu bug 522637 in bzr "BzrCheckError: Cannot add revision(s) to repository: missing referenced chk root keys" [High,Confirmed]
<thumper> hi people
<thumper> I just noticed a 'dent about conceptual differences between hg and bzr
<thumper> is there a doc somewhere to point them at?
<poolie> http://doc.bazaar.canonical.com/migration/en/survival/bzr-for-hg-users.html maybe
<thumper> poolie: ta
<abentley> thumper, yeah, whoever wrote bzr-pipeline was reading my mind :-)
<thumper> :)
 * igc lunch
<poolie> spiv, igc, lifeless: perhaps the day has come to use a script to flip all bugs from triaged->confirmed?
<spiv> poolie: well, it's not causing me any direct pain that I've noticed, but if it's bugging you then go ahead :)
<spiv> poolie: fwiw, a one-off bug spam like that isn't a big deal for me.
<lifeless> poolie: if you do that, please send a mail saying 'starting' and another saying 'stopped'
<lifeless> so I can just delete all bugmail in the intervening period
<poolie> heh
<poolie> imbni there was a wikipedia-like concept of 'this is a minor edit'
<poolie> otherwise no objections?
 * lifeless shrugs/
<poolie> putting pqm failures as attachments (not inline) in the comment stream might just be the killer feature for direct pqm integration
<poolie> because it would mean the person who queues/approves the merge need not be in the loop to fix the failures
<spiv> poolie: yes, that would be awesome
<lifeless> grabbing late lunch
<idnar> huh
<idnar> I run bzr upgrade on this branch, and it tells me "This may take some time. Upgrade the repositories to the same format for better performance."
<mwhudson> i think that bug got fixed
<idnar> running bzr 2.1.0 here
<idnar> would the fix have been after that?
<idnar> not that it's a big deal, just a little confusing
<spiv> I don't think that was fixed in 2.1.
<vila> hi all !
<_Andrew> Hi, I was wondering if anyone knew if this kind of thing exists in bzr and what it's called. I want to copy a file so that changes are tracked and applied to both the original file and the cloned file?
<bob2> it does not
<_Andrew> doh :(
<bob2> not sure that any dvcs does that
<fullermd> I think I heard once that hg has copy support.  How much it DOES with it, I don't know.
<_Andrew> I think it's quite a useful feature because there is a situation where I want to update from a parent however the file I want to update needs to be split up so that the functionality is in one file and the html is in another. If I had a copy function then I think it should be able to still apply the parents updates.
<_Andrew> I'll look around. Maybe someone else is working on this for bzr
<fullermd> Well, sure it's useful.  But it's not just the devil being in the details; he brought along 10,000 of his closest friends too, and they're having a raucous party.
<_Andrew> hehe
<fullermd> Conceptually, git's psuedo-ignoring of files has a chance of DTRT there.
<radoe> hm, bzr tags in a branch of emacs upstream repo from http://bzr.savannah.gnu.org/r/emacs/trunk/ takes about 25 seconds....
 * igc dinner
<Tiibiidii> hi, i'm thinking of versioning my project's libraries...
<Tiibiidii> i read this: http://stackoverflow.com/questions/1710027/can-should-i-put-3rd-party-libraries-in-version-control
<Tiibiidii> and they suggest that, while libraries should be versioned, it's better if they are in a different branch
<Tiibiidii> so i looked at nested trees...
<Tiibiidii> i could create one with split or branch of the library subdirectory
<Tiibiidii> (is there any difference between these 2 commands?)
<Tiibiidii> and then i could even join the subdirectory
<Tiibiidii> the main purpose of "join" (if i'm not wrong) is that the commit on the parent tree, are recursed into the subtree
<bob2> split and join are still experimental afaik
<bob2> no
<Tiibiidii> uh
<Tiibiidii> i'm asking myself if i should branch it into a subdirectory or joining it however...
<Tiibiidii> what do you use to version your libraries?
<bob2> the internet
<Tiibiidii> lol?
<bob2> split and join don't really help with vendor branches
<Tiibiidii> mhn
<Tiibiidii> why do you say that?
<Tiibiidii> (however please note that mine's a java project... and afaik in java world is quite common to not use the latest and greates version of an external library... just look at  maven)
<bob2> I guess join could help, actually
<Tiibiidii> (so i'm not urged to update my lucene to 3.0 :) )
<bob2> don't java people just use maven for this?
<Tiibiidii> many do...
<Tiibiidii> ( i haven't really used it yet... i'm not even doing this for work: it's an university project... and i'm thinking of versioning my libraries only now that i've to leave this project to another guy, so at least he'll start with this problem already solved)
<bialix> Tiibiidii: you can use either bzr-externals plugin or bzr-scmproj plugin
<bialix> there is no built-in support for nested trees yet
<Tiibiidii> mhn, i read about those... but it seems they were used a solution for when nested trees weren't yet supported
<bialix> so split works, but join is not AFAIK
<Tiibiidii> ah
<Tiibiidii> that's strange
<Tiibiidii> i mean: i should have a quite stable version of bzr
<Tiibiidii> not a bleeding edge one...
<bialix> I don't understand
<Tiibiidii> and yet if i type "bzr help join" it doesn't warns anything about it not being implemented yet
<Kamping_Kaiser> jelmer: can i rebase part of a tree? i'm trying to work out why bzr is crashing during a rebase. it seems to do the first 2-3 commits, then bomb out
<bialix> Tiibiidii: today join works as merge of subtree into parent tree. This is not what nested tree should be IMO
<jelmer> Kamping_Kaiser, No, there's no way to do a partial rebase at the moment.
 * bialix waves at jelmer
<jelmer> hey bialix
<bialix> heya jelmer
<Tiibiidii> bialix: ok, thank you... i didn't really delved into nested trees documentation... however that's good news, right? (at least for my use case)
<Tiibiidii> however do you suggest i should only split/branch it... or should i split+join it?
<Kamping_Kaiser> jelmer: ok. I'll leae that branch alone for a while.
<fullermd> split+join would be an incredibly pointless operation...
<bob2> why do you want to use them at all?
<bob2> you want to check out specific revs of your vendor branches
<Tiibiidii> because using an integrated bzr tools seems more appropriate than using an external plugin like scmproj :)
<bialix> Tiibiidii: what is your use case?
<bialix> Tiibiidii: oh, c'mon
<Tiibiidii> project, with some folders (most important among them: src/ and test/ )
<Tiibiidii> and then an unversioned lib/ folder
<Tiibiidii> i want to version it
<Tiibiidii> but i would prefer to version it in a separate branch
<Tiibiidii> however fullermd, why do you say it's pointless? i mean: it's even suggested as an use case here: http://wiki.bazaar.canonical.com/NestedTreesDesign#id20
<Tiibiidii> (however, thank you all for the hints this far)
<fullermd> First off, that's a design doc for discussions about how to implement a feature, not anything remotely related to what the commands do in bzr.
<fullermd> So trying to take anything in it as suggesting things to do with bzr is chimeric.
<Tiibiidii> uh... my bad: i thought that since split and join were present in bzr 2.0 they were working as in that doc
<fullermd> Not at all.
<fullermd> join implements "by-value" nested trees, which basically means it's equivalent to merging the other branch and mv'ing everything into the subdir.
<thumper> using bzrlib, what is the (easiest) way to determine the last revision that modified a particular file?
<fullermd> A useful thing, but nothing at all like "by-reference" nesting, where you link to an existing but kept separate branch.
<thumper> only really concerned with mainline revisions
<Tiibiidii> ok
<fullermd> And split is a dangeous command, because your intuition about it usually doesn't match what it actually does.
<Tiibiidii> uhm
<fullermd> You think of it as "take the history of just this subdir and make a branch of it"
<Tiibiidii> yes
<fullermd> But that's a destructive operation.
<Tiibiidii> (given that lib/ until now isn't yet versioned, that's not really a problem for me)
<fullermd> What it does is the same as "bzr branch existing new ; cd new ; rm <everything but that dir> ; mv <that dir> <root> ; bzr ci"
<Tiibiidii> oh
<fullermd> Yeah, so it has no applicability there anyway.
<fullermd> (actually, split + join might have really scary consequences, since it would merge rm'ing everything, I think.  But at best, it's an expensive no-op.)
<Tiibiidii> rm <everything but that dir> <-- why does it do this?
<fullermd> Because if it didn't, you wouldn't end up with a branch looking like it was based at that subdir, you'd just have a copy of the existing branch.
<Tiibiidii> mhn, using "bzr branch --use-existing-dir lib" would do what i'm aiming for?
<fullermd> No, that's a trick for saving transfer in certain cases.
<fullermd> If lib isn't versioned, none of this is meaningful.
<fullermd> (and if it's a versioned dir in a branch, you couldn't "branch" it anyway)
<fullermd> What's in it that you're trying to jump through all these hoops in the first place, rather than just add'ing it to the branch it's already in?
<Tiibiidii> they taught me that adding big binary blob in a VCS (even modern ones, aka: after-CVS) isn't not a good thing
<Tiibiidii> but since i want to version my libraries, i'd prefer to keep them separated
<fullermd> Well, it's not.  But why do you want to...   well, I guess it doesn't matter.
<Tiibiidii> lol
<Tiibiidii> why do i want to version my libraries?
<fullermd> Yeah.  It's nutbar.
<fullermd> But if you want to, you want to.  Retarded or brilliant, that's your problem, not mine   :p
<Tiibiidii> mhn
<Tiibiidii> are you saying you don't version your libraries?
<fullermd> Just make 'em their own branch, and worry about burning the bridge of externals/scmproj/nested-branches when and if you come to it.
<fullermd> Well, what libraries?  3rd party stuff I happen to link, like libX11 or gtk or something?  No.
<fullermd> My own stuff?  Of course not.  I version the source.
<Tiibiidii> mhn, well...
<fullermd> If I wanted to do the former, I'd use vesta   :p
<Tiibiidii> if it where libX11 or gtk i probably wouldn't version it....
<Tiibiidii> i mean: that ones are quite common
<Tiibiidii> on the other hand, sax, lucene, pdfbox, etc. are not
<Tiibiidii>  i mean: that ones are quite common <-- i mean for the target system... i guess one doesn't have the lucene .jar laying aroung if he's not developing something with it
<fullermd> See, that sounds more like you don't care about _versioning_ them, you're just trying to come up with a _deployment_ mechanism.
<Tiibiidii> yes... but by versioning something it should even be easier to deploy it, no?
<Tiibiidii> bzr pull, compile, and run
<fullermd> I doubt it.  Would be a lot less efficient than `fetch -o- | tar xvf-`
<Tiibiidii> fetch -o- ?
<fullermd> Well, "wget -o-" if you don't have fetch.  Whatever.
<Tiibiidii> mhn
<Tiibiidii> so you mean
<Tiibiidii> bzr pull, fetch, tar xvf, compile and finally run?
 * fullermd shrugs.
<fullermd> No reason the fetching couldn't be part of the compile process.
<Tiibiidii> uhm
<fullermd> make's all about building dependancies, after all.  Fetching is a form of building   :)
<fullermd> But in any event, I have a violent antipathy to use of VCS's as deployment mechanisms.  Other people here don't have my pathology, so they might have more cogent advice.
<Tiibiidii> but fetching is a complicated process, i mean: by fetching the latest version libraries something is almost guaranteed to break
<Tiibiidii> mhn ok
<Tiibiidii> i could even use maven
<Tiibiidii> but that imho is overkill (at least for now)
<fullermd> Well, I was thinking in the sense of you providing a tarball like you'd provide the branch.
<Tiibiidii> (and i would've to learn yet another tool)
<Tiibiidii> mhn that's probably what i'll end up to :)
<Tiibiidii> (i mean: for the only lone guy who'll continue my work that's not a problem... otherwise i should kept the tarball updated with the latest library changes)
<Tiibiidii> however thank you all for the help
<Tiibiidii> in the end i guess that for my next project i'll use maven and version the .pom
<Tiibiidii> and for now i'll version my nbproject/project.properties that contains the libraries list
<Tiibiidii> (i haven't versioned yet my ide config directory since i'm fairly certain that the next guy will use eclipse, and so the netbeans files will be of no use to him... and so i preferred to avoid cluttering my branch)
<GaryvdM> Hi. Is there a way to have a setUp that runs only once for multiple tests. In the setup, I'm creating a tree, and in the tests, I do some read only operations.
<GaryvdM> This is my test: http://bazaar.launchpad.net/~garyvdm/qbzr/538735-treewidget-filter-ignored/revision/1212  At the moment, its one test. I want to split it up, so that I can see if more than one Is going to fail.
<bialix> GaryvdM: hi
<bialix> GaryvdM: AFAIK, no
<bialix> what's the problem?
<GaryvdM> bailix: Hi. I only want to create the tree once for performance reasons.
<bialix> ok, I see
<bialix> GaryvdM: you can try to override __init__ but I think this is not recommended way
<bialix> maybe vila knows?
<GaryvdM> :-)
<vila> GaryvdM: you can't
<bialix> heya vila
<vila> the main reason is to ensure that bugs don't propagate from one test to the other
<vila> bialix: hey :)
<GaryvdM> Hi vila
<GaryvdM> So should I just split it up, and not worry about performance?
<vila> GaryvdM: otherwise you may want to look at lp:testresources which intent to address that
<vila> GaryvdM: exactly
 * GaryvdM looks
<vila> GaryvdM: the long term plan is to be able to have wt fully supported in memory so we don't have to pay the IO penalty
<GaryvdM> Thats cool.
<vila> GaryvdM: and sorry for not replying to your mail about 'QBzr test I just wrote' :-( It still flagged as 'needs to be acted upon' though...
<GaryvdM> vila: No problem. I just wanted to let you know I made some progress.
<GaryvdM> Recently, I've been writing lots of tests for qbzr :-)
<vila> GaryvdM: That's great !
<vila> GaryvdM, bialix : Out of curiosity, how do you hack on qbzr ? Always using the trunk version ? Switching between branches ?
<GaryvdM> Vila: Mostly, just on trunk. For big features I create a feature branch.
<vila> GaryvdM: and how do you *use* that feature branch ? swapping the installed one with yours ?
<GaryvdM> vila: I have a dir structure like this: http://pastebin.org/116211
<GaryvdM> vila: When I'm deving, I export BZR_PLUGIN_PATH=~/qbzr/wd/
<GaryvdM> All editing happens in ~/qbzr/wd/qbzr/
<GaryvdM> Poor mans co-located branches.
 * GaryvdM -> lunch
<vila> GaryvdM: beware: you have two featureA branches :-)
<GaryvdM> Vila: It would be cool for plugin authors to be able to do somthing like BZR_PLUGIN_PATH=;qbzr=~/qbzr/featureA
<GaryvdM> I'm sure that I would do feature branches more if I could do that.
<vila> GaryvdM: how about BZR_PLUGINS_AT=qbzr@~/qbzr/featureA ?
<vila> GaryvdM: let me see if I can write a quick patch for that
<GaryvdM> Vila: Yes, Thats the idea.
<vila> GaryvdM: here you are: https://code.edge.launchpad.net/~vila/bzr/82693-plugin-at-path/+merge/21547
<vila> :-P
<GaryvdM> :-)
<vila> GaryvdM: tests and feedback welcome (I'm not sure ~ is supported, but it should be easy to add)
<vila> bbia
<bialix> vila: I'm using colo plugin
<bialix> before colo plugin I've used just light checkout of several branches in shared repo. so it was almost the same as colo, but separated in 2 directories
<GaryvdM> Hi vila. bialix said while you were away: http://pastebin.org/116280
<bialix> oops
<xorAxAx> hi, how can i clone all of these branches? https://code.edge.launchpad.net/~mwhudson/pypy/
<vila> bialix, GaryvdM: I thought I read somewhere that it was possible to use ctfl-F for searching in qblame but no luck so far...
<vila> bialix, GaryvdM: Did I dream or is it part of a wip ?
<maxb> xorAxAx: There is no trivial shortcut. You'd have to make a list and do each one. (Into a shared repository, obviously)
<xorAxAx> maxb: how do i ensure that it is a shared repo?`
<maxb> A shared repo is what you create using 'bzr init-repo'
<xorAxAx> maxb: and how do i clone into the shared repo?
<maxb> Any branch newly created under the directory of a shared repo will use it
<xorAxAx> ah, magic
<xorAxAx> ok
<maxb> Note that this is just a storage/bandwidth optimization, to avoid storing/transferring the common history between branches multiple times
<maxb> wget -nv -O- "https://code.launchpad.net/pypy/+branches" | html2text -ascii -nobs -width 300 | sed -nr 's/.* (lp:[^ ]+) .*/\1/p'
<maxb> xorAxAx: ^ may be of use to you
<xorAxAx> cool!
<GaryvdM> vila: lp:~garyvdm/qbzr/annotate_find
<GaryvdM> vila: wip
<GaryvdM> vila: wip because I want to make that ui change to all browse dialogs before I land it. If you don't mind that, It is compleatly usable.
<vila> GaryvdM: I'll try it (and hope I'll remember to track when it lands...) that's my most wanting feature
<vila> GaryvdM: well, that and being able to do bzr qblame <file> <linenumber> :-P
<GaryvdM> vila: That branch also has a gotoline (ctrl-g), but no command line option.
<vila> GaryvdM: I see that, cute :)
<vila> err, I can't type anything  in Goto Line box
 * GaryvdM looks
<vila> .. but got a nice error dialog if I press the Go button about: invalid literal for int() with base 10: '' :-D
<vila> incremental search.... rhaaaa lovely
<vila> hmm, no short-cut for previous/next ?
<GaryvdM> vila: For me I can type numbers into the goto line box.
<GaryvdM> vila: I get that error I type nothing in.
<vila> GaryvdM: Do you have a numeric keypad or are you typing from the upper row ?
<vila> neither works in my case anyway
<GaryvdM> :-( Keypad does not work. Using upper row.
<vila> weird
<vila> GaryvdM: you checked your num-lock right ?
<vila> pasting doesn't work either, that kind of rules out a keyboard problem
<GaryvdM> vila: I'm just doing :
<GaryvdM>         self.line_edit.setValidator(QtGui.QIntValidator(1, sys.maxint, self.line_edit))
<vila> GaryvdM: Anyway, it's already useful as-is, I usually *know* the line number because it's there in an emacs buffer but generally I'm searching for some text, so incremental search is a real plus
<GaryvdM> vila: I'll make a note about that.
<vila> GaryvdM: commeting this line is enough to make it work ;)
<vila> But you should also bind <return> to the Go button ;)
<GaryvdM> Yes
<GaryvdM> Hmm, I have go.setShortcut((QtCore.Qt.Key_Enter)) , but it's not working
<vila> hmm, I think you should do that on text entry
<ascii_phil> Any bzr-svn people around?
<jelmer> ascii_phil, yep
<ascii_phil> bzr-svn is refusing to do a commit because it would change the mainline history.  I think the commit should be a straight append.  Is there any way to tell what changes bzr-svn wants to make to the history without actually doing it?
<ascii_phil> The commit is going from a local Bazaar repository to a remote Subversion repository.
<jelmer> ascii_phil: What does "bzr missing" say ?
<ascii_phil> Three extra local revisions, no extra remote revisions.  The first of the three local revisions is a merge from another local Bazaar branch that's been pushed to a different Subversion branch.
<ascii_phil> That may be confusing.  I have two bzr branches: one synced with a project's trunk and another synced with a branch of that project.
<ascii_phil> I did some work in the dev branch, pushed it to svn, merged the dev work into the bzr trunk, then pushed the merge into the svn trunk.  Following that, I pulled from the bzr trunk into the bzr dev branch (maybe I didn't need to do that?) and put another two commits into the dev branch.  Now the bzr dev branch won't push to the svn dev branch.
<timClicks> is there an equivalent to "git format-patch origin/HEAD" in bzr?
<james_w> timClicks: bzr send is the analogous command
<timClicks> james_w: ty
<NfNitLoop> ascii_phil: strange, sounds like that shoudl work.   Try 'bzr vis' and see if it reveals some non-linear history?
<ascii_phil> It looks reasonable.  Lemme take a snapshot.
<ascii_phil> Here's what `bzr vis` gives me: http://imgur.com/cM1gK.png .
<NfNitLoop> so those blueish/purplish dots were done in another branch, then merged in to this branch.
<NfNitLoop> were either of the 2 revisions after those from SVN?
<NfNitLoop> Oh, wait, you said you merged from trunk into your dev branch.
<NfNitLoop> so those colored dots are from trunk.
<ascii_phil> I merged those 8 blue dots from this branch into the trunk.  Then I pulled from the trunk back into this branch.
<NfNitLoop> ah, that's why.
<ascii_phil> Now I think I see the problem.  bzr had no problem stuffing what were toplevel commits into a merge commit, but that's not compatible with Subversion.
<NfNitLoop> because the history in trunk has a different order from the history in your branch.
<ascii_phil> So I'd be okay in this case if I *didn't* pull the merge back from the trunk.
<NfNitLoop> right.  By pulling trunk, then trying to push it to your dev branch, you'd be reordering the history in your dev branch to look as if it were trunk.
<NfNitLoop> right.  Instead, *merge* back from trunk.
<NfNitLoop> the merge from trunk will be appended to the end of your history, and that can be pushed back to SVN.
<NfNitLoop> FYI... you CAN push this to svn if you use a --force (or --override?) flag, but bzr-svn stops you because that sort of history is REALLY wacky to read in a SVN repository.
<NfNitLoop> so bzr-svn is just trying to protect you in that respect.
<NfNitLoop> Your other option is to just delete your dev branch and re-create one from trunk.
<ascii_phil> Yeah, the error message includes an option to change to let it go ahead, but I really don't want to rewrite the Subversion commit history.
<NfNitLoop> good call. :)
<ascii_phil> Awesome.  I rewound the branch's history, did a merge from the trunk instead of a pull, and was able to push my new commits up to the Subversion branch.
<ascii_phil> Thanks!
<NfNitLoop> no problem.
<paris> has anyone tried to install bzr on apache with mod_fcgid?
<paris> all i get is (146)Connection refused: mod_fcgid: read data from fastcgi server error.
<NfNitLoop> paris: Erm... install bzr on apache with mod_fcgid to do what?
<NfNitLoop> serve out a branch?
<paris> if got a base directory that has /admin and /code, admin for cgi script, code for all sub dirs
<paris> and beneath that are the results of init, so not sure if u'd consider that a branch or not, still wrapping my head around this concept
<GaryvdM> paris: what happens when you run bzr-smart.fcgi from the command line
<paris> so code/projects/myproject/stable, code/projects/myproject/dev
<NfNitLoop> well, before you try to wrap your head around the concept, what are you trying to accomplish?
<paris> it complains that request_uri isn't set, which seems like an acceptable error
<paris> we have a svn repo, and want to gradually convert
<paris> (repos), want to have central repo capabilities, but allow for distributed local copies
<paris> as well as play around with foreign branching to accomodate current build tools
<GaryvdM> paris: Much eaiser to serve branches with sftp
<paris> wanting to serve through apache to use existing auth methods
<GaryvdM> paris: I see
<paris> right now, its all on a nfs, so we could access directly, but i'd like to do everything through http(s)
<GaryvdM> paris: what happenes if you run bzr-smart.fcgi from the command line?
<paris> the only sense i can make of that error, is the script is firing properly, which i dont know if is due to mod_fcgid compatability or a configuration error on my part
<jacques> I'm trying to branch from launchpad and I am behind a http/s proxy - do I need to build bzr 2.1 for this to work?
<paris> it complains that request_uri isn't set, which seems like an acceptable error
<GaryvdM> paris: please paste bin the whole error.
<paris> i think i made progress, had to chmod +x the fcgi file
<paris> bzr: ERROR: Server sent an unexpected error: ('error', "Can't extract file(s) to egg cache\n\nThe following error occurred while trying to extract file(s) to the Python egg\ncache:\n\n  [Errno 13] Permission denied: '/.python-eggs'\n\nThe Python egg cache directory is currently set to:\n\n  /.python-eggs\n\nPerhaps your account does not have write access to this directory?  You can\nchange the cache directory by setting the PYTHON_EGG_
<paris> looks like i need to do some environment cleanup
<paris> if anyone has access to that wiki page, be nice to add a note to chmod the fcgi script, though I assume people are familiar with fastcgi would expect it to be known
<GaryvdM> paris: url?
<GaryvdM> for wiki page...
<paris> http://doc.bazaar.canonical.com/bzr.2.1/en/user-guide/http_smart_server.html#pushing-over-bzr-http
<GaryvdM> paris: Ah that doc is from the bzr source.
<paris> also not sure why python_egg_cache set env isn't being passed down to python ( i added a shebang at the top of the fcgi to point to python, so perhaps its not inheriting system env? ), but i chowned /.python-eggs and it works now
<paris> so for the svn plugin, am i able to run something like, "bzr branch http://my.svn.repo", and if i commit, it goes local, and if i push it goes to the bzr repo, but if i commit, it goes to svn?
<paris> assuming bzr branch is done beneath the init-repo
<Peng> What?
<Peng> commit and push are the same as any other bzr branch.
<paris> i guess i asummed that you could branch off of a svn branch, and work on it locally
<paris> and only "push" the changes to svn when you wanted to
<Peng> You can.
<paris> put pushing, would go to ur bzr branch
<paris> where submitting would go to svn
<Peng> Pushing goes to the parent branch. I'm not sure what exactly you're asking. If the parent branch is an svn branch, that is where it will go.
<paris> gotcha
<NfNitLoop> you can even do:  svn -> bzr -> 2nd-bzr-branch -> push back to original SVN repo.
<paris> yeh, for some reason i wasn't thinking about the branch in the middle
<NfNitLoop> It works quite nicely. :)
<paris> so our "central "repo, would branch svn
<paris> then u branch that branch
<paris> going to be quite the ride trying to get our CI servers to use bzr, but i'm really liking how its all setup
<lifeless> paris: what CI do you use?
<paris> lifeless: quickbuild
<paris> we've had luntbuild, played with hudson/bamboo/cruisecontrol, etc but they are too simple
<lifeless> wow
<lifeless> you must have pretty intesnse hneeds - hudson is extremly capable of just about anything
<bob2> lifeless: how heavy is hudson?  could I run a master and slave in 360MB of ram (assuming test suites take negligible amounts)?
<maxb> I used to think hudson was great, but I've grown somewhat disenchanted with it now it takes 20 minutes to restart, because it's sitting there parsing all of its on-disk XML
<lifeless> I haven't directly used the others; I know a bamboo dev, but I don't imagine that menans a lot - the lead time on infrastructure changes could be pretty big in dev-cycle time
<lifeless> bob2: dodgy
<lifeless> bob2: would depend on how many plugins you have I suspect
<lifeless> maxb: set a retention policy for jobs is one workaroundl; the other is to wait for em to fix it :P
<bob2> lifeless: dang
<lifeless> 360MB is barely enough to run a browser
<lifeless> :P
<paris> having build configurations with inheritance, is very powerful
<paris> we can just create a new configuration to follow our svn naming pattern, and depending on where we place it, it can do deployments, release management, etc
<bob2> haha, just wanted to not pay a lot to host it
<lifeless> intersting
<lifeless> uhm, I suspect there is something /like that/ in oe of the job parameterisation things
<lifeless> bob2: we're currently running it on a cheap linode, and its happy enough
<lifeless> bob2: I'm currently doing the migration to move it into the dc
<lifeless> paris: anyhow, we'll be delighted to help you get it using bzr
<lifeless> (it == quickbuild)
<paris> lifeless: thanks :), its really just a matter of some ant scripts with command line, i tend not to depend on gimmies from CI systems because it locks you into their build process
<paris> let alone take the time to build a plugin to support a new VCS
<lifeless> ok, time to fly. ciao.
<poolie> hello all
<spiv> Morning.
<poolie> hi spiv
<jelmer> ascii_phil, still there?
<thumper> morning
<thumper> how do I find out the last revision id that a particular file was modified in?
<thumper> mainline revision id is fine
<Peng> thumper: bzr log some/file?
<thumper> Peng: using bzrlib?
<thumper> I don't care about the history, or what changed
<thumper> just the revision id of the last change
<Peng> Sorry, I dunno.
<jelmer> thumper: Something like:
<jelmer> tree.inventory[tree.path2id(path)].revision
<poolie> hi peng, jelmer, thumper
<jelmer> 'morning poolie
<Peng> Hi poolie. :)
<thumper> jelmer: thanks
<thumper> jelmer: is that mainline revision, or any revision?
<thumper> hi poolie
<jelmer> thumper, the revision in which it was originally changed, not the revision in which it was merged into mainline
<thumper> jelmer: ok
<thumper> >>> wt.inventory[wt.path2id('FrontPage.txt')]
<thumper> InventoryFile('frontpage.txt-20100307092531-ok8yvr7j90c7ulee-2', u'FrontPage.txt', parent_id='tree_root-20100307084431-gmml6lwzcqlftotj-1', sha1=None, len=None, revision=None)
<thumper> jelmer: why is revision None?
<jelmer> thumper: Was that file changed in the working tree?
<jelmer> thumper: I think you might have to look in wt.basis_tree() rather than wt itself
<thumper> jelmer: no
<thumper> jelmer: it was commited as revision 1
<thumper> jelmer: unmodified in the working tree
<thumper> jelmer: wt.basis_tree()... gives a revision
<thumper> any idea why the working tree inventory doesn't?
<thumper> seems a bit strange
<thumper> poolie: is that a bug? ^^^
#bzr 2010-03-18
<jelmer> thumper: I'm not sure why it isn't there for the working tree, it's strange indeed. I could imagine it being None for files that have changed (since their current state is not in any revision yet) but not for unchanged files.
<thumper> I guess I could file a bug, it can always be marked invalid :)
<poolie> thumper: it's not a bug
<poolie> files in the wt don't have a revision
<thumper> poolie: even when they are versioned?
<thumper> poolie: it has a parent_id
<thumper> poolie: hence my confusion
<spiv> thumper: a working tree is a revision-under-construction, conceptually.
<thumper> spiv: it'd make sense to me then to not have a parent_id for the InventoryFile from a working tree
<spiv> Well, it knows the parent.
<thumper> at least then it would be internally consistent from my point of view
<poolie> thumper: nb the parent is the parent directory
<thumper> spiv: so why doesn't it know the revision?
<poolie> thumper:  what revision do you want it to be?
<poolie> the one where it was last modified?
<thumper> poolie: that is what I would expect, yes
<poolie> but then what if it's been modified on disk?
<spiv> Or the one it is about to be when you type "bzr ci" ;)
<poolie> if we leave it the same, there is a big risk of bugs
<poolie> if we perhaps set it to None in that case, that requires reading the whole file to determine this property
<poolie> which would tend to make things slow
<thumper> I'm not sure, I'm just starting to play with bzrlib internals
<poolie> so
<poolie> if you want to find out "for the unmodified files, tell me which revision they came from"
<poolie> this necessitates doing a diff type operation
<poolie> so you have to do iter_changes
<thumper> poolie: so what is the parent_id of an InventoryFile?
<thumper> poolie: all I want to find out is the last revision a particular file was modified in
<spiv> thumper: the file_id of its containing directory
<thumper> poolie: which I get from wt.basis_tree().inventory[file_id].revision
<thumper> poolie: which is what jelmer said
<poolie> or something equivalent to that
<poolie> we should document that more
<poolie> thumper: yes that's the best way to get it
<thumper> cool
<poolie> assuming you don't care about uncommitted changes
<thumper> poolie: for what I'm doing, there aren't any uncommitted changes
<poolie> k
<poolie> you don't even have to use a wt if you don't need one
<thumper> poolie: it makes for fast file access
<thumper> poolie: for the tip revision
<thumper> that is my current reasoning
<thumper> I may change later to just using in memory trees
<thumper> but getting something working first
<poolie> please file bugs tagged 'doc api' if something is not sufficiently explained, or perhaps just send one email describing everything
<poolie> and i will try to make it better
<thumper> poolie: where are the existing docs on the api?
<thumper> poolie: I'm just working from mwhudson's pydoctor files right now
<thumper> poolie: if there are some conceptual overviews that'd probably help
<spiv> thumper: In addition to the pydoctor docs there is http://doc.bazaar.canonical.com/bzr.dev/developers/
<thumper> spiv: thanks, I'll take a look
<spiv> Primarily the "Developing using bzrlib" section, I guess.
<spiv> But there might be some relevant info in the other sections, e.g. if you want to use bzrlib's testing facilities in your test suite.
<thumper> yeah, I'm using TestCaseWithTransport
<thumper> I'm actually quite keen to learn more of the bzr internals
<thumper> I may even submit some patches :)
<poolie> cool
<thumper> one day...
<poolie> this really is a good chance to improve the api docs
<thumper> I'll try to make notes of my pain points
<poolie> lucid needs to reboot now, biab
<mwhudson> i guess i could try to put my editable version   of the apidocs online again
<poolie> mm
<poolie> you're welcome too, but i think it will become a dead end
<poolie> i think what we need is not a gloss written onto the api docs, but rather people asking questions that actually drive improvements in the docs instead
<mwhudson> probably
<poolie> like a footer on all of them saying "if this is unclear ask in #bzr and we will improve it"
<dvheumen> hi poolie. about the contributor agreement. I forwarded your reply to me with the agreement and my text, but maybe that's what killed the process?!?
<dvheumen> :P
<dvheumen> In that case, I could send a clean version again
<dvheumen> ... and I didn't CC you, only sent it to contributor-agreement@canonical.com
<poolie> would you please forward that mail to me?
<dvheumen> ah, whoops, I missed the second part of that sentence saying I should CC you :P
<dvheumen> forwarding ...
<spiv> dvheumen: ah good, I'm looking forward to your patch landing :)
<dvheumen> spiv, well, it's not that spectacular :), but thanks for saying that ;)
<dvheumen> poolie, mail should arrive shortly
<poolie> k thanks
<dvheumen> okay, since you've got the Agreement, everything should be alright. I'm gonna call it a night.
<igc> morning
<moldy> hi
<moldy> can i easily merge a single directory of another branch into my branch while keeping history?
<bob2> no
<moldy> hm, ok :-/
<moldy> bob2: how would you approach this?
<spiv> moldy: the two basic options are "lose the history" and "merge the whole other branch in but then undo the changes from outside the directory you want."
<moldy> spiv: hm, ok, thanks.
<moldy> if i deleted a directory, how can i view the log for that directory? "Path unknown at end or start of revision range"
<Peng> moldy: If you can remember when you deleted it, 'bzr log -r <some rev where it existed>'
<moldy> Peng: hm, ok, thx
<poolie> hi igc
<thumper> poolie: any way to tag an individual file?
<poolie> thumper: i just answered the question about it
<poolie> no
<thumper> poolie: thanks
<vila>  hi all
<gour> hello
<gour> jelmer is the author of bzr-svn?
<vila> gour: yes he is
<gour> vila: i had some crash in bzr explorer while fetching from svn repo, but would like to send paste before opening ticket (http://dpaste.com/173190/) - maybe it's just network problem
<vila> gour: well, 'could not connect' indicates either a network problem or an authentication problem
<vila> gour: try connecting with the svn client itself and, except if the problem is transient) file a bug
<gour> vila: thanks. it may be network problem then...it fetched quite a lot from the repo before crashing
<gour> ok
<gour> vila: svn did the job
<vila> gour: bug filing time it is then
<gour> vila: ok
<igc> bbiab
<echo-area> spiv: ping
<knielsen> bzr has per-file changeset comments (implemented for MySQL I think). They can be added with `bzr gcommit`. But is there any way to view them? I couldn't find any ...
<vila> oh boy, how I hate linux when it starts thrashing...
<GaryvdM> knielsen: I believe with bzr glog
<vila> knielsen: bzr viz (GaryvdM you insensitive clod !)
<knielsen> ok, thanks! (glog is a plugin I guess?)
<vila> GaryvdM: may be we should just add glog as an alias for viz in bzr-gtk ;-)
<vila> knielsen: it's part of bzr-gtk
<GaryvdM> vila: Oh. I thought that was allready the case.
<knielsen> vila: hm, strange, I have bzr-gtk but don't seem to have glog ... anyway, I'll check it out
<GaryvdM> knielsen: I thought it was glog, but it is bzr viz
<vila> knielsen: GaryvdM thought about qlog in qbzr plugin but it's called viz in the bzr-gtk plugin
<knielsen> hehe, ok :)
<vila> knielsen: sorry for the confusion
<spiv> echo-area: pong
<spiv> echo-area: I'm only half around...
<vila> knielsen, GaryvdM, jelmer : I've just pushed to lp:bzr-gtk the alias addition, so there
<GaryvdM> :-)
<knielsen> ok, I see, that works, thanks! I guess there is no command-line way to see the comments?
<vila> GaryvdM: Wow, just tried 'bzr qlog' in a directory (below a shared repo) without branchs in it (but still branches in sub dirs)
<vila> GaryvdM: I got a message on the console but a blank (well grey) screen....
<knielsen> (probably `bzr log --verbose` should show them, if anyone cared enough to add that)
<knielsen> I guess MySQL is probably the only project to use per-file comments anyway ...
<vila> knielsen: it's implemented as a revision property, which are quite arbitrary (and in that case encoded in a non-trivial way), so bzr itself can't just display it properly
<vila> knielsen: a specific log formatter can, you may want to file a bug asking for one
<knielsen> vila: ok, I see, thanks for info
<echo-area> spiv: Okay, so let's talk tomorrow.  I just checked our last dialogue, and you are off the day by now :)
<GaryvdM> vila: my 3g went wonkey, so I may have missed messages. The last thing I saw was: "GaryvdM: I got a message on the console but a blank (well grey) screen..."
<vila> GaryvdM: that was it
<GaryvdM> vila: what was the message?
<vila> GaryvdM: not a branch
<GaryvdM> Vila: ok. I'll log a bug. It should be able to handel that.
<vila> GaryvdM: sure, that's the first time I encounter it and I was a bit surprised that I needed to *kill* the window, clicking the close button seemed unresponsive
<GaryvdM> vila: Can you reproduce the hang?
<vila> just a sec
<vila> WOW
<vila> I can't
<vila> I just get the error message and the qlog just quit
<balor> So I've merged something onto my mainline.  I've now got a BASE OTHER and THIS file for one file.  What's the best way to merge all this?  Do I meld OTHER and THIS onto BASE or some other permutation?
<vila> amazing, ok, forget it, I can't reproduce
<vila> balor: 'file' itself already contains all the merged stuff and the conflicted regions enclosed with markers
<balor> vila: I can see that.  But is there a tool that lets me choose between chunks, rather than simply editing the file in emacs?
<vila> balor: man, if you use emacs try smerge !
 * vila checks how smerge is configured here
<vila> balor: hmm, just opending a conflicted file is enough to trigger smerge here
<balor> And if I wasn't an emacs user, is there another tool?
<vila> Ha, that maybe because I use dvc
<vila> yes meld certainly, but I don't use it (I've just installed it, gimme a sec)
 * vila thought meld could be triggered automatically frombzr
<balor> ah! bzr-gconflicts
<balor> It'll set up meld correctly to do the merge
<vila> balor: starts meld automatically ?
<vila> good
<vila> balor: try pinging GaryvdM when he come back, I'm pretty sure qconflicts (from qbzr) can do that too
<balor> Hmm....I still have to copy foo.c.BASE over foo.c after the merge
<vila> balor: you still need to to 'bzr resolve file'
<vila> s/to to/to do/
<alf_> Hi all, I have been using bzr explorer to read the history/logs of specific files and directories.
<alf_> Due to the depth of the history (>40000) this takes a while. Is there a way to speed things up? Would indexing using "bzr index" help here?
<jelmer> alf_: Hi
<jelmer> alf_: No, bzr index is just used by "bzr search" - it won't speed anything up
<jelmer> alf_: Do you have the Bazaar C extensions compiled?
<jelmer> alf_: And are you using a recent version of Bazaar?
<alf_> jelmer: I am using bzr 2.1.0 from debian testing
<alf_> jelmer: The good thing is that bzr explorer incrementally displays the matching commits as it finds them. It still takes a lot of time to process them all, however.
<alf_> I am guessing it is just searching all commits and just displays ones that match?
<jelmer> alf_: You're just browsing aren't you?
<jelmer> alf_: Or are you doing something more complex than that?
<igc> night all
<alf_> jelmer: in the file browser I am selecting a file/directory and clicking show log in the context menu
<jelmer> g'night Ian!
<dcoles> jelmer: Would you believe I'm having trouble with bazaar and urlsplit again...
<dcoles> This time with bzr-git...
<jelmer> dcoles: You're running Lucid I bet?
<dcoles> Yes. Someone changed the behaviour of urlsplit?
<jelmer> dcoles, Yep, upstream python did
<jelmer> there's a fix for it in bzr-git trunk
<dcoles> (Since I can no longer reproduce the behavour that was breaking bzr-svn)
<jelmer> the behaviour in bzr-svn was unrelated to Python
<dcoles> Ah. Cool. I had just started to monkey-patch and then noticed that bzr-git already "did the right thing"
<bialix> jelmer: hi
<bialix> jelmer: can we chat about Bug 540363
<ubottu> Launchpad bug 540363 in qbzr "SVN Commit throws 'SvnBranch' object has no attribute 'control_files'" [High,Fix released] https://launchpad.net/bugs/540363
<jelmer> bialix, hi
<jelmer> bialix, sure
<bialix> in qcommit we're trying to store some data in branch.conf
<bialix> IIUC SvnBranch has no branch.conf?
<bialix> so my fix to use Branch.get_physical_status instead of bzranch.control_files might be incorrect at all?
<jelmer> bialix: To access branch.conf you should use Branch.get_config()
<bialix> jelmer: maybe I should skip work with branch.conf at all for SvnBranch? Or even for all non-BzrBranches?
<bialix> jelmer: we're using Branch.get_config()
<jelmer> bialix: bzr-svn will return a config object if you call get_config() on a SvnBranch
<jelmer> bialix: but will store/retrieve in branch.conf but elsewhere
<bialix> jelmer: here is the code: http://pastebin.com/kTCkCkic
<bialix> self._get_branch_config() == Branch.get_branch_config()
<jelmer> Branch.get_config() you mean?
<jelmer> Anyway, that should work
<bialix> yes, get_config, sorry
 * jelmer gets dragged to lunch
<bialix> bon appetit
<bialix> thanks, jelmer
<smoser> Hey all, I know this isn't bzr specific, but expect someone would know an answer here.
<smoser> I'm looking at http://bazaar.launchpad.net/%7Esmoser/%2Bjunk/ec2-test/files/head%3A/user-data/ , and want to include a download link to the 'head' version of one of the files there
<smoser> include-compressed-script-01.txt.gz specifically
<smoser> the 'download file' link seems to be a premenant link to the head at the time i grab it.
<james_w> smoser: you can probably mangle the link
<smoser> i would have thought so. but it seems to have some data in it.
<smoser> http://bazaar.launchpad.net/%7Esmoser/%2Bjunk/ec2-test/download/head%3A/includecompressedscr-20100318141221-ewki6l3sasp5rmny-1/include-compressed-script-01.txt.gz
<smoser> and its missing the path (user-data/), so i wasn't sure
<james_w> interesting
<james_w> beuno: around? ^
<james_w> smoser: it still seems to be pointing to head: though, so should work
<james_w> it will break if you bzr rm and then bzr add that file
<smoser> well, it doesn't. i upated the file and the old link didn't work.
<smoser> well, it worked, but got the old version
<james_w> very odd
<smoser> yeah, i suspect user error.
<smoser> maybe i checked before new version had updated
<james_w> ah, there is probably a lag of a minute or two after you push
<beuno> james_w, hi
<beuno> yeah
<beuno> so loggerhead is on the public area
<james_w> hi beuno
<beuno> which has to wait for the puller to bring it in
<beuno> so there is a delay
<NfNitLoop> Hrmm.  I'm helping a coworker learn/use bzr and bzr-svn.  He's used git before, and I think he's familiar with hg as well.  But he seems to be having a hard time with some of the concepts.  I may not be the best teacher. :/
<NfNitLoop> Like, it's confusing to him that each branch is a separate directory since in bzr & hg that's handled in SCM metadata w/o the need for another directory.
<NfNitLoop> and he's not quite understanding the difference between a "parent" branch and a "bound" branch.
<NfNitLoop> OTOH, the problem could just be that he hasn't read any bzr docs and is relying on me to tell him everything. heh.
<fullermd> I'm of the belief the former is easier to grasp by thinking strictly about the 3 components, and which are present in a given location.
<fullermd> For the latter, _I_ like solving it by killing "bound".  With fire.    :)
<NfNitLoop> hehe.
<fullermd> But that's more like a troll than a solution...
<NfNitLoop> Well, we have a rather large tree, so it's handy to bind it to branches, do some work, bind to a different branch, do some other work...
<NfNitLoop> instead of creating N working copies, or doing 'bzr checkout .' 'bzr remove-tree' all the time.
<NfNitLoop> but yeah, he tried to rebase in a bound branch and... things did not go well. :p
<fullermd> What's the advantage of bounding, rather than using a light checkout and switch?
<NfNitLoop> eh, it's in a shared repo, bind and switch,  light checkout and switch.   Not much difference in that case, right?
<fullermd> Clarity about what's going on.
<fullermd> It would be better modelling it as a heavy checkout and switch, than as a bound branch.  But with it all being local, light checkout is conceptually a step closer.
<NfNitLoop> does the behavior differ?
 * fullermd covertly looks around for anybody who'll call him on trolling like this...
<NfNitLoop> I thought the only difference is that a lightweight checkout doesn't have local history.
<NfNitLoop> but otherwise all operations between a light/heavy checkout should be the same?
<NfNitLoop> (and a bound branch == a heavy checkout.)
<fullermd> Well, see, that's the thing...
<fullermd> In implementation, they are, which is the root of confusions.  In concept, they're not.
<fullermd> And in concept, what you're using here is a checkout, because what you want is just a working tree on a branch (in a serial-monogamy sort of sense).
<fullermd> And (IMAO) that's a lot easier to explain and grasp if explained as a checkout (working tree) moved among branches via 'switch', than as another branch with a special bound property that causes certain automatic interations with this other branch.
<NfNitLoop> Oh.  Yeah.
<NfNitLoop> Only at this point, changing his workflow more would be counterproductive.
<fullermd> Oh, just reboot 'im.  The POST will wipe out the old habits.
<NfNitLoop> heh.
<NfNitLoop> I think he'd be a lot less confused if he'd started with the bzr tutorial and learned the concepts first.
<NfNitLoop> instead, he looked at a wiki page I wrote about the workflow I use to interact with our SVN repo.
<NfNitLoop> thought "Git's close enough" and started using my workflow.
 * fullermd really should write up his model docs sometime   :|
<NfNitLoop> without quite understanding it.
<fullermd> Well, look at the bright side; if the version control usage doesn't pan out, he's still got a good future in politics   8-}
<MTecknology> What would cause this? bzr: ERROR: Cannot lock LockDir(http://bazaar.launchpad.net/~ubuntu-drupal-devs/ubuntu-drupal-theme/6.x-orange/.bzr/branch/lock): Transport operation not possible: http does not support mkdir()
<fullermd> Trying to write across http.
<MTecknology> fullermd: that happened when I just rant bzr commit -m "..."
<fullermd> Which suggest that somewhere prior to that you did "bzr checkout http://...."
<MTecknology> I grabbed it with bzr branch lp:..
<MTecknology> I even tried on a fresh branch
<fullermd> If you're not logged in (bzr lp-login), lp: resolves to a read-only http:// URL.
<MTecknology> oh..
<fullermd> If you lp-login, it'll resolve to a writable (assuming you're in the right group anyway) bzr+ssh:// url, so you could lp-login, and then "bzr switch lp:..." to swap over to the writable protocol.
<MTecknology> why does it need to use the web if I'm only doing a commit on a branch grabbed using bzr branch? I thought that usually meant everything happens local until a push
<fullermd> It doesn't, if you made a _branch_ with "bzr branch".  But in this case, you made a _checkout_ with "bzr co" (or possibly altered the branch later with 'reconfig' or 'bind')
<fullermd> Check "info".
<MTecknology> oh.... i get it now
<fullermd> (if you expect and _want_ a separate branch, definitely check before you switch and commit and maybe push it upstream before you intend to)
<MTecknology> I ran bzr branch lp:.. but because I didn't do lp-login, that's why it did http
<MTecknology> I thought you meant that had to do with the commit
<MTecknology> fullermd: thanks
<fullermd> Well, commit wouldn't try to write to the upstream if it were just an indepdendent branch.
<fullermd> It would only do that if you somehow ended up with a checkout/bound branch.
<poolie> hi igc, lifeless, spiv, jelmer,
<lifeless> poolie: the robert has landed
<poolie> ah, you're in the other Commonwealth?
<lifeless> poolie: yup
<lifeless> about to go to the pre conf dinner I think
<poolie> enjoy
<lifeless> I got some good stuff done on the plane; I took lynnes new eeepc - huge battery life
<fullermd> Wait...   if there's an "other", they're no longer common wealths anymore.
<igc> morning
<igc> hi poolie
#bzr 2010-03-19
<poolie> igc is explorer now in the mac packages?
<poolie> re bug 483083
<ubottu> Launchpad bug 483083 in bzr-mac-installers "No bzr-explorer in Mac desktop bundle 2.0.1" [Undecided,Confirmed] https://launchpad.net/bugs/483083
<poolie> mwh, spiv does python -O do anything aside from turn off assertions?
<mwhudson> poolie: it makes __debug__ 0
<poolie> and anything else?
<poolie> python -h says "optimize bytecode slightly"
<mwhudson> i didn't think that was controlled by -O
<poolie> this is re bug 147927
<ubottu> Launchpad bug 147927 in bzr "use python -O (assertions off) when running installed copy" [Low,Confirmed] https://launchpad.net/bugs/147927
<spiv> poolie: what mwhudson says
<spiv> I think the "optimize bytecode slightly" is alluding to omitting the bytecode of "if __debug__:" blocks.
<poolie> so the bug's obsolete?
<spiv> I think so, yes.
<spiv> And we've sort-of replaced what that would do with the -D flags.
<poolie> which are better i think
<poolie> ok closed
<jelmer> If somebody could review https://code.edge.launchpad.net/~jelmer/bzr/branch-names/+merge/21197 that would be much appreciated, it's the next step for colocated branches.
<poolie> it was on my list but it's a long list :)
<poolie> so
<poolie> it looks pretty good
<poolie> i had some qualms about the earlier patches needing to insert 'name' into quite so many places
<poolie> but it's not really your fault
<poolie> i feel those classes could do with a scrub
<poolie> do you want to talk about that patch or do you just want a +1?
<jelmer> poolie: I'm happy to talk about it
<poolie> i mean, do you have any concerns?
<poolie> it looks ok to me
<jelmer> poolie: Ideally I'd like a +1 but it'd also be good to know what you think of the general direction my patches are going in and what plans you have for that API in general.
<poolie> i think it's good
<poolie> i feel there's a lot of duplication in bzrdir.py
<jelmer> poolie: Yeah, there's quite a few places that have a name parameter. I'm not sure how we could best abstract that out though.
<poolie> anyhow
<poolie> i don't think we should block your stuff
<poolie> if you get around to deleting a lot of code from bzrdir or branch.py it would make me happy :)
<jelmer> ok :-)
<igc> poolie: explorer is in the mac packages for Snow Leopard (10.6) but not earlier IIUIC
 * igc out for a few hours
<poolie> thanks
<echo-area> spiv: hi
<echo-area> spiv: https://bugs.launchpad.net/bzr/+bug/537888  <---  This link contains my patch to the doc.
<ubottu> Ubuntu bug 537888 in bzr "on documentation of stacked branches" [Medium,In progress]
<spm> poolie: should be able to review (properly, skim read looks fine) and get that in this arvo.
<poolie> no rush
<poolie> hello echo-area
<echo-area> poolie: hi
<poolie> oops, i started a proposal for that but i didn't paste the link
<poolie> spiv, want to read https://code.edge.launchpad.net/~mbp/bzr/doc-stacking/+merge/21694
<spiv> echo-area: will look, thanks!
<Adys> Is there a way to force a revert even if it ends up in an error (file not versioned, ...) ?
<spiv> Adys: what error are you getting?  revert should always work I think.
<Adys> adys@azura:~/src/bzr/xflight$ bzr revert *.txt
<Adys> bzr: ERROR: Path(s) are not versioned: CMakeCache.txt
<spiv> Oh, I see.
<Adys> i dont see a --force option
<spiv> revert thinks you're trying to revert a file it doesn't know anything about, but I guess what you actually want is for it to ignore the unversioned file(s) matched by *.txt and revert the rest?
<spiv> I suppose you could do something like: bzr revert `bzr status -S -V *.txt | cut -b 5-`
<spiv> But I don't think we have a builtin option for that, but it would be good to add.
<spiv> Adys: I've filed https://bugs.edge.launchpad.net/bzr/+bug/541676
<ubottu> Ubuntu bug 541676 in bzr "Add --ignore-unversioned option to revert" [Low,Confirmed]
<Adys> cheers spiv
<Adys> and ya its not a big deal to me, just thought it'd be something good to have builtin as well
<igc> back
<nlisgo> Is there a way to return a list of files that have changed from revision x to the latest revision
<nlisgo> And then to create a patch file between a specified version and the latest revision
<bob2> well, the latter is easier
<spiv> nlisgo: for the latter: bzr diff -r REV..-1
<spiv> nlisgo: (although you may find 'bzr send' to be better than generating plain diffs, depending on what you are doing)
<spiv> nlisgo: for the former: bzr status -r REV..-1
<nlisgo> thanks very much spiv. I shall give them a go.
<nlisgo> That worked fantastic spiv. Thanks very much!
<nlisgo> what would the command be for send?
<nlisgo> bzr send -o -r REV..-1 > patchfile
<thumper> igc: ping (perhaps)
<nlisgo> bzr send ./ -o ../myfile.patch -r REV..-1
<spiv> nlisgo: typical use of 'bzr send' is to tell it which branch you are 'sending' to
<spiv> nlisgo: and then it works out exactly what info to include
 * spiv is off for the day
<spiv> G'night all!
<nlisgo> spiv: night - thanks for help
<spiv> nlisgo: no probs
<vila> hi all, oops forgot to do that hours ago
<vila> Is there some lovely LOSA around to have a look at pqm, it seems hung in an unusual way
<vila> i.e. the make has been done but the selftest step reported nothing for... ~1 hour
<gioele> I have problems branching from an SVN repository. bzr keeps saying Â«bzr: ERROR: Not a branch: "/branches/src/gioele-api/XXX".Â». I successfully branched from other branches of the same SVN in the past. How can I debug this?
<jelmer> gioele: what does "bzr svn-layout" on that repository tell you?
<gioele> jelmer: that I have to modify ~/.bazaar/subversion.conf ;)
<igc> hi jelmer, vila
<igc> thumper: pong
<jelmer> 'morning Ian, Vincent
 * vila waves back
<bialix> hi guys
<vila> huh ? No more bzr_man.html created by 'make docs' ? What did I miss ?
<vila> wow, that was already lost in 2.1
<vila> igc: does this ^ ring a bell ?
<bialix> vila: I guess it was the part of what igc did for new documentation
<igc> hi bialix
<bialix> do you really need an html?
<bialix> hi igc
<vila> I need to test modifications to bzrlib/help_topics/en/configuration.txt
<igc> vila: I think the file is now called index.html
<vila> whre ?
<igc> under doc/en/user_reference
<vila> try it, no index.html there
<igc> vila: do you have sphinx installed?
<vila> I ran 'make docs' and got no complains,
<vila> I then installed sphinx, search the makefile, run make html-sphinx, still no sugar
<igc> make docs is the docutils stuff which is effectively dead
<vila> it ends up saying The HTML pages are in _build/html but there is no _build dir here
<vila> nm, let's start again
<igc> try doc/en/_build/html
<vila> I need to test modifications to bzrlib/help_topics/en/configuration.txt, what should I do ?
<igc> the _build directory is relative to the sphinx config file (in doc/en)
<bialix> vila: bzr help conflicts? :-P
<bialix> rats
<bialix> typo
<bialix> heh
<igc> vila: make html-sphinx is the right command
<igc> look in doc/en/_build/html for the results
<vila> igc: there are also quite a few warnings during make html-sphinx
<igc> vila: yes, I/we need to fix those
<igc> vila: the old docutils stuff has to go first
<vila> indeed
<igc> because many of the warnings are a consequence of trying to support do slightly different doc systems
<vila> where is configuration.txt output now then ?
<igc> s/do/two/
<igc> under doc/en/_build/html/user-reference
<igc> vila: it will be called configuration-help.html
<igc> vila: the -html prefix is necessary to prevent namespace clashes with std sphinx docs (like search.html)
<vila> ENOTFOUND
<igc> vila: is anything in doc/en/_build?
<vila> doc/en/_build/html/user-reference/configuration-help.html finally
<vila> now, how do I know what kind of markup can be used ?
<igc> vila: good question :-)
<igc> vila: you can use any sphinx markup you like for nice html
<igc> vila: the trouble is nice text for command line users
<vila> :-/ Ok, nm, the table of contents answer my precise question here, I used the wrong underline char before, now it's indeed a subsection
<igc> so we tend to stick with plain text with some limited markup
<igc> i.e.
<igc> :: at the end of a line for introducing examples
<igc> :doc:`foo-help` for cross-references (get turned into `bzr help foo` in the text output
<vila> yeah, except I have some text to describe the example so using Examples:: doesn't work, I can use it for each example though
<vila> cough, sphinx always rebuild everything ?
<igc> vila: inside command docstrings, subsections like Examples can be introduced by using :Examples: and indenting text within that by a character
<vila> :text: what's that ?
<vila> rest ? sphinx ?
<igc> vila: have a look in builtins.py at cmd_log for example
<igc> :text: is a bzr-ism for marking subsections inside a docstring
<vila> I'm not inside a docstring
<igc> vila: it doesn't apply to a plain text file though
<igc> vila: here's the doc on sphinx: http://sphinx.pocoo.org/contents.html
<vila> ha good
<vila> thx
<vila> does it generate texinfo output ?
<vila> :-P
<vila> LaTeX files ! I feel younger by the minute :)
<igc> vila: :-)
<igc> vila: we generate our PDF manuals via LaTeX fwiw
<gioele> if I "bzr push" an svn imported branch, will this create an svn commit for each bzr commit?
<vila> from latex files getting texinfo should be trivial (at least in theory, oooh, I love those theories :)
<igc> vila: however, we don't have a PDF verison on the User Reference because ...
<igc> keeping things working for docutils means that sphinx can't build the LaTeX
<igc> hence my keenness to drop support fro docutils
<igc> gioele: I believe so but jelmer will know for sure
<jelmer> gioele, for every commit in mainline, yes
<gioele> jelmer: with which date? all with the current date and time?
<igc> got to go
<igc> night all
<vila> igc: thx for the help and last question: our official doc in the sphinx one now right ? At least for 2.2 ?
<vila> igc: it would be good to clarify things a bit here
<mok0> Hi, any bzr devs around for a couple of questions? I am working on backporting bzr to hardy and would like to clarify whether there are anything to be concerned about
<spiv> mok0: there are hardy packages in the bzr PPA: https://edge.launchpad.net/~bzr/+archive/ppa?field.series_filter=hardy
<mok0> spiv, I know
<mok0> spiv: I'd like to hear to what extent they have been tested
<spiv> AFAIK they work just fine.  I don't know of any reports of problems.
<mok0> spiv: any pitfalls we (backporting team) should be aware of?
<spiv> The main issue we've had with packaging has tended to be making sure the plugins are all up to date with the version of bzr
<mok0> spiv: OK, sounds good
<Peng> Do you mean packaging issues or bzr issues? I run from source on Hardy and have had no issues.
<mok0> Peng, I mean issues with the plugins. I also have no problems with bzr iteself
<spiv> So bzr itself doesn't have very tough dependencies (just Python, basically), but if you upgrade bzr without upgrading plugins that tends to cause grief if you expect e.g. bzr-svn to work.
<mok0> spiv: right. subvertpy is on it's way to the hardy backports archive as we speak
<spiv> mok0: *nod*
<mok0> spiv: When that becomes available, I can test bzr-svn etc.
<spiv> mok0: packages that depend on bzr (mainly just plugins, although maybe also loggerhead?) is where I'd expect potential problems.  So if you're aware of that then I think you know about as much as I do :)
<mok0> spiv: I wasn't, thanks,
<spiv> In terms of testing, we do occasionally hear people grumble when we break or not update the PPA, so I assume people are testing it.  It'd be nice if LP could give some sort of stats that indicate usage though.
<mok0> spiv: Indeed it would
<spiv> (Easier said than done, I'm sure)
 * spiv -> bed
<mok0> Heh
<spiv> mok0: good luck, and thanks for backporting :)
<mok0> spiv: goodnight spiv, and thanks
<mok0> My pleasure :-)
 * mok0 < lunch
<andyjb23> is there a way of installing bzr 1.18 on fedora 12?
<Peng> bzr 1.18? Why? That's quite old.
<andyjb23> i know, but a project i'm working on needs 1.18 to work properly
<Peng> ...Why?
<andyjb23> i don't know, i haven't worked on it myself yet
<Peng> Bazaar is nearly completely backwards-compatible...
<bialix> I suspect their need <2a format
<bialix> andyjb23: I can suggest format1 plugin to force using old default format with bzr >= 2.x
<andyjb23> what does that mean?
<bialix> the main thing changed between 1.18 and 2.x is new default repository format, now called 2a
<bialix> my plugin force to use old format named pack-0.92 instead
<Peng> IIRC 1.18 supports 2a, though. It probably sucks a bit, but it works
<bialix> you may ask your team about the reasons behind 1.18
<Peng> You don't need the plugin. It's just so that you don't have to remember to do "bzr init-repo --pack-0.92". Which is good.
<bialix> Peng: if you have to support even older bzr clients, believe me you don't want to use 2a
<bialix> also 2a is rich-root format. and therefore any unexpected format upgrade will give you big problems
<andyjb23> so do i need this plugin or just to use --pack-0.92 every time i use bzr?
<bialix> it's up to you
<andyjb23> but both make it behave like bzr 1.18?
<bialix> but you'd better to understand the reasons behind the choice of 1.18 only
<bialix> andyjb23: not really
<andyjb23> bialix: this is my first encounter with bzr, i'm just following instructions written by someone else on the project about a year ago
<andyjb23> i will ask when he wakes up though
<bialix> 1.18 was released about half year ago
<bialix> one can't write such instructions 1 year ago
<andyjb23> hold on, history says instructions are 5 months old, sorry
<Peng> andyjb23: Please do ask him. It most likely isn't actually necessary to use an old version.
 * bialix nods
<andyjb23> thanks
<luke-jr> is it possible to retroactively revert a revision?
<luke-jr> eg, remove the revision (and its modifications) from the branch's history completely
<lifeless> uncommit
<NfNitLoop> luke-jr: Not once that revision is public.
<NfNitLoop> by which I mean, in someone else's repository.
<NfNitLoop> If that revision is only on your disk, you could branch from the point before that revision...
<NfNitLoop> then replay all of the history after that onto the branch.
<NfNitLoop> and throw away your "tainted" branch.
<luke-jr> NfNitLoop: can the replay part be automated sanely?
<luke-jr> /easily
<NfNitLoop> I *think* rebase might be able to do that?
<luke-jr> hmm
<luke-jr> I thought rebase was a git cmd
<NfNitLoop> there's a bzr-rebase plugin.
<luke-jr> ah
<luke-jr> ok
<luke-jr> I'm considering releasing some internal code, but I'd need to strip customer-specific changes ;)
<NfNitLoop> the problem is...
<luke-jr> not a good idea to publish customer credit card numbers and such :)
<NfNitLoop> those branches would be divergent.
<luke-jr> hmm
<NfNitLoop> meaning you wouldn't be able to merge from that branch to your internal branch.
<NfNitLoop> because "rebase" basically takes the commit message and the diffs and commits them as completely new (unrelated) revisions.
<luke-jr> what if I do the branching inside Subversion using cherry-picking, and use bzr-svn to bridge with the real world?
<NfNitLoop> so a merge across those branches would see them as needing lots of merging.
<luke-jr> since Subversion supports cherry picking properly
<NfNitLoop> Sure, that could work.
#bzr 2010-03-20
<bignose> I'm just now learning about the pipeline plugin.
<bignose> I'm also totally unfamiliar with âlightweight checkoutâ.
<bignose> apparently I need to make a lightweight checkout in order to make a pipeline.
<fullermd> They're like checkouts, except not as heavy   8-}
<bignose> what's foiling me at the moment is:
<fullermd> (runner-up: They're checkouts that can't hold their liquor)
<bignose> âbzr checkout --lightweight --revision "tag:release 1.2.3" foo.upstream/ foo.patch-pipeline/â
<bignose> the result, though, is not at the requested revision; it appears to have ignored that option
<bignose> what I want is to apply an old set of patches at a corresponding old upstream version; then step through each subsequent upstream version modifying the patches accordingly as I go.
<bignose> is that an appropriate usage of pipelines?
<fullermd> Can you `branch -r [...]`?  I wonder if maybe it just doesn't like spaces in tags.
<bignose> shall check, hold on
<fullermd> However, that aside, I suspect that won't quite work anyway; with a checkout at the non-head version, you can't commit, so you'd need a branch headed there before you could move it forward.
<bignose> yes, âbzr branch --revision "tag:release 1.2.3" foo.upstream/ foo.bzr/â works. the resulting branch is at the specified revno, and all subsequent tags exist but don't know their referent.
<bignose> okay. so, given the use case, am I wasting time trying to use a pipeline?
<fullermd> Well, I don't know anything about pipeline.  But the issues sound orthogonal to me.
<fullermd> You'd just need to start the pipeline with a branch at that rev to work from.
<fullermd> How do you know the result [of the co --light] isn't at the requested rev?
<bignose> okay, so how do I start a pipeline at that rev? I can't even seem to get a lightweight checkout to work correctly.
<bignose> because âbzr revnoâ says so, and all the subsequent revision data is in the branch.
<fullermd> bzr revno gives the branch revno, not the working tree revno.  So of course it would say that.
<fullermd> (and of course all the data's in the branch; it would be Really Bad if co threw that away!)
<bignose> whereas, with a âbranchâ instead of a âcheckout --lightweightâ, the revno is as requested and the revision data isn't present.
<fullermd> Try revno --tree.
<fullermd> But at any rate, yes, you'd want a branch of the appropriate rev to start a pipeline from.
<bignose> ah yes, âbzr revno --treeâ reports the requested revno.
<bignose> I don't see why the checkout needs later revision data if I haven't asked for it yet. (seems rather un-light too!)
<fullermd> ENONSENSICAL
<fullermd> The checkout doesn't have ANY revision data.
<fullermd> Revision data is all through the _branch_.
<bignose> it makes as much sense as for âbzr branch --revision NNNâ, and that doesn't have subsequent revision data either.
<bignose> hmm. okay, clearly this is where my knowledge of lightweight checkouts fails me.
<bignose> but that may not be something I need to know yet.
<fullermd> A checkout is just a working tree.  It's no different from a WT that happens to be colocated with a branch.
<bignose> so, with the tree at the requested revno, should I then expect to be able to:
<bignose> * configure it to be a pipeline
<bignose> * apply patches
<bignose> * commit changes
<fullermd> Neither has any history, or revision info, or yada yada; when you run 'revno' or 'log' or some such, it just uses the WT to find the branch, and then does the operation on the branch.
<bignose> * update from subsequent revisions upstream
<fullermd> AFAIK, pipeline is just a layer that uses one-or-more branches to do its stuff.
<bignose> * continue converting the patches
<bignose> ?
<fullermd> My vague sense is that since abentley wrote it, he wrote it to operate in his workstyle, which is a bunch of treeless branches somewhere, and a single [light] checkout switch'd among them.
<fullermd> Which is where the co --light command you came across comes in.
<fullermd> So I'd make a branch from the upstream at whatever rev you want to start with, and then use that as the 'base' of the pipeline.
<bignose> got that far. what do I need to be careful of to make sure I can merge each patch from subsequent upstream revnos?
<bignose> s/each patch/each local patch/
<fullermd> Well, a pipeline is just an arrangement of branches.  So whatever you'd need to do with a normal branch to maintain <whatever ability>, you'd do with pipeline.
<bignose> argh, badly phrased. the patches are local, and are against a specific upstream revno. the point of the exercise is to update these local patches against later upstream revnos, one by one.
<fullermd> I've never used it, so I don't know how much complication it would add.
<bignose> okay, thanks for your help so far.
<bignose> nnngh. adding a new pipe insists on updating the checkout.
<bignose> defeating the purpose.
<bignose> argh. it's fiddling around making directories *parallel to* the branch where I'm operating?
<bignose> this is most annoying.
<fullermd> Yeah, that's what I said   :p
<fullermd> 1..N treeless branches, a light checkout switch'd among them.
<fullermd> vila: re bug 542400
<ubottu> Error: Could not parse data returned by Launchpad: list index out of range (https://launchpad.net/bugs/542400)
 * fullermd pats ubottu.
<fullermd> vila: Are you sure that's really bzr?  It seems to be pretty qbzr-entangled...
<vila> fullermd: huh, how do you know about it when it's private ?
<fullermd> I know all and see all.
<vila> fullermd: the command itself doesn't involve qbzr and I'm pretty sure I've seen a patch by NAOKI about the subprocess parameters not being encoded as they should
<vila> given that the filename is not ascii... there are good chances that it's encoded correctly :)
<fullermd> Owell.  Just wondering.  It'll get sorted out one way or another I reckon.
<lifeless> fullermd: MA is 'the commonwealth of massacheussets
<vila> Same Owell here, but I trust bialix
<lifeless> (spelling fail but still)
<bialix> hi guys
<bialix> who is summon me?
<vila> great, now I know it's not saturday :)
<bialix> it's saturday
<fullermd> lifeless: ...   well, yes, but...  EREF?
<bialix> bonjour vila
<lifeless> fullermd: the other day, poolies comment 'the other commonwealth'
<lifeless> fullermd: and youre reply :P
<fullermd> Oh.  Don't you go screwing up my word games with mundane facts!
<vila> bialix: do you remember a patch from naoki about encoding paths for subprocesses ? Could that apply to bug #542400 (and by the way, can you confirm that you too can read this bug ?)
<ubottu> Error: Could not parse data returned by Launchpad: list index out of range (https://launchpad.net/bugs/542400)
<fullermd> vila: Oh, now you're just _taunting_ ubottu.  That's just cruel.
<bialix> Not allowed here
<bialix> Sorry, you don't have permission to access this page.
<bialix> that's what I see
<vila> fullermd: I love it when it reply starts with 'Error:' :-)
<fullermd> The poor guy who registered that nick doesn't   :>
<vila> Ok, now we know we have a lp hacker around.... :)
<bialix> vila: patch from naoki? vaguely
<bialix> Qt uses unicode
<bialix> and I like that
<bialix> we need to encode data for python standard subprocess module because it can't handle unicode
<bialix> bad python
<vila> right, I think this was mentioned in the discussion and it's unclear to me if a wroking solution was found (console encoding vs fs encoding IIRC)
<vila> seriously how come fullermd can read this bug report and bialix can ?
<vila> cant
<vila> bah
<vila> seriously how come fullermd can read this bug report and bialix cant ?
<bialix> babah
<lifeless> vila: who is subscrubed
<fullermd> You received this bug notification because you are a member of bzr-core,
<bialix> I'm just poor boy
<fullermd> (of course, $DEITY knows how _that_ happened.  Some fool had a moment of weakness, maybe...)
<lifeless> bzr-core is just bzr without plugins
<lifeless> its not 'core developers'
<vila> ha, of course. bialix ! Not poor, bad ! Not part of bzr-core, tsk tsk :)
<bialix> yep, not part of bzr-core
<lifeless> 'bzr' is part of bzr-core
<fullermd> (technically, I'm part of bzr, which is part of bzr-core)
 * bialix is bad? oh, man...
<vila> red big flashing
<bialix> yeah, yeah
<bialix> I was joking too
<vila> :)
<fullermd> Well, now that the channel's all active, must be time for me to go...
<bialix> to sleep?
<fullermd> Perchance to dream.
<koskela> hello
<bialix> hi
<koskela> A question: Why pushing over sftp doesn't move any files? It just creates .bzr directory under my push directory, nothing else...
<bialix> because push only sends the history of your branch
<bialix> if you want to copy working tree files you need to use bzr-upload plugin
<koskela> oh... ok
<koskela> How to check if it's installed?
<bialix> run `bzr plugins` and look for the line 'upload x.y.z' where x.y.z is the version of the upload plugin'
<bialix> you have to install it as upload, not as bzr-upload
<bialix> koskela: ^
<koskela> 1.0.0dev is the version
<bialix> check `bzr help upload` for help
<koskela> Ok... Do I remember totally wrong because I think it worked earlier that bzr push command uploaded the files too...
<bialix> koskela: there is also push-and-update plugin
<bialix> maybe you're using that in the past?
<bialix> anyway, push updates working files only for push from local disk to local disk
<bialix> or just to local disk, that's more correct
<koskela> Ok...
<koskela> Oh, ok, now I remember... At least another situation that I was remembering, was local directory to another local directory... Thanks!
<Gnx> I've got a little problem, today bzr started hanging with the sftp connection and I can't even seem to google anything sensible for the error message
<bialix> what's error message
<Gnx> Disconnect (code 2): Protocol error: packet 5 in interactive
<bialix> show the relevant part of .bzr.log
<Gnx> umm, where would that be in the windows version
<bialix> run `bzr version` and you'll see the location
<bialix> are you on windows?
<bialix> are you using bzr.exe from standalone installer?
 * bialix bbiab
 * bialix back
<Gnx> yeah, on windows
<bialix> do you have any special settings regarding ssh client?
<Gnx> bialix: nope, it used to work just fine, and it still works for other team members
<bialix> do you see anything unusual in .bzr.log?
<jelmer> hi Bialix
<bialix> heya jelmer!
<jelmer> How are things?
<bialix> despite be busy with the main work? well, fine, thanks. today I'm trying to implement snapshots for scmproj
<bialix> jelmer: and you?
<jelmer> bialix: Same, busy but happy :-)
<Gnx> bialix: this line 8.375  failed to load system host keys: [Errno 2] No such file or directory: 'C:\\/.ssh/known_hosts'
<Gnx> but, I don't know if that is it
<bialix> Gnx: it's harmless
<Gnx> because it asks for my pwd anyway
<bialix> Gnx: are you using pageant?
<Gnx> bialix: nope
<bialix> can you pastebin the relevant part of .bzr.log?
<bialix> Gnx: if you're using paramiko for sftp (which I believe is the default) you can set your password in the authentication.conf file
<bialix> so you don't need to type it everytime
<Gnx> oh, well didn't really mind doing that
<bialix> doing that what?
<Gnx> entering the password
<bialix> np
<bialix> Gnx: if you still encounter this problem try to ask in bzr ML or file a bug
 * bialix disappears
<sudhanshu> hi all
<sudhanshu> how to setup enviornment using bzr
<sudhanshu> anyone live
<sudhanshu> ?
<dutchie> Conflict adding file website.  Moved existing file to website.moved.
<dutchie> how can I use the existing website.moved file?
<sudhanshu__> any one can tell me how i can start work on bzr for mixxx software
<sudhanshu__> i've python 2.6.4 as well as bzr also
<sudhanshu__> it's installed in my system
<zini> I am looking for a bazaar equivalent of statsvn (http://www.statsvn.org/). Any suggestions?
<beuno> zini, the best I canthink of is bzr-stats
<zini> I think I saw that while searching for a replacement. But it gives only stats about commiters, right?
<zini> Well, I am off. Thanks anyway.
<strk> bzr: ERROR: Operation denied because it would change the main history,
<strk> how to fix ?
<strk> I did unbind, commit commit push
<strk> then pull, merge, commit
<strk> and got lost :'(
<lifeless> strk: you need to checkout the branch, merge your branch into the checkout, and commit
#bzr 2010-03-21
<jml> "bzr ls" appears to download an awful lot.
<jelmer> jml: I think it might grab a copy of the entire revision tree
<jml> jelmer, ok thanks
<mohitranka> Hi All
<mohitranka> Which version of bzr should one use on Windows, for knit-repository?
<mohitranka> A remote collegue of mine is using 2.0.4, and seems like the repository format has changed, on 2.0.4
<mohitranka> what is the windows version of bzr with knit repository support?
<cwhii> bzr missing shows I have 3 extra revisions. How do I get them to launchpad.net? Details: http://stackoverflow.com/questions/2487545
<poolie> thanks cwhii
<poolie> cwhii: answered there
<cwhii> Same error using bzr push bzr+ssh...
<poolie> how strange
<poolie> i wonder if that's still an auto-
<poolie> mirrored branch and therefore you can't write to it?
<poolie> it's not a very helpful message if so
<poolie> so yes, that's it
<cwhii> like maybe the lock error message actually means it is locked?
<poolie> it means this branch is readonly to you
<poolie> despite being owned by you
<poolie> and the reason why is that it's an auto-import branch
<poolie> so what i would suggest you do is
<poolie> through https://code.edge.launchpad.net/~cwhii/emle/2.0
<poolie> rename that branch to something like 2.0-import
<cwhii> Import Status: Suspended
<cwhii> This branch is an import of the Subversion branch from https://emle.svn.sourceforge.net/svnroot/emle/trunk.
<poolie> then push your own branch to ~cwhii/emle/2.0
<poolie> which will be a regular writable branch
<poolie> before you do this, you might like to create a new emle-dev team
<poolie> and push it to ~emle-dev/emle/2.0
<poolie> and then other people can have access to it later, if you want that
<edgimar> I don' t know a lot about bazaar, but I wanted to find out the following:  if I have a "Decentralized with shared mainline" repository centrally accessible, is it also possible at the same time for it to be used in the "centralized" mode (where repo history isn't pulled)?
<poolie> edgimar: yes, you can have some people with checkouts and some people branching off it
<cwhii> I have no clue. I am so confused with this. So, can you be very explicit.
<poolie> sure
<poolie> first go to https://edge.launchpad.net/people/+newteam and make an emle-dev team
<poolie> 2nd go to https://code.edge.launchpad.net/~cwhii/emle/2.0/+edit and change the "name" field to "2.0-import"
<poolie> 3rd on your pc, in the branch directory, type "bzr push --remember lp:~emle-dev/emle/2.0"
<edgimar> poolie, so a checkout means no repo history.   I know that doing bzr clone bzr://path/to/repo will pull the history -- what must one do to just get the latest rev with no history?
<poolie> bzr checkout --lightweight BRANCH_URL
<edgimar> ok, great.  thanks for the info.
<cwhii> emle-dev created.
<cwhii> 2.0-import.
<igc> morning
<poolie> hi igc
<igc> hi poolie
<cwhii> pushed to emle-dev
<poolie> same answer here http://stackoverflow.com/questions/2487545/how-to-get-local-bzr-commits-to-server/2489092#2489092
<cwhii> So, can I delete the ~cwhii emle since that looks like it is my personal repo and I really only want an emle developer one?
<poolie> the import? or something else?
<poolie> cwhii: i suggest you do the "change series branch" step, #4 in my stackoverflow thing
<cwhii> #4 in so.com done.
<poolie> igc, can you help with the bug/question queues?
<cwhii> Thanks.
<igc> poolie: sure
<poolie> cwhii: all set?
<poolie> igc, actually i'll do the bugs if you do the questions
<poolie> to avoid racing
<igc> poolie: ok
#bzr 2011-03-14
<poolie> hi all
* 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: poolie
<vila> hi all !
 * fullermd gives vila a sickly wave.
<vila> hoo
<vila> or ooh ?
<fullermd> Today, it's more like 'ow'   :|
<vila> ha right, this one
<lifeless> vila: oh hai
<vila> _o/
<vila> maxb: gentle nudge about 2.3.1 in ppas, any news ?
<maxb> hi
<mr-russ> vila: I've attempt to write up the small doc for shared repo stuff using bzr+ssh.
<mr-russ> vila: how do I now do the next parts to make it a merge candidate?
<maxb> there's this dh_python2 packaging migration that is somewhat blocking
<vila> mr-russ: push a branch on launchpad and propose it for merging (bzr push ; bzr lp-open)
<vila> maxb: not for all ubuntu versions I hope ?
<maxb> all but natty
<mr-russ> vila: sorry I'm a real noob here.  push to?  the bzr trunk, or somewhere else.
<vila> maxb: ok, I'm lost, where should I look to learn more ?
<vila> mr-russ: push to launchpad: bzr push lp~<your_launchpad_username>/bzr/<name_reflecting_your_branch_intent>
<vila> grrlp*:*
<vila> shudder
<vila> mr-russ: push to launchpad: bzr push lp:~<your_launchpad_username>/bzr/<name_reflecting_your_branch_intent>
<maxb> vila: my/jelmer's brain?
<vila> maxb: ok, downloading right now
<vila> :)
 * mr-russ waits for upload
<vila> maxb: I've missed some episodes, what's the intent of dh_python2 and why does it matter ?
<maxb> basically the debian unstable packagings have all shifted to track a major change in python packaging system
<maxb> and now we need to figure out the best way to backport stuff
<vila> but why does it impact more than natty ?
<vila> (and even natty for that matter >-/)
<maxb> because we used to reuse sid packaging across all distroseries
<vila> and why don't we postpone that to after 2.3.1 ?
<maxb> vila: Hi, sorry, lost phone reception as I entered my office block
<maxb> So, the thing is that in the past we have just re-used sid packagings unmodified
<maxb> So, we either solve the migration question first and continue to do so
<maxb> Or, we just independently update the 2.3.0 ppa packaging to 2.3.1
<maxb> granted, perhaps we should do the latter, as a pragmatic solution to getting 2.3.1 packages out in the PPAs on time
<vila> maxb: +1 :)
<vila> o:) even
<vila> meh, bug #654733 regressed on FreeBSD 8-/
<ubot5> Launchpad bug 654733 in Bazaar "bp.launchpad.test_register.TestBranchRegistration.test_onto_transport tests fail on Python 2.7" [High,Fix released] https://launchpad.net/bugs/654733
<vila> It turns out the natty xmlrpclib.py carries an additional patch
<vila> Where should I search to identify this patch and its rationale ?
<vila> http://paste.ubuntu.com/580061/
<fullermd> How purdy.
<vila> Purdy, MO (city, FIPS 60176)
<vila>  Location: 36.81846 N, 93.92068 W
<vila> shudder
<vila> ok, it's part of https://launchpad.net/ubuntu/natty/+source/python2.7/2.7.1-5/+files/python2.7_2.7.1-5.diff.gz but not part of lp:ubuntu/natty/python2.7 8-/
<fullermd> Is that just a test failure, or something broader?
<vila> fullermd: only a test failure and due to some test fake object and a patch is on its way, but still, I'd like to understand what happened there (probably for reasons similar to the ones behind your question ;)
<vila> fullermd: don't let that make your blood boil ;)
<lifeless> jelmer: do you know, will jam be around today?
<fullermd> Oh, I won't.  This is why I tricked you into going py27 before me   :p
 * vila restore freebsd8 slave backup and forgot about the issue ;)
<vila> fullermd: naaah, evrything went well except for that glitch
<fullermd> Hm.  Funnily enough, I just came across a commit disabling the py-yolk package due to possibly the same thing.
<fullermd> http://psf.upfronthosting.co.za/roundup/tracker/issue8194
<fullermd> So it looks like that patch is in upstream for some future release.  Doesn't help the releases already out, ghouh.
<fullermd> Or though, even.  Eye khan tipe.
<vila> right, thanks fullermd, that answer my question about the rationale
<vila> and that ^ answers lifeless question ;)
<jelmer> lifeless: there he is :)
<vila> lifeless: care to share this summoning trick ?
<lifeless> jam1: hi
<jam> hi lifeless
<lifeless> jam1: that loggerhead bug - in the lp qa queue - can we test that remotely ?
<jam> lifeless: I think so
<lifeless> https://devpad.canonical.com/~lpqateam/qa_reports/deployment-stable.html (good morning)
<jam> I don't know how to tell if qastaging gets a loggerhead oops
<jam> but any HEAD request would trigger it
<jam> if HEAD qastaging.../changes doesn't generate an oops, then we're good
<jam> I don't know how the apache proxy figures in, but I think we'd still get a 500 if it failed
<lifeless> jam: care to give it a spin ?
<jam> lifeless: do you know that qastaging has the newer loggerhead?
<lifeless> yes
<jam> well, newer launchpad wrapping of loggerhead
<lifeless> its in the report
<lifeless> which means its autodeployed
<jam> lifeless: on qastaging I'm just getting the "infinite redirect bug"
<jam> foo/bar/changes redirects to foo/bar/changes
<jam> can't test loggerhead there, I believe
<jam> I don't remember exactly why
<lifeless> argh
<lifeless> uhm
<lifeless> do you think this could make things worse ?
<jam> lifeless: I'm pretty confident on the patch, since I was able to reproduce it locally.
<jam> And in the immediate term,
<jam> mthaddon switched us to using GET anyway
<lifeless> jam: mark it qa-untestable then
<jam> lifeless: If you tell me when its deployed, I can qa it then
<lifeless> sure, but for now ... need to fill in the paper work :)
<jam> lifeless: marked
<vila> fullermd: 2.7 is the official default now right ?
<fullermd> _PYTHON_PORTBRANCH=..   2.7
<fullermd> _PYTHON_DEFAULT_VERSION=.   ${_PYTHON_PORTBRANCH}
<vila> fullermd: thanks
<fullermd> (post-8.2/7.4)
<vila> fullermd: EPARSE, does this mean the change is part of an as-yet-unreleased version ?
<vila> fullermd: or did I just expose my ignorance again ?
<fullermd> Mmm.  Culture gap.
<fullermd> There's a tarball of ports on the CD/DVD/etc you grab to install $VERSION, which is roughly enough just a snapshot of the point in time "somewhere around" when the release was cut.
<fullermd> The default was changed after those snaps for 8.2/7.4.  But the default has to do with _ports_, not the OS release, so if you e.g. updated the ports tree after your 8.2 install before installing stuff, you'd get 2.7 default.
<fullermd> But whatever you build builds against whatever you have installed, so if you installed bzr right away, it would go with the prior default (2.6).  And after updating ports, you'd keep using 2.6 for stuff until you switched it around.
<fullermd> (special cases aside of course, like programs that require 2.7 would refuse to build)
<vila> ok, right, so the parallel with Ubuntu would be that this is part of -update (IIUC) which is official enough for me (especially since this means the test failure can't be triggered except on unlucky setups)
<fullermd> So you can't say "FreeBSD X.Y uses version Z" really, just "As of X.Y, the default was Z".
 * vila nods
<fullermd> Well, who runs tests anyway?   :p
<vila> hehe, babune does
<fullermd> Probably most installs out there are 2.6 now.  That'll tip over the next few months, probably.  I don't have a general feel for how quickly the change will be followed by existing installs.
<fullermd> I've still got perl 5.8 on my system here frex (that way I don't accidentally write code requiring a later version)
<vila> right, so switching to 2.7 on babune sounds still valid (and was triggered by a need to install sphinx anyway which I will do once I've finished sorting out this glitch)
 * fullermd nods.
<jelmer> hmm
<jam> jelmer: who usually reviews your dulwich patches? I'm surprised to see it addressed to "vcs-imports"
<jelmer> jam: If they're possibly controversial I usually send them to the dulwich-users@ mailing list for review so people can speak up if they object
<jelmer> jam: I was submitting them as LP merge reviews as well so I wouldn't lose track of the ones I had submitted, I hadn't considered that that would result in email for ~vcs-imports members..
<jam> jelmer: I'm perfectly capable of ignoring them, I just haven't seen them before
<jelmer> jam: Perhaps I should unsubscribe ~vcs-imports from lp:dulwich
<jam> and wasn't sure what you were asking
<jelmer> well, if you're wondering about reviews... ;-)
<poolie> hi jam, jelmer, vila
<jam> hi poolie
<jelmer> 'evening poolie
<jelmer> welcome back :)
<vila> poolie: eerk, don't start too strong after your vacations ! It's nice to see you but I'd like to see you for long ! ;D
<jam> jelmer: in your export tar revisit, you mention fixing bug #102234, but when I test it manually using bzr.dev, I don't see the extra dir
<ubot5> Launchpad bug 102234 in Bazaar "bzr export embeds the tarfile path; causes problems with 7zip" [Low,In progress] https://launchpad.net/bugs/102234
<poolie> vila, hi :)
<jam> jelmer: also, AIUI, XZ != LZMA, though I have to poke through your details
<vila> poolie: nice to see you back, our vacations overlapped and we didn't met since... like.. a month ? :D
<jam> they have the same underlying compression, but different framing
<jelmer> jam: Newer versions of python already take the base dir name
<vila> jam: thanks for the review !
<jam> jelmer: so it is just a different python version that we are working around?
<poolie> i'd like to just pull out the xmlrpc stuff
<poolie> inbox 0!
<jelmer> jam: yeah
<jam> poolie: not bad after 2 (non consecutive) weeks of vacation
<jelmer> jam: It seemed easy enough to do (and add a test for)
<jam> a big select and discard?
<vila> poolie: inbox 0 ! wow, congrats !
<jam> of course, poolie, didn't review all of jelmer's pending changes, either. So clearly he skipped *some* parts of his inbox :)
<vila> poolie: by the way, it would be awesome if you could push a bit on the SRU[s]
<jelmer> jam: lzma/xz is a good point, I'll dig deeper..
<jam> jelmer: why did you indirect from "ie.symlink_target" to "tree.get_symlink_target()", for RevisionTree, etc, it is extra overhead for sure (since it then has to look up the InventoryEntry by file_id, and return the value you have)
<jelmer> jam: It means you can directly export from a working tree
<jelmer> I noticed that it otherwise wouldn't work (also for ie.text_size) when writing tests.
<jam> jelmer: http://news.softpedia.com/news/Introducing-LZMA-and-XZ-Compression-Algorithms-124883.shtml
<jam> I believe
<jam> looks like I was slightly rwong
<jam> wrong
<jam> XZ is, indeed, a new format entirely
<jam> but seems able to understand lzma streams
<jelmer> The strange thing is that "file" reports the .tar.lzma streams we're generating as being XZ
<jelmer> jam: I guess we should strictly change it to .tar.lzma, or at least add that to the list of extensions
<jam> jelmer: yeah, and it looks like no chance to get XZ in 2.X http://bugs.python.org/issue6715
<jam> since it missed 2.7, it won't be in any 2.x release
<jelmer> jam: I'm using an external lzma module with xz support so that shouldn't be an issue
<jam> jelmer: XZ? or lzma ?
<jelmer> jam: the lzma module has an option to force xz or lzma
<jam> I looked into lzma quite a bit when we were doing the groupcompress work. Looking here: http://stephane.lesimple.fr/wiki/blog/lzop_vs_compress_vs_gzip_vs_bzip2_vs_lzma_vs_lzma2-xz_benchmark_reloaded
<jam> I'm reminded why we chose to skip it.
<jam> The knee on the "time to compress" curve is huge for lzma
<jam> bzip2 is "slow" at 22s to compress.
<poolie> jam :) i'm going to do some code reviews separately from email
<jam> lzma and xz default compression is 100s
<poolie> i still have some mail that needs action
<poolie> and i also have SRUs on my list
<jam> poolie: does that count as inbox 0? I can certainly file all my "unread" mail into other folders...
<jelmer> jam: updated to include .tar.lzma support
<jelmer> jam: the original patch was correct in that the default from the lzma python module is strangely enough to use xz compression
<poolie> everything's been scanned and i have an idea what i need to still deal with
<jam> jelmer: I would expect that depends highly on the version of the module
<poolie> i think that's the original definition
<jelmer> jam: I'm forcing the format now
<jam> jelmer: I'm a little concerned about external dependency, but not critical. Certainly we aren't going to implement it ourselves :)
<vila> poolie: I use this definition roughly too (inbox is really unsorted mail for me)
<jelmer> jam: We'll raise DependencyNotPresent if the user doesn't have it installed, and we won't attempt to use it unless the user explicitly asks for a .tar.xz/.tar.lzma tarball.
<jelmer> jam: I guess it could live in a plugin, but that seems too much trouble for something that's only rougly 20 actual lines of code :)
<jam> jelmer: yeah, not a big deal
<jam> as you say, it is isolated to being pretty optional
<jam> and probably just gives a Recommends sort of flag
<jam> (or even Suggests?)
<jelmer> Suggests seems most appropriate at the moment, perhaps Recommends if .tar.xz becomes much more popular.
<jelmer> Since Recommends are installed by default on modern Debian/Ubuntu systems I'm hesitant to add every optional dependency to it.
<jelmer> In the past we had bzr Recommend bzrtools and bzrtools recommend graphviz and graphviz depending on some X libraries. Which meant that installing bzr on a server pulled in some X libraries.
<jam> jelmer: yeah, I remember
<fullermd> Hm.  bzr info now blows up on weave_fmt stuff   :|
<jam> fullermd: definitely jelmer's fault, and something that should be fixed
<jam> jelmer: for export-to-stdout, I'd rather use pure relative paths than "-/"
<jam> is it hard to change?
<jam> (so "export -" would create a file with all files rooted at '.')
<jelmer> fullermd: I think my "misc" branch should fix that, it's some confusing interaction with imports.
<jelmer> fullermd: it's in the PQM queue
<fullermd> How do we not have a test that caught that?
<jelmer> fullermd: it's the order in which the imports happen, the testsuite loads all formats first
<fullermd> Even for blackbox's?
<jam> fullermd: most things are "run_bzr" which runs in-process
<jelmer> jam: That seems reasonable. My only concern is that tarballs without a root folder can be pretty annoying to unpack if you don't create a separate directory before unpacking.
<fullermd> Ah.  That makes sense.
<jam> a few things are "run_bzr_subprocess" but we avoid them because they are *very slow*
<jelmer> jam: Not sure how much of a concern that is.
<jelmer> Using "-" is also certainly not very nice.
<jam> jelmer: I agree, but people should use a root, or pass a path
<jam> -/ is just ugly
<fullermd> Yeah.  If they were all that, it would take too forkin' long.
<jam> :)
<jelmer> jam: Perhaps we can change "-" to "." and print a warning?
<jam> jelmer: I don't see a need to warn. I don't really know why people want to export to '-',but if they do, they get what they asked for
<jam> I don't think anyone doing it is asking for '-/'
<jelmer> jam: I agree "-" is wrong, but as somebody who has once overwritten half his home folder by unpacking a dodgy tarball I feel inclined to warn when not using a root dirname...
<jam> jelmer: from my experience, it is very common in the Zip world
<fullermd> jelmer: Yes, it seems fixed now.
<jam> such that by default, Windows extracts into a directory named by the zip name
<jam> (so "proper" zip files get extracted to foo/foo/files)
<jelmer> jam: urgh
<jam> jelmer: I'm not really against a warning, especially because tarball etiquette specifies one
<jam> but I don't really want to say stuff if I think people won't listen to it
<jelmer> jam: fair enough
<jelmer> jam: I'd be happy to leave it without a warning for now, since this is a fairly unusual use case anyway and if it's not uncommon in the zip world.
<jam> general question for the audience. what is the best way to test that work *isn't* done?
<jam> (I have a query that starts at the tip, and should only process, 20 items and return them. How do I tell that the next 20 weren't touched?)
<jelmer> jam: updated to default the root to '' if dest is '.'
<jam> jelmer: does that make it "/" ? which would probably be worse than "./"
<jam> (though I'm pretty sure tar strips that by default)
<jelmer> jam: No, there are tests that check the paths.
<spiv> jam: assert something about the count of items examined, or the identities of items examined, or lay booby traps on items that should not be examined...
<jam> hey spiv. Yeah, I was thinking some sort of booby traps
<spiv> I'm reminded of tests that hook the hpss client and then assert things about self.hpss_calls
<jam> problem is injecting booby traps in Branch history
<jam> (this is loggerhead code)
<spiv> jam: oh, that's easy, just put the unwanted history in a stacked-on repo that isn't accessible ;
<spiv> ;)
<jam> spiv: isn't it almost midnight there?
 * spiv goes to bed before he thinks of a really silly idea
<spiv> (yes)
<jam> sleep well, sir, good to see you around
<magcius> jam, hey, I'm Jasper, what exactly do you want for tests?
<magcius> For the redirects, that is.
<jam> magcius: for the redirect stuff, a test that what is really a file under /files redirects to /view, and the reverse for accessing a dir under /view
<jam> basically, just a rough test that the change really does what you want
<jam> probably can put it in test_simple.py
<magcius> jam, will it give me a mock inventory?
<jam> though I'll note "setUpLoggerhead()" defaults to using HTTPExceptionHandler. It might be easier to not use it, and just catch the exception in an "assertRaises".
<jam> magcius: you can use "self.createBranch" and "self.build_tree()" to create a real one.
<magcius> OK.
<jam> actually, it fits better in "test_controllers"
<jam> vila: wrong ping channel :).
<beuno> jelmer, thanks for your export branch, it looks like exactly what I was needing  :)
<jelmer> jam: Thanks for the review!
<jam> jelmer: not, I caught "assert" late.
<jelmer> jam: I was literally about to press "e<enter>"
<jam> note
<jelmer> jam: this is the assert in bzrlib.export.tar_exporter ?
<jam> jelmer: I believe so. PQM would catch it, but you don't have to wait for it :)
<jam> bzr selftest -s bt.test_source
<jelmer> jam: perhaps I should just kill the assertion, lzma itself also checks that the format is supported.
<jam> jelmer: however you like
<jam> just letting you know you can't submit it like it is :)
<magcius> jam, how do I run tests?
<jam> magcius: bzr selftest -s bp.loggerhead will run all loggerhead tests
<magcius> jam, Ran 0 tests in 0.000s
<jam> magcius: do you have loggerhead installed as a bzr plugin?
<magcius> not sure
<magcius> how can I do that?
<jam> magcius: cd ~/.bazaar/plugins
<jam> ln -s $LOGGERHEAD_DIR loggerhead
<magcius> and?
<magcius> aha
<magcius> jam, when building the test: ValueError: cannot get null revision inventory
<magcius> self.createBranch(); self.build_tree(('file', 'folder/', 'folder/file'))
<jam> magcius: you need a "tree.commit()" in there
<jam> after build tree
<jam> you probably also need to tree.add
<jam> if you look at TestInventoryUI
<jam> there should be some hints there
<magcius> aha, thanks
<jelmer> jam: the mtime argument to gzip.GzipFile is only available on Python >= 2.7.
<jelmer> jam: Does this look reasonable: http://bazaar.launchpad.net/~jelmer/bzr/export-tgz-711226/revision/5740
<jelmer> The other options are to check sys.version or to use the inspect module
<jam> jelmer: if you want to be evil, you could override time.time() for the __init__ timeframe
<jam> or we could overrride GzipFile._write_gzip_header
<jelmer> jam: I'm fine with just doing the right thing on Python 2.7
<jam> I'm also never quite sure when python raises TypeError vs AttributeError
<jam> jelmer: most people who want that functionality want in on py2.6
<jam> still the default in natty
<jam> I believe
<jelmer> jam: they won't get this new bzr until oneiric though
<jelmer> though I guess if we don't patch GzipFile or time.time we should at least mention this in the release notes
<maxb> Unless they use the ~bzr PPA
<jam> jelmer: right, the patch notes would be "support fixed tar.gz on Python2.7 which exposes 'mtime'" or somesuch
<jelmer> jam: is there a particular reason CHKSerializer uses XML for inventory serialization? Just because that infrastructure was already in place?
<jam> jelmer: for bundle transmission, IIRC
<jam> ideally, we wouldn't need it
<jam> at one point we used it for transmitting it for conversions
<jam> but spiv fixed it to use an inventory delta instead
<jelmer> jam: is there something CHK-based that might work for bundles?
<jam> jelmer: well, not without reworking bundles
<jam> arguably the ideal would be to treat a bundle as a branch stacked on a hypothetical repo that has restricted availability ,and then we would use it as a StreamSink
<jam> so the data would be similar to what we would otherwise transmit
<jelmer> jam: hmm, that does sound nice
<jam> jelmer: the other big win, is that on the other side you can treat it as a StreamSource
<vila> jelmer: doh, I dunno what happened with bug #731240 (probably some double edit with different UIs), but thanks for setting it straight  ;D
<ubot5> Launchpad bug 731240 in Bazaar "opening over http in dumb mode fails in selftest" [Low,Fix released] https://launchpad.net/bugs/731240
<jelmer> vila: least I could do after you've been fixing Triaged bugs for me for the last two months ;-)
<vila> jelmer: hehe, tha's what made me laugh after the initial "Huh ? Didn't fix a similar bug recently" when receiving the mail and thinking it was a new one ;)
<tacone> hello, i have unneeded binary files in my past revisions. is there any way to clean the repository ?
<maxb> tacone: Unfortunately not, unless you are willing to rewrite the the entire history in a way which will break the ability to do merges between the new and the old incarnations
<tacone> :-(
<tacone> thanks :)
<maxb> If this is acceptable to you, the fastimport plugin and fast-import-filter would be what you would need
<tacone> uhm ?
<maxb> If you did want to perform the kind of rewriting that I was implying, the 'bzr-fastimport' plugin, and its "bzr fast-import-filter" command would be the tools you would need to look at
<tacone> ok
<tacone> i'm looking it up right now. thanks !
<jelmer> maxb: Just submitted debian bug 618349 with patch
<ubot5> Debian bug 618349 in python-configobj "python-configobj: ConfigObj writes out the wrong kind of triple quotes" [Normal,Open] http://bugs.debian.org/618349
<hunger> How can I get bzr to output progress information when cloning in a non-interactive shell?
<PenguinOfDoom> When I commit to my bzr branch, it automatically pushes to an svn branch. That's not what I want, and I have no idea how I got there
<PenguinOfDoom> how do I get it to do local commits?
<PenguinOfDoom> "bzr unbind" claims it's not a bound branch
<jelmer> PenguinOfDoom: is it a checkout perhaps?
<jelmer> hunger: I don't think there is any way to do that - how would you want to get that information, anyway?
<PenguinOfDoom> jelmer: I don't think it's a checkout, but how do I tell?
<PenguinOfDoom> (I think it's a branch in a shared repository)
<jelmer> PenguinOfDoom: bzr info will tel you
<jelmer> *tell
<trond-> Hi, I am using bzr for development of websites, and I have created a clone by using the branch command. Now I have continued to work on the main and I want to re-branch those changes (as I have not done any changes to the branch). Is this possible? or shall I just delete the old branch and re-clone the solution again?
<PenguinOfDoom> jelmer: bzr info doesn't mention anything about the branch being a checkout
<jelmer> PenguinOfDoom: what does it say about the format? "Standalone branch" / "Shared repository branch" / etc ?
<PenguinOfDoom> http://pastebin.com/H6FZx7Jh
<jelmer> trond-: I'm not sure if I understand what you mean exactly, but I think "bzr pull" from the main branch should do what you need
<trond-> jelmer, ok. So I'll be in the branch-directory/job and bzr pull then?
<jelmer> trond-: depending on what branch-directory/job is, yes
<jelmer> PenguinOfDoom: I'm pretty sure that shouldn't push if you commit
<PenguinOfDoom> jelmer: I know that it shouldn't, but it does.
<jelmer> PenguinOfDoom: it should only do so if you explicitly run push or pull
<jelmer> ehm, just push I mean
<jelmer> PenguinOfDoom: does "bzr config" mention a bound branch?
<PenguinOfDoom> There's no such command. I'm using bzr 2.2.1 from maverick
<jelmer> PenguinOfDoom: in that case, does "grep bound ~/.bazaar/bazaar.conf ~/.bazaar/locations.conf .bzr/branch/branch.conf" return anything ?
<PenguinOfDoom> Nope! branch.conf has three lines, parent_location, push_location and submit_location
<jelmer> I'm at a loss then, sorry. :-/
<PenguinOfDoom> derp
<jelmer> are you sure the branch wasn't bound earlier and unbound now?
<jelmer> is there any reference to the location it pushed to anywhere?
<jelmer> do you have a plugin that autopushes or something that installed perhaps?
<PenguinOfDoom> It autopushes to the push location. I didn't install any such plugin on purpose
<PenguinOfDoom> also, I deleted branch.conf and now it doesn't push any more maybe
<jelmer> PenguinOfDoom: how did you originally create the branch?
<PenguinOfDoom> I created it in svn with "svn cp", then did a "bzr branch svn+ssh://svn.twistedmatrix.com/svn/Twisted/branches/iocp-tcp-large-write-3233-2" locally
<trond-> jelmer, yup pull seemed to work. Had some conflicts, but I believe I have resolved those. Thanks for the help..
<denys> is there a way to use bzr-svn with a repository in which I have permission for a subdirectory, but not for the root?
<jelmer> denys: only with newer versions of bzr-svn, and if you disable the cache and manually specify the repository layout
<denys> I am using lp:bzr-svn so I guess I just need to tweek some configuration stuff
<jelmer> denys: yeah, disable the configuration and set the repository layout
<jelmer> *should* do it
<denys> jelmer: I found some info on layout in bzr help svn-layout, but nothing about "disabling the cache". could you give me a small clue where to look?
<jelmer> denys: set "use-cache = False" in the relevant entry in ~/.bazaar/subversion.conf
<denys> jelmer: thank you
<ajmitch> jelmer: bzr-builddeb looks to be a bit broken in sid, missing the upstream/ dir :(
<jelmer> ajmitch: Urgh, that's what we get for running the testsuite from the source directory. Sorry, will fix.
<ajmitch> eventually the BTS will get my mail about it
<coreGrl> hi, I'm a web developer, I'm developing in php and I want to keep track of my sources, I'm thinking to have a working copy and to use bzr to verions it, then backup the repository on a usb disk and on dropbox, what's the best way to achieve this? there is an example somewhere?
<jelmer> coreGrl: you should be able to simply "bzr push" to the locations where you would like a copy of your history to be
<jelmer> coreGrl: if you'd like to upload a copy of your files without the history to the web server, have a look at the bzr-upload plugin
<coreGrl> jelmer, there is documentation about this scenario?
<jelmer> coreGrl: there is documentation about the individual uses of bzr push and bzr upload, though not on this scenario specifically. A couple of common use cases are explained in the user guide @ http://doc.bazaar.canonical.com/latest/en/user-guide/index.html
<coreGrl> tanx jelmer
<poolie> hi all
<jelmer> ajmitch: any chance you could add a changelog entry referencing the LP and debian bugs?
<ajmitch> sure
<ajmitch> version it as 2.7.2?
<jelmer> ajmitch: seems reasonable
<ajmitch> jelmer: pushed, you'll want to tweak it before uploading I think
<jelmer> ajmitch: \o/
<exarkun> Hey, bzr is broken some more, again, continuously, http://buildbot.twistedmatrix.com/builders/lucid64-py2.6-select/builds/674/steps/bzr/logs/stdio
<exarkun> Sorry, it's really bzr-svn I guess
<exarkun> but in my rage I am not sure if I can reliably distinguish between them
<poolie> :/
<exarkun> I am going to switch to git I think
<poolie> can you get the backtrace out of there?
<poolie> or set -Derror when running it?
<exarkun> Here's the crash log file, http://twistedmatrix.com/~exarkun/bzr-20110314212803-3315.crash
<exarkun> oops, permissions
<exarkun> okay, fixed
<jelmer> exarkun: that's bzr-svn
<poolie> a permissions problem gave you a keyerror?
<jelmer> 'morning poolie
<exarkun> no, sorry, the permission problem was on the log file I uploaded to my website :)
<exarkun> I don't know what caused the bzr-svn problem
<poolie> hi jelmer
<jelmer> exarkun: the quick fix is to remove the tdb cache file, though can you perhaps move it out of the way for debugging?
<exarkun> Okay
<exarkun> I can post the tdb file somewhere too if that will help debug the problem
<poolie> and the traceback please
<jelmer> exarkun: yeah, that'd be great. was a previous pull perhaps interrupted or something like that?
<exarkun> I don't /think/ so.  But there is probably some concurrent use of bzr with this cache
<exarkun> There is more than one builder set up on this user account
<exarkun> http://twistedmatrix.com/~exarkun/broken-bbbe8e31-12d6-0310-92fd-ac37d47ddeeb/
<mwhudson> um
<mwhudson> is the order bzr loads plugins defined?
<jelmer> mwhudson: not really
<mwhudson> jelmer: has it changed recently or something?
<mwhudson> i have a plugin called AAA that sets up the paths for dulwich & subvertpy
<jelmer> mwhudson: I think it's just whatever os.listdir() returns
<jelmer> have you recently changed filesystems ? :)
<mwhudson> doesn't os.listdir() sort?
<mwhudson> ah no
<mwhudson> i guess something moved around
<mwhudson> hm
<jelmer> mwhudson: you could use the daily build ppa ? :)
<mwhudson> yeah i guess i could now
<spiv> mwhudson: or use sitecustomize.py ;)
<mwhudson> spiv: i have some morals!
<maxb> mwhudson: I had an AAA plugin that stopped working recently too
<maxb> I couldn't pinpoint any obvious cause
 * jelmer just has a 15-entry PYTHONPATH that gets set by ~/.zshrc
<maxb> I assumed I'd just been temporarily lucky with python dict ordering
<mwhudson> maxb: it does look like filesystem ordering, nothing to do with python
<maxb> There is a certain amount of pleasant elegance in being able to set up all your plugins via .bazaar/plugins
<maxb> mwhudson: I think from when I looked at the code the listdir results get gathered into a dict and then iterated
<mwhudson> maxb: oh right
<mwhudson> well it's a set, but
<spiv> sets/dicts iteration order can be affected by insertion order.
<maxb> either was I am tempted to propose a deterministic sort for loading order
<jake__> hullo. how do i restore a version without overwriting the existing one? do i have to duplicate the entire branch?
<mwhudson> so renaming it to AA or AAAA or ... might work? :)
<mwhudson> jake__: version of a particular file or the whole tree
<jake__> version of a particular file
<jake__> you mean rename the original file before the bzr revert?
<mwhudson> jake__: no, that was a previous conversaton
<mwhudson> jake__: bzr revert takes a filename argument
<jake__> oh okay
<mwhudson> jake__: or you can probably use bzr cat
<jake__> ah, that looks promising
<jake__> sweet, that did exactly what i wanted
<jake__> thanks
<mwhudson> np
#bzr 2011-03-15
<maxb> jelmer: You have removed the failure note about bzr-explorer from DailyPpaStatus, but the latest build is still failing in the same way?
<jdobrien_> ping
<maxb> ping who?
<jelmer> maxb: it's a bzr bug that's been fixed
<magcius> jam, ping
<magcius> jam, http://bazaar.launchpad.net/~jstpierre/loggerhead/fix-569358/revision/434
<magcius> also, does the lp bookmark thingy support shortcuts for users? So I can replace lp:~jstpierre/loggerhead/fix-569358 with ~loggerhead/fix-569358 or something
<magcius> er, lp:~loggerhead/fix-569358
<spiv> magcius: lp:~/loggerhead/fix-569358
<spiv> magcius: â~fooâ of course would always mean the user foo.
<magcius> OK.
<spiv> I tend not to use that shortcut though because you can't share that URL with other users.
<magcius> spiv, it's a bit long to type.
<magcius> spiv, and I accidentally pushed to a different URL at first.
<magcius> and I'm not sure I can re-set it
<spiv> reset what in particular?
<spiv> The default location for 'bzr push'?  Use 'bzr push --remember URL'
<spiv> jam: http://blog.vrplumber.com/index.php?/archives/2490-Meliae-is-neat,-but-scary....html
<thomi> Hi, I'm trying to package a bzr plugin. I'm testing the package, and I can't see the plugin name in 'bzr plugins'. I can't import the plugin from a python console either, but if I cd to /usr/share/pyshared then I can.
<jam> spiv: thanks for the heads up. Didn't realize someone was talking about me at pycon :)
<poolie> thomi, i'd guess it's because you're installing it to the wrong path
<jam> but yes, the observation that memory gets sucked into dicts is also what I've found
<jam> hi po
<jam> poolie: hi
<poolie> hi there
<poolie> i'm going out now; biab
<thomi> I'm installing it to /usr/share/pyshared/bzrlib/plugins/sloecode - if I put it in ~/.bazaar/plugins/sloecode it works fine.
<poolie> by hand, or using pycentral etc?
<poolie> i think just putting the files there is not enough
<poolie> hi mars
<thomi> the latter, although I'm just following the packaging guide on the wiki, so I may have missed something
<jam> magcius: looking pretty good. The only thing left I might ask (since you've done so well), is to use "e = self.assertRaises(...)" and then check the attributes of the exception, to make sure it is redirecting to the right url. Then we know the redirecting is working correctly, and somebody can't mess it up later.
<jam> thomi: offhand, I don't think /usr/share/pyshared is in the bzrlib search path
<magcius> jam, I was going to do that, I didn't know assertRaises returns the exception.
<jam> I think we search the platform specific ones
<jam> magcius: it doesn't in unittest, it *does* in bzr's test suite
<magcius> Yeah.
<poolie> thomi, i would just check what's different between your packaging and say bzr-gtk
<magcius> I usually use pytest, which is a bit nicer, I guess.
<thomi> jam: on my system (Ubuntu 10.10), all the bzr stuff is in there. I can see my plugin right next to all the other installed plugins :-/
<magcius> unittest is very barebones, I know twisted fixed a bunch of those random things up
<thomi> poolie: yeah, I've been comparing to bzr-hg, and so far they look very similar
<jam> thomi: very strange
<jam> you might want to try "bzr plugins" and "bzr <command> -Derror". It is possible the plugin is failing to load, and -Derror should tell you why
<lifeless> magcius: bzr's test frame is (mostly) testtools these days
<lifeless> magcius: which has some very nice stuff in it, if I do say so myself
<magcius> testtools?
<lifeless> testtools
<magcius> fork of unittest or something?
<lifeless> http://pypi.python.org/pypi/testtools
<spiv> magcius: https://launchpad.net/testtools, http://pypi.python.org/pypi/testtools
<thomi> jam: I've tried that. 'bzr plugins -Derror' produces no additional output, and 'bzr sc-login -Derror' gives me "unknown command 'sc-login'".
<spiv> magcius: a library of tasteful extensions within the unittest design, not a fork
<magcius> OK.
<magcius> Everybody has their own testing framework :(
<magcius> latest kid on the block: http://packages.python.org/Oktest/
<spiv> That's why testtools isn't a new framework :)
<magcius> jam, so, I know Loggerhead is a separate project from Launchpad.
<magcius> jam, so, if I wanted http://bazaar.launchpad.net/launchpad to do a redirect to http://code.launchpad.net/launchpad
<magcius> how would I do that?
<magcius> without introducing some coupling or assumptions that we're running under Launchpad.
<magcius> Would I have a hookable, global 404 handler?
<jam> magcius: launchpad runs its own "main" script, you could certainly do something at that level
<magcius> jam, linky?
<jam> magcius: grabbing it
<magcius> Thanks!
<jam> magcius: http://bazaar.launchpad.net/~launchpad-pqm/launchpad/stable/files/head:/lib/launchpad_loggerhead/
<magcius> OK.
<jam> and http://bazaar.launchpad.net/~launchpad-pqm/launchpad/stable/view/head:/scripts/start-loggerhead.py is the actual start script
<jam> magcius: I would probably say, poke around in 'app.py' looking for where requests come in. Because you have to do it higher than the BranchWSGIApp, because you don't have a branch
<magcius> Right.
<magcius> Is most of the code in lib.launchpad_loggerhead.app just there for the oops stuff?
<jam> magcius: and stuff like /favicon etc
<magcius> OK.
<jam> if you look at "RootApp.__call__" it has a fair amount of tests. It also glues the Launchpad virtual file system into the web interface
<magcius> jam, https://code.launchpad.net/~jstpierre/loggerhead/fix-569358/rev/435
<magcius> er
<magcius> jam, http://bazaar.launchpad.net/~jstpierre/loggerhead/fix-569358/revision/435
<spiv> jam: I'd appreciate your thoughts on https://bugs.launchpad.net/bzr/+bug/709349
<ubot5> Ubuntu bug 709349 in Bazaar "bzr: ERROR: bzrlib.errors.RetryWithNewPacks: Unprintable exception RetryWithNewPacks" [High,In progress]
<spiv> jam: I've just added a comment about where I'm up to: basically something that ought to be impossible appears to be occurring.
<poolie> spiv, i read that
<poolie> my only idea would be that it is indeed filesystem weirdness, but that would be strange on a local linux fs
<spiv> poolie: thanks for that.  At least I'm not missing anything obvious then :)
<poolie> :}
<vila> hi all !
<jam> morning vila
<vila> hay jam, you're up quite early :)
<vila> jam: (according to the logs that is)
<jam> vila: I get up around 6:30. Just takes a while to get everyone off to school, etc.
<poolie> hi jam, vila
<jam> hi poolie
<vila> hey poolie
<mr-russ> hi vila, I manage to propose a merge, thanks for the help.
<vila> mr-russ: you're welcome ! (on all counts ;)
<vila> package-importer is toasted
<vila> debug_log mentions OperationalError: table failures has 4 columns but 3 values were supplied
<vila> does that ring any bell in someone's head ?
<spiv> vila: not for me
<vila> I'm investigating but the error message basically implies that the failures table got an additional row...
<maxb> where by row, you mean column? :-)
<vila> maxb: obviously :D
<vila> but this doesn't make a lot of sense... the column is 'emailed' and has been there for more than a year...
<vila> ...except if this exception was *never* caught before....
<jam> vila: one possibility is if the column changed to being NOT NULL or something along those linse
<jam> lines
<vila> jam: I've icommon..._set_failure to properly initialize 'emailed' to 0
<jam> vila: weird, 'emailed DEFAULT 0'
<vila> I've also killed the running mass_import and the nexuiz-data one
<vila> jam: indeed
<jam> but also "SELECT count(*) FROM failures" == 0
<jam> vila: so no failures have ever been logged
<jam> or that table is cleared out by something
<vila> jam: or some new sqlite3? version introduced a change ?
<vila> in behaviour
<vila> bah, very unlikely
<jam> vila: I think the "we've never put anything into that failure table" is pretty significant
<jam> the table is empty right now
<vila> jam: it is not on my local importer
<vila> and _start_package insert a a new row
<vila> in the failures table
<jam> vila: I'm just telling you what I see on jubany
<jam> meta.db has no rows in the "failures" table.
<vila> jam: I get that, I just continue the discussion :)
<vila> the truth is there somewhere, waiting for us to discover it by throwing contradictions to each other ;)
<jam> vila: so I agree with your original assertion "we've never hit that on Jubany" or, we've hit it, but just failed imports because of it, etc.
<vila> so I've landed a patch that create the failure row as it is created in _start_package and I'm waiting for some {lo|g}sa to restart the importer...
<vila> I've been told we're losa-less until US starts...
<jam> vila: I started. wait...
<vila> jam: no !
<vila> jam: you can't properly start the mass_import.py script
<jam> vila: I'm saying I started work, but I'm not in the US zone anymore.
<vila> gee, you scared me ;)
<vila> I almost made a joke about you not being in US anymore... :D
<poolie> the kanban is about to get a bit more accurate
<poolie> as i roll out trunk
<poolie> ah, some of it's going to need to wait on a review
<poolie> but, still, a bit better
<poolie> i should finish
<poolie> vila, i just noticed http://people.canonical.com/~mbp/kanban/vila-kanban.html is curiously empty
<poolie> i'm sure you're doing stuff but maybe you should update the bugs?
<vila> poolie: I just made it even more empty :)
<poolie> :)
<vila> poolie: and I just pushed a fix for the importer without an associated bug which doesn't help either ;)
<poolie> well, the point is to fix things, not move the cards around
<poolie> but a certain amount of keeping track of things is useful
<vila> poolie: sure
<vila> wow: http://babune.ladeuil.net:24842/job/selftest-windows/lastFailedBuild/testReport/junit/bzrlib.tests.test_export/TarExporterTests/test_tgz/
<vila> jelmer: ^ could that be related to your recent changes ?
<jam> vila, jelmer: Looks like a O_BINARY issue to me
<jam> probably "bzr export" isn't set to use EXACT encoding
<jam> so it outputs in Text form, and that garbles the compressed data
<vila> do we have a bug about switching to sphinx (including pqm) ? I couldn't find one
<vila> or switching to tarmac, whatever
<jam> jelmer: Just found out an interesting road-tax issue. Diesel costs significantly less at the pump, and traditionally gets significantly higher km/L, but the road tax is almost 2x per year.
<jam> vila: I don't know of a bug. poolie's statement in the past was "If we are going to set something new up, probably should be tarmac, but it isn't worth the effort yet to switch off of PQM".
<jam> my personal feeling is that without Queued status in Launchpad
<jam> Tarmac is a poor fit for us
<jelmer> jam: Yeah, that's one of the reasons people buy particular cars which are taxed less.
<jelmer> jam: Same goes for LPG
<jam> jelmer: is it meant to be a tax on industrial vehicles?
<jam> or because diesel traditionally has higher polutants?
<jam> (I know in the US, they didn't get low-sulpher diesel until something like post 2007)
<jelmer> jam: I think the pollution is the reason, but I'm not entirely sure
<jam> just curious
<jam> do you even have a car?
<jelmer> jam: Nope, I don't have one.. and my parents didn't have one when I grew up.
<jelmer> my mom has a car these days, and I have a drivers license.. but I mostly use it when I'm in the US or during holidays (when we use somebody else's car)
<jelmer> jam: You're looking at getting a car in .nl?
<jam> jelmer: interesting. I know quite a few people in big cities that live that way.
<jam> jelmer: yeah
<jam> the big thing is having a child, and trying to figure out how to get him around
<jam> it is possible by bike, but likely we still want a car
<poolie> jam, i'd be happy to switch to tarmac
<jam> the place we've picked is also more on the outskirts (in Waalre, if that means anything to you)
<poolie> it looks like the losas want us to set it up ourselves
<jam> poolie: I've seen quite a few limitations when people get into the details, though.
<poolie> limitations of tarmac?
<jelmer> jam: Ah, nice. I've camped there once :)
<jam> and how do we set it up ourselves without a datacenter access? Run it on our own machines?
<poolie> anyhow, i have a medium-low thing on my todo list of prototyping it
<poolie> at least for the prototype
<jam> poolie: stuff like not being able to land on anything that isn't the dev focus, etc.
<jam> I think some have been overcome
<jam> but since rockstar isn't focused on it anymore
<jam> maintained bot >>> unmaintained bot
<jelmer> jam: Are you implying pqm is maintained??
<poolie> :)
<jam> I think that was, honestly, the only problem with PQM
<jam> jelmer: not at all. but I'd rather keep a tool that we're using now and have worked around
<poolie> it's not top of my list
<jam> than switch it for *another* unmaintained tool
<poolie> if someone else gets a bee in their bonnet and does not have too much other stuff queued or in progress, they can do it
<jam> especially since it was designed around incomplete features in Launchpad
<jam> I *really* want a tweak rating, and "review: needsfixing, merge:approve" is the best we have, but Tarmac will land that patch.
<jam> since we don't have Queued
<poolie> i would like 'tweak' too
<poolie> ok, really good night now
<jam> poolie: sleep well
<jam> jelmer: need me to fix the windows export breakage?
<jelmer> g'night poolie, see you tomorrow
<jelmer> jam: If you have an idea of what's going wrong. I'm looking at it and it seems like a perfectly reasonable test to me.
<jam> jelmer: did you see my earlier comment about possibly being an "encoding=exact" type thing?
<jam> vila: bonus points, the test passes when "bzr selftest -s bt.test_export"
<jam> but *fails* with --verbose
<jam> jelmer: ^^
<jelmer> jam: ahh
<jelmer> jam: You're probably right, as tgz (and tar) is the only one we actually use open() for
<jelmer> jam: tar isn't tested though
<jam> jelmer: and doing "bzr export --verbose --format=tgz - " does generate an invalid stream
<jam> jelmer: http://paste.ubuntu.com/580504/
<jam> makes it pass for me
<jam> with --verbose
<jelmer> jam: +1
<jelmer> poolie: thanks for removing the needs testing column in kanban :)
<jam> vila, jelmer: have you had any problems pushing changes to LP?
<jelmer> jam: no, but I haven't tried yet this morning
<jam> I just tried to push an update to my "jam-integration" branch, and it is telling me Readonly.
<jam> *sigh* just figured it out
<jam>  jam-integration was a mirror
<jam> bad error messages ftl
<jam> (of course, the source is now offline since I took down my server)
<jam> jelmer: anything we can do to get your Kanban "needs release" changes into Released?
<jelmer> jam: not really, some of them are just waiting for upstream releases
<jelmer> I'm working on fixing some last bugs before a bzr-svn release now
<jelmer> but I have no control over wikkid, storm, pygpgme, etc
<evanton> I am trying to retrieve http://wiki.bazaar.canonical.com/QBzr using a http library and I'm getting access denied, but it works in a regular browser, why is the site dumping me like that?
<evanton> I've tried to change the default user-agent, no luck
<jelmer> evanton: it seems to work fine here in e.g. curl
<jelmer> evanton: are you getting a 401 of some sort, or a HTML access denied page?
<evanton> jelmer: if you'll be around I can try finding that coed snippet so I could provide an exact answer to this question
<evanton> *code
<jam> evanton: several of us should be around for a while
<jam> evanton: it works here using 'wget'
<vila> jam: no problem pushing so far
<jam> *My* guess is that you have an HTTP proxy that you aren't respecting in your http library
<jam> vila: I figured it out. Was a mirror branch I was pushing to
<jam> and LP giving no reminder ofthat
<vila> right, just read it :-/
<evanton> ok, I found it
<evanton> I'm getting a 403
<evanton> "You are not allowed to access this!\r\n"
<evanton> it is the urllib3 python HTTP library, if this matters
<jam> evanton: if you can dump your HTTP headers, you might find something interesting.
<jam> I really do expect it is a Proxy issue
<evanton> jam: the request headers or the reply headers?
<evanton> jam: and I'm not behind a proxy
<jam> evanton: probably both, especially if you can catch the ones your web browser sends
<evanton> jam: sure, I have live http headers in firefox
<evanton> jam: http://dpaste.org/mdBc/
<evanton> the first is the sniffed http session of urllib3, below is the dump from live http headers (firefox browser)
<jam> evanton: you're not passing an "Accept" (if I read it correctly)
<jam> I don't know if that matters
<jam> evanton: here itis. you are passing the full URL
<jam> "GET http://wiki.bazaar.canonical.com/QBzr"
<jam> not
<jam> "GET /QBzr"
<jam> (that is my guess)
<evanton> hmm
<jam> I've certainly seen servers that reject passing the full URL in the GET
<evanton> jam: so it likely looks like a problem with this particular http library?
<jam> evanton: something like that
<jam> it is passing "Host:" so it shouldn't be also passing the full URL
<jam> at least, AIUI
<evanton> I am confused because I'm using this library for other sites too and this is the first site that dumps me
<evanton> not using the default urllib2 because this one can reuse http connections (handy when having to retrieve a couple of urls from the same site)
<evanton> interesting, retrieving /QBzr works
<luks> passing the whole URL normally means that you want to use the HTTP server as a proxy
<evanton> jam: you are probably right, I'll mail the author of urllib3
<jam> evanton: I can confirm, sending raw socket.socket() messages
<evanton> thanks for your help
<jam> sending /QBzr works
<jam> sending full url gives Forbidden
<hunger_> Is there a way to force "bzr clone" to provide progress information when running in an non-interactive environment?
<jam> hunger_: BZR_PROGRESS_BAR , IIRC
<jam> hunger: export BZR_PROGRESS_BAR=text
<jam> should do it
<hunger> jam: Great! Thanks!
<hunger> jam: The bzr checkout wizard in Qt Creator is not providing any indication that it is doing something... we need to fix that:-)
<jam> hunger: I'm guessing you want to ensure the process barrier rather than using bzrlib?
<jam> One thing you could consider, is setting your own UIFactory
<hunger> jam: The code was contributed. I have to admit that I never really looked into bzr myself:-)
<hunger> jam: It does work pretty well though, doing the normal checkout etc. I di dto test the plugin.
<cerf> hello there !
<cerf> I have created a QtCreator plugin for Bazaar
<cerf> at some point I need to get the ouput of the 'bzr clone' command
<cerf> I have tried to play with the BZR_PROGRESS_BAR env-var
<cerf> but with no success
<cerf> only the modes 'none' and 'tty' work
<cerf> 'dots' or 'text' don't
<cerf> any idea ?
<jam> cerf: version of bzr?
<jam> dots is pretty old, IIRC
<cerf> v2.2.1
<cerf> it still appears in 'bzr help env-variables'
<jam> cerf: we've supported it for a long time. though I think poolie changed the values in a release, I'm trying to track down which one
<jam> bug #339385
<ubot5> Launchpad bug 339385 in Bazaar "bzr: BZR_PROGRESS_BAR is ignored" [High,Fix released] https://launchpad.net/bugs/339385
<jam> so the last time I see it explicitly touched is pre 2.0
<jam> but checking
<cerf> that's right I have seen this bug report
<jam> cerf: since bzr-2.0 it has been either "text" or "none"
<jam> not "tty" or "dots"
<jam> cerf: http://bazaar.launchpad.net/~bzr-pqm/bzr/2.0/view/head:/bzrlib/ui/text.py#L144
<cerf> indeed
<jam> cerf: There may be another bug involved. But "dots" has been gone for a long time, I don't see how "tty" would do anything. "text" looks like it
<jam> should work in all 2.X releases
<cerf> what would you suggest to work around my problem ?
<jam> cerf: if you could file a bug about "bzr help env-variables" having bad documentation, and then use "BZR_PROGRESS_BAR=text"
<jam> I think it is just a doc bug
<cerf> I cant get tty or text progress output
<jam> Are you sure it was "tty" that worked for you, and not "text" ?
<cerf> 'tty' works the same as 'text' for me
<jam> cerf: I can confirm here that "export BZR_PROGRES_BAR=text" works for me
<jam> if I do "bzr log http://.... >out.txt 2>err.txt"
<jam> with the setting, it puts progress into 2
<jam> without, it doesn't
<jam> are you expecting progress on stdout ?
<cerf> yes that's it
<cerf> is it possible ?
<jam> cerf: progress is always on stderr, so it doesn't intermingle with real data on stdout
<jam> you can certainly capture stderr of a subprocess, though
<cerf> thanks jam, I'm gonna try to read stderr
<jam> cerf: bug #735417
<ubot5> Launchpad bug 735417 in Bazaar "doc for BZR_PROGRESS_BAR incorrect" [High,Confirmed] https://launchpad.net/bugs/735417
<jam> hopefully gets backported to at least 2.2
<jelmer> jam: are you submitting a fix for the tgz export test or should I ?
<jam> jelmer: already finished through pqm
<jelmer> heh, nevermind then :)
<jelmer> jam: Thanks
<jam> Just used 'pqm-submit' rather than going through the launchpad work
<jam> I usually do that for "trivial" fixes
<vila> jam: the empty failures table is probably due to bug #608563 as I *did* issue a retry --all to address slangasek query
<ubot5> Launchpad bug 608563 in Ubuntu Distributed Development "requeue_package.py --all-of-type retries all packages" [High,Triaged] https://launchpad.net/bugs/608563
<jam> ah
<vila> eeerk, there are uncommitted changes on jubany ??
<vila> in delete_branches_from_lp.py fwiw
<james_w> I think spiv was hacking on that
<vila> ha (I was about to ask you the same question in #lp-ops ;)
<vila> err is, but anyway
<vila> hmm, I'll try to ping tomorrow and if they come in the way will just shelve them and mail him
<jam> vila: I don't know what is going on here: http://babune.ladeuil.net:24842/job/selftest-windows/374/testReport/junit/bzrlib.tests.blackbox.test_export/TestExport/test_tar_export/
<jam> It works here
<jam> and it did fail before my update
<jam> this hints that it has the updated patch: http://babune.ladeuil.net:24842/job/selftest-windows/374/
<vila> jam: yup, more than hint
<jam> vila: doesn't mean hudson actually succeeded in applying the update. But yeah, I would be surprised if it didn't
<vila> well, I've seen weird things on jenkins/hudson, but not using the right code ? Never so far
<vila> jam: could it be that the encoding is overridden when running without a real tty or something ?
<vila> 79.100  encoding stdout as sys.stdout encoding 'cp1252' in http://babune.ladeuil.net:24842/job/selftest-windows/lastFailedBuild/testReport/junit/bzrlib.tests.blackbox.test_export/TestExport/test_tar_export/ may not be relevant...
<jam> vila: redirecting to a file still works for me here
<vila> jam: you're notoriously good at avoiding windows babune slave bugs ;D
<jam> vila: I'm running the wrong file, just a sec
<jam> k weird, I know I got at least one failure in the past
<jam> which 'exact' seemed to help
<jam> but now, it won't fail either way
<jam> I suspect a failure to flush()
<jam> which would make it ~ load dependent
<jam> and certainly babune runs differently there
<vila> jam: also, is redirecting to a file the same thing as running ~without a console as on babune ?
<jam> vila: you are redirecting to a file already.
<jam> not sure about 'without a console'
<jam> but you are capturing the output == redirected to a file
<jam> I can no longer reproduce failure with or without -v with or without my patch :(
<vila> pipe probably... or are you talking about the test framework ?
<vila> jam: ouch
<jam> I know I did see a failure before
<jam> not sure how I triggered it
<jam> but that was how I thought I 'fixed' it. Since it did fail, and then it stopped failing
<jam> ah, got a failure
<jam> load dependent
<jam> vila: "for i in `seq 20`; do bzr selftest -s bp.test_export test_tar_exporter; done
<vila> 'load' as in CPU load or import load order ?
<jam> and I got maybe 3-4 failures out of 20
<vila> ooooooouch
<jam> (without my patch)
<vila> jam: eerk, erratic on babune too: look for 41 vs 42 :http://babune.ladeuil.net:24842/job/selftest-subset-windows/
<jam> vila: well, I see now. "test_tar_export" exports to a file on disk, not to '-'
<jam> so it obviously wouldn't have been affected by my patch
<vila> urgh, I dunno what I prefer :-/
<jam> vila: I think it is just a flushing issue. TarFile.close() does *not* close its underlying stream.
<jam> I don't know why GzipFile would get caught up without flushing itself
<jam> I'm trying a different patch
<jam> note also, that the streams are not explicitly closed
<jam> no try/finally
<jam> ug
<jam>         stream = open(dest.encode(osutils._fs_enc), 'w')
<jam> doesn't look good
<jam> I don't know how it ever worked
<jam> maybe got lucky and no '\r' or '\n' in the compressed stream
<vila> aaaaah
<jam> note that for gzip.GzipFile:
<jam> "If not given, the âbâ flag will be added to the mode to ensure the file is opened in binary mode for cross-platform portability."
<jam> however, we are opening directly with "open()"
<vila> >_<
<jam> jelmer: so there is another bug, and its time for me to go. Basically you also changed it to use "open(..., 'w')" where GzipFile used to translate that to 'wb' automatically,
<jam> I'll try to get to it tonight.
<jam> I'd like to change a few other things anyway.
<jam> *sigh*, even adding more data to it doesn't guarantee it will fail. time to try harder
<jam> jelmer/vila: if you want to poke at it, a good start for forcing a failure is at lp:~jameinel/bzr/integration
<jam> It uses osutils.rand_chars() to put in a bunch of data, that ends up likely to create '\n' in the output stream
<vila> jam: use rand_chars() *until* you end up with a '\n' in the gzip output and stick with it ?
<mgz> >>> [c for c in "".join(chr(i) for i in range(256)) if "\n" in c.encode("zlib")]
<mgz> ['\t', '\x95', '\xa5', '\xb5', '\xc5', '\xd5', '\xe5', '\xf5']
<vila> mgz: :D
<mgz> ...hm, need to limit it to the non-adler32 bit of the value though, tab is no good.
<mgz> all the rest would do though.
<mgz> or a PNG, which has a cunningly crafted header to detect errors like this.
 * mgz pulls jam's branch to start on a fix.
<mgz> meh, I hate '-' as a magic name meaning stdout
<mgz> seems like the test is fixable, but this will still be bogus code
<mgz> anyone who pipes a compressed tar from bzr on windows risks corrupting it, we don't set our output stream to binary mode
<mgz> and even if we did, we don't control the other end of the pipe.
<mgz> ah, 'exact' does handle our end.
<mgz> hm, I wonder if there's any tar metadata that will vary across platforms or python versions and screw this plan up.
<mgz> testing this kind of bug with zip would be much easier... :)
<jelmer> mgz: what are you trying to fix?
<mgz> vila's babune error.
<jelmer> mgz: shouldn't that just be a matter of opening the file in binary mode?
<mgz> jam's got a branch that does that, but it seems like something's still borked, and it needs testing.
<mgz> it's probably just the test framework that's wrong post-jam-fix
<vila> mgz: if you're able to reproduce it reliably *and* fix it, I think we shouldn't try too hard to keep reproducing it
<mgz> well, I have a magic string that works here, I'm just #1 worried it may not consistently, as the tarfile module has been fiddled with a lot since 2.4 and #2 the test still fails
<jelmer> mgz: I thought jam's fix was for a different issue
<vila> I fail to see how you could not guarantee that the compressed data will always be the same across all supported envs so trying to do it is likely to be brittle
<jelmer> at least, I think the change to use 'exact' isn't really relevant here
<mgz> it sets encoding='exact' on the command, which appears to be about this issue.
<vila> mgz: he later said it wasn't relevant (AIUI)
<mgz> ah, okay, missed that, I'll change the other line he mentioned then.
<vila> mgz: he got tricked by the test failing erratically
<vila> mgz: and (still AIUI) ended up suspecting the compressed data to contain '\n', found that gzip guarantee using 'wb', etc
<jelmer> vila: do you know if he submitted another fix?
<vila> jelmer: not that I know of, he ended up saying:
<vila> <jam> jelmer/vila: if you want to poke at it, a good start for forcing a failure is at lp:~jameinel/bzr/integration
<vila> <jam> It uses osutils.rand_chars() to put in a bunch of data, that ends up likely to create '\n' in the output stream
<vila> <
<jelmer> vila: it seems like the open on bzrlib/export/tar_exporter.py:111 should be changed to have 'wb' instead of 'w'
<jelmer> vila: ah, he noticed that as well
<vila> jelmer: without looking at the code, he said 'w' should never had worked so the test was passing by luck
<vila> or maybe it's a new test you added recently ?
<jelmer> I added the test recently
<jelmer> actually, I think that one may have been there before
<vila> that would explain it then, even on babune the failure was erratic
<jelmer> but the code didn't use open() earlier
<vila> here we are
<jelmer> jam said he was going to look at it tonight though
<mgz> I've got it.
<vila> yeah, I can't look at it right now either
<mgz> the sys.stdout bit is the dodgiest aspect.
<vila> binary(sys.stdout)
<vila> :)
<mgz> that's still only our end.
<mgz> also, it's scattered all over the file.
<vila> if it's going to contain a gzip content, the other end has better be prepared to handle it as binary
<mgz> I'm not sure if 'exact' on the command should have stdout covered already or not.
<jelmer> mgz: isn't the test failure while writing to test.tar.gz ?
<mgz> it is, but we also want to not corrupt things written to stdout if possible.
<mgz> (as far as possible)
<jelmer> fair 'nough
<jam> jelmer, vila: didn't read the whole argument, but there are 2 bugs
<jam> one is open('w')
<jam> one is encoding = 'exact'
<jam> I fixed one, but the test was flakey
<mgz> okay, that works.
<mgz> so, jam, 'exact' does handle setting stdout to binary before we arrive at lines like `stream = sys.stdout` in tar_exporter?
<jam> mgz: yes
<jam> I have a fix for the other, but I wanted to make the test reliably fail
<jam> note that zlib does huffman encoding, etc.
<jam> so any one character isn't guaranteed to trigger it
<mgz> hm, what goes through plain_tar_exporter? because there's another non-binary open there.
<jelmer> mgz: not open() open() though, tarfile.open()
<mgz> ^well, it is in practice on idential input, zlib is pretty stable
<jam> lots of them in the cod. the compressors like gzip.GzipFile take 'w' but internally turn it into 'wb'
<jam> might just want to force them all
<mgz> looks like open-open to me jelmer
<mgz> ^the main issue is tar is a big binary blob that I'm worried may not be very consistent
<jam> mgz: just for the heck of it, I also wanted to switch to osutils.open_file()
<mgz> even if we're not writing mtime and other obviously variable things
<jam> since then it won't interact with ssh children, etc
<mgz> sounds reasonable jam.
<mgz> http://paste.ubuntu.com/580664/ <- this is my diff on top of your branch thus far.
<jam> mgz: anyway /me is in family time
<mgz> byebye.
<jam> mgz: also, we don't need _fs_encode for open() and I'd rather avoid it
<jam> I'd also rather use encode('utf-8') where it gets put into headers
<mgz> yup.
<jam> thoguh there are arguments both ways
<mgz> the open argument doesn't end up in the tar anyway, it's just the branch filenames to worry over there
<jam> mgz: ! is ok, if you are sure it will fail 100%, though I'd rather take the chances on 65k * 1-in-256 chances of getting '\r' randomly
<mgz> well, the problem with random is that it's... random. "!" is 100% with the code on my machine, it's just a question of if tar module changes have ever modified the output it gives to gzip.
<mgz> the constants all look pretty constant from the code, provided stuff like file mode bits haven't been messed with.
<magcius> jam, is my merge deployed yet?
 * jelmer moves
<jam> mgz: true, but 1in 2^256 is a pretty small chance of failure :)
<mgz> fairynough.
<achiang> hello, having some conceptual issues, hoping to get some pointers. upstream branch has two commits, -1, and -2 that i want to drop
<achiang> so i tried: bzr uncommit ; bzr uncommit ; bzr revert --no-backup
<achiang> can i just push this new local copy to upstream now?
<achiang> i think maybe not so much...
<beuno> no
<beuno> so, what you'll want
<beuno> is to revert to -3 and then apply -1, I think
<achiang> beuno: i've tried reading the bzr merge and bzr revert man pages several times and still find them rather incomprehensible. :-/
<beuno> so, if these are revnos, say, 9 and 10
<beuno> I'd bzr revert -r 8
<beuno> commit, and then bzr merge -r 10
<beuno> I think that would do it
<maxb> achiang: Hi. So, you could push your uncommitted head if you really wanted to, but rewinding a public branch leaves no evidence that you intended them to be removed
<beuno> and will cause others that have it to maybe have problems
<maxb> So, other people who had already obtained those revisions would not receive any kind of information that you wanted them gone and would probably reintroduce them
<achiang> yes, i want to leave a record of my revert
<maxb> So, what you actually want to do is to ensure you have your local tree up to date and clean at revision -1
<maxb> and then bzr merge -r -1..-3
<maxb> Actually, make that 'bzr merge -r -1..-3 .'
<achiang> maxb: beuno: i think i got it with what beuno mentioned... i just said, "bzr revert --no-backup -r 29"
<achiang> and that gets rid of r30 and r31
<achiang> and now i'm making a new commit
<maxb> beuno instructions confuse me, the revert and commit bits make sense, but what's the final merge for?
<beuno> to bring back the -1 revision, which he wanted
<beuno> he has -1, which he wants, and -2, which is doesn't
<achiang> beuno: no, i did not do the final bzr merge
<maxb> Not according to achiang's initial statement
<achiang> conceptually, it was dropping just the top two commits
<achiang> not commits in the middle anywhere
<achiang> beuno: maxb: thanks for the help (again). i know i've asked for help on dropping commits before, but the bzr way of doing it still hasn't sank in yet. :-/
<beuno> ah
<beuno> then it was just rever, yeah  :)
<maxb> The bzr way is not all that different to the svn or cvs way, really :-)
<achiang> if one starts as a git user and then tries to grok bzr, it's hard
<maxb> well yes, that's cos git is different to mostly everything else :-)
<achiang> ... but growing most rapidly in adoption, so maybe it's time to rethink that attitude. :)
<achiang> but anyway, i am not here to bite the hands that help me
<maxb> I know it is. I just don't understand why :-(
<achiang> i genuinely appreciate the help, so thank you
<maxb> I am capable of using git, I just don't understand why I would want to
<maxb> And when I can 'bzr branch git://......' I don't have to :-)
<maxb> This reminds me, I need to write some sort of hook-based branch replication solution, so I can have another go at popularizing bzr at work
<maxb> (am continually mystified that no-one has done this already)
<maxb> Surely someone out there must run a bzr hosting server with near-realtime syncing of pushed changes to an offsite node?
<vila> maxb: I think bound branches address more than 90% of the needs so nobody stepped up...
<maxb> ?
<maxb> How do bound branches address the use-case of bzr.someorganization.com being replicated to another server?
<vila> that's not what I said
<vila> I meant, if you know your changes are already in two different places, you don't care pushing them to a *third* place
<maxb> I suppose
<vila> but I fully agree with you that we need a better backup story for hosting servers
<maxb> But recovering from a putative disk failure relying on individual developer workstations isn't a very palatable situation
<vila> indeed
<maxb> I suppose everyone who does this is coming up with their own solution for their private architecture
<maxb> Which is a shame, because bzr's hooks are almost good enough to make this work really nicely
<vila> the hard part is handling the restore and the deleted branches and other evil details
<maxb> stacking locations being a very evil detail :-)
<vila> shhh, don't wake up the daemons ;)
<maxb> I was planning to punt on that and just use shared repositories
<insanity99> hey guys, im trying to set up bazaar so i can access my python folder on  2 computers. but im finding it hard to do
<insanity99> anyone here?
<wilx> Hi.
<wilx> I am sort of confused about workspace models provided by the Bazaar Explorer.
<wilx> Basically, I want to mirror a SVN branch locally.
<wilx> From that local mirror I want to be able to create Bazaar branches.
<insanity99> dont think anyones here
<insanity99> im trying to set up bazaar so i can access my python folder on  2 computers. but im finding it hard to do
<wilx> ..so that I can do disconnected development.
<wilx> And when I am done with development, I want to be able to commit the changes back to the mirror and through that back to the SVN repo.
<wilx> Do I want "feature branches" or "colocated branches" or "shared repository"?
<jelmer> wilx, shared repository is just a storage optimization
<jelmer> wilx, it sounds like you want feature branches
<wilx> Ok. Thanks. I will try with that.
<chx> hi. is bzr heads supposed to be very very slow? :)
<lifeless> no
<chx> it just sits there
<chx> for quite some time now :/
<soren> It's quite slow for me, too.
<soren> I have a /lot/ of branches, though.
<chx> so here's why i am running it: one of teammates did a number of bzr commit --local then bzr pull and now he wants his commit history back. Is that possible?
<soren> $ time bzr heads
<soren> [...]
<soren> real	1m1.604s
<soren> user	0m32.600s
<soren> sys	0m8.460s
<soren> Not as slow as I remembered.
<soren> It's doing a lot of work, though. As I said, I have a lot of branches.
<chx> i dont have a lot of branches but the repo is quite big -- lots and lots of files and revisions.
<lifeless> chx: sure its possible. bzr heads --dead
<chx> just came back empty
<chx> after like eight minutes or something
<chx> bzr st -v shows them as pending
<lifeless> oh
<lifeless> just commit :>
<lifeless> chx: its not dead - its a pending merge; bzr heads --all should list his last commit
<chx> so i am expressing myself wrong. previously bzr log showed them as commits. that's what we would like back. a bzr commit would put them into one commit.
<chx> yes. i know this should be a branch and not bzr commit --local :/
<soren> chx: I don't think I understand the motivation, but something like this should do it:
<soren> chx: bzr pull . -r revid:the_revision_id_of_his_original_head
<psynaptic> hey there, I have lost my head
<soren> chx: bzr merge url_to_the_shared_repo
<soren> chx: bzr commit -m 'Merge trunk' or whatnot.
<lifeless> pssibly bzr merge --uncommitted will suck the pending merge across - I'm not sure though
<chx> psynaptic: no you didnt
<chx> psynaptic: you have all your commits but now they form a pending merge
<psynaptic> my working copy contains all the changes
<psynaptic> which is what scares me
<chx> soren: bzr pull . -r 18143 is no revisions to pull
<soren> chx: Not revno, revid.
<chx> oh revid!
<soren> And make it "-r revid:the_rev_id"
<chx> so then the question is, how do i see the revid of a pending merge that st -v shows me?
<soren> chx: As lifeless said, bzr heads --all should show it.
<soren> chx: I'm not sure bzr status gives it up easily.
<chx> ok give me ten minutes while that runs :D
<psynaptic> ;)
<lifeless> what format repo is this that its taking so long?
<psynaptic> it's on launchpad
<psynaptic> which seems slow for us
<psynaptic> we have tons of branches though
<BjornW> Hi there, can someone tell me if and where I can find more information on using php to script bzr?
<chx> lifeless: i think 2a
<lifeless> oh
<lifeless> don't run heads against lp
<lifeless> you run it against your local branch
<chx> oh my lord it runs against LP????
 * chx immediately breaks
<chx> lifeless: ok, so .... this is a checkout bastardized with commit --local and then up.
<lifeless> chx: lightweight or heavyweight? [bzr info should say[
<chx> lifeless: heavyweight checkout. we do not use lightweight checkouts.
<lifeless> ok
<chx> "     checkout of branch: "
<lifeless> so, I'm not sure why bzr heads is going to lp, but it will explain it
<lifeless> (the performance)
<lifeless> and why it doesn't see your head
<lifeless> so
<lifeless> bzr unbind
<lifeless> then bzr heads --dead
<chx> ahhha
<chx> didnt dare to unbind
<chx> i mean, i thought of reconfigure
<chx> but let me try
<chx> i am now, after all, on a copy.
<lifeless> chx: unbind saves the location
<lifeless> chx: you can 'bind' to get it rebound
<chx> even after unbind it have not finished yet
<chx> though i ran bzr heads --all
<chx> lifeless: i have stopped it running. it STILL did not finish.
<lifeless> chx: :(
<lifeless> chx: maybe spiv can give you a hand; I'm juggling too many things just now
<spiv> chx: check the output of 'bzr info'
<spiv> Maybe there's something obviously odd.
<chx> spiv: http://paste.pocoo.org/show/354260/
<chx> spiv: i think it's not too odd
<chx> spiv: http://paste.pocoo.org/show/354263/ this is st -v
<spiv> chx: and the problem you're having is that 'bzr heads --all' is being very slow?
<chx> spiv: well psynaptic mostly just wants his commits to show in bzr log as it did before bzr up :(
<psynaptic> this is what happened:
<psynaptic> <changes>
<psynaptic> ci "commit1"
<psynaptic> sorry..
<psynaptic> ci "commit1" --local
<psynaptic> <changes>
<psynaptic> ci "commit2" --local
<psynaptic> then I had this local history:
<psynaptic> commit2
<psynaptic> commit1
<spiv> If you're trying to find the revid of the pending merge, try using 'bzr qlog', it shows revids of pending merges.
<psynaptic> but then I ran up, I got changes from commit1 and commit2 dumped into my working copy and lost the commit history
<spiv> And then "bzr pull --overwrite -r revid:..." as suggested earlier will put the commit back as the tip
<psynaptic> not sure why but we don't have qlog
<spiv> psynaptic: not lost, just not on the mainline anymore.  If you commit you'd still see commit1 and commit2 in in the output of 'bzr log -v'
<spiv> psynaptic: it's part of the qbzr plugin
<psynaptic> ahh, so if I commit these changes it will keep my history?
<spiv> (Oops, I meant 'bzr log -n0', rather than 'bzr log -v')
<spiv> Yes, it'll appear as a merge, essentially.
<psynaptic> right
<psynaptic> lemme try that
<spiv> That's why 'bzr st' is telling you about 'pending merges', to reassure you that history is being kept and will be recorded when you commit.
<psynaptic> didn't seem to work like that
<psynaptic> ok, I have restored the backup
<psynaptic> st does show pending merges but they were consolidated into a single log item when I did commit --local
<spiv> Try 'bzr log -n0'
<spiv> or 'bzr qlog' (or 'bzr viz' if you have bzr-gtk)
<psynaptic> right
<psynaptic> bzr log -n0 does show all the commits
<psynaptic> :)
<psynaptic> great, thanks a lot
<psynaptic> I am happy now
<psynaptic> :D
<spiv> Mostly we just show the "left-hand" or "mainline" history by default
<psynaptic> I see
<spiv> But when you commit a merge (or "bzr up" then "bzr commit" when you have local commits, which is essentially the same situation) there's a revision with multiple parents.
<spiv> bzr log -n0, and the visualisation tools like 'bzr qlog' can tell you about the full graph.
<psynaptic> handy
<SuperMMX> hi, when I use bzr-svn to branch in windows, I found that there are revisions with backslap \ in one directory name, and the next revision fixed it. But now I get the error of invalid character in the directory name. bzr 2.3.0 with the bundled bzr-svn.
<SuperMMX> is there any way to workaround this ?
<jelmer> SuperMMX: no, Bazaar doesn't support entries with backslashes unfortunately
<jelmer> bug 81844
<ubot5> Launchpad bug 81844 in Bazaar "Handle backslashes in filenames more gracefully" [Wishlist,Confirmed] https://launchpad.net/bugs/81844
<SuperMMX> no workaround at all ? That was just one revision.
<SuperMMX> actually, I google all related bugs, mailling list, seems no luck so far.
<jelmer> SuperMMX: none other than cloning from a location that doesn't have any backslash in the history
<SuperMMX> jelmer: that's bad, one mistake blocks all.
<jelmer> I think we should probably increase the importance of that bug
<jelmer> given the number of people that have hit it so far
<SuperMMX> probably shallow branch can fix the problem, but that wil be in the far future.
<jelmer> yes
<SuperMMX> jelmer: thanks anyway.
<psusi> I'm trying to specify a tag with bzr branch -r that has a : in it and it seems to be interpreting the : in a way that confuses it
<psusi> is there some sort of escape needed or something?
<jelmer> psusi, prefix the tag name with tag:
<psusi> ahh
<jelmer> that forces bzr to consider that string as a tag name
<Peng> : is special in revison specs -- see "bzr help revisionspec"
#bzr 2011-03-16
<poolie> spiv, i'm alive :)
<spiv> Oh good :)
<poolie> hi spiv
<poolie> the changelog thing was ok
<poolie> thanks for adding it to whatsnew
<vila> hi all !
<vila> spiv: there a re uncommitted changes on jubany regarding delete_branches (sp?), can you have a look ?
 * jelmer waves
<poolie> hi vila
<vila> poolie: hey !
<jelmer> what are we going to use for the standup, skype/mumble/... ?
<spiv> vila: oh right
<spiv> vila: I think probably they should just be committed; I was thinking maybe I'd try polish them a little but I don't think it's worth spending more time on that.
<vila> spiv: by the way, do you when bzr was upgrade to 2.3b5 on jubany ?
<spiv> vila: it's changes necessary to make it work with the launchpadlib version and maybe other aspects of jubany
<spiv> vila: Not sure, but I can probably infer from the bug or RT, let me see if I can dig that up
<spiv> vila: https://bugs.launchpad.net/udd/+bug/653307/comments/25 implies the upgrade happened between 2011-02-02 and 2011-02-04
<ubot5> Ubuntu bug 653307 in Ubuntu Distributed Development "Import fails with missing referenced chk root keys" [Critical,Fix released]
<vila> spiv: ha! right, thanks, I read that but the bit about upgrading didn't stick in my mind.
<spiv> vila: no problem
<vila> spiv: on a related note, http://package-import.ubuntu.com/status/gobject-introspection.html#2011-03-15%2015:06:47.074448 is quite obscure and may be related to the fetch changes ?
<vila> s/obscure/obscure to me/
<spiv> vila: that's a fixed bug, waiting on an RT for a bzr upgrade :(
<spiv> vila: https://bugs.launchpad.net/udd/+bug/726584 I think
<ubot5> Ubuntu bug 726584 in Ubuntu Distributed Development "flash-kernel import fails apparently mismatching maverick and natty branches" [Undecided,New]
<vila> haaaa, *another* bzr upgrade ! ... /me connects the dots
<vila> pfew, thanks spiv
<spiv> vila: presumably taking a while due to a recent LOSA shortage
<vila> spiv: but also requires 2.3.1 which is not in ppas yet !
<vila> maxb: any news about 2.3.1 in ppas ?
<spiv> vila: I don't think that's a blocker
<vila> spiv: that == ?
<spiv> vila: (that == no PPA build yet) check the version of the package on jubany
<jelmer> spiv: g'day!
<jelmer> spiv: your mumble works :)
<spiv> jelmer: :)
<jelmer> spiv: mine just freezes and doesn't let me unmute..
<jelmer> (yet audio works...)
 * spiv logs off the evening
<poolie> oh, no :)
<poolie> time flies
<poolie> did you gues stand up without me?
<jelmer> spiv and I said hi on mumble, which was nice :)
<jelmer> I'm not sure if that counts as a standup
<poolie> is jam here?
<jelmer> haven't seen him yet, here or on mumble
<poolie> ok i think i'm on
<jam> hi po
<jam> hi poolie
<jam> yeah, I didn't get back in time
<poolie> i was concentrating and missed it
<poolie> you can join us now
<mr-russ> question about reviews and mergre proposal for bzr on launchpad.
<poolie> sure
<mr-russ> If my code is reviewed, and set to Needs Information, how does it go back to needs review?
<mr-russ> Does pushing further commits do that?
<mr-russ> https://code.launchpad.net/~mr-russ/bzr/add-doc-for-shared-ssh-server/+merge/53217
<mr-russ> specifically this is my first lp bzr merge and I really don't know how it all fits together.
<poolie> no, you'll need to set it back to 'needs review' through the web ui when you're happy with the state
<poolie> or click 'resubmit'
<mr-russ> status is need review, so that's correct?
<jelmer_> poolie: I can't really hear you, getting a lot of echo
<poolie> vila, can you mute yourself (click the microphone icon)
<vila> poolie, jelemer: I begin to hear you and have my micro off (which I suspect was the reason you muted me ?)
<poolie> vila, yes, if you have a desktop mic and speakers i think you'll need to mute yourself when not talking
<poolie> the echo suppression is not all that smart
<vila> poolie: yeah, I'm pretty much in this mode now mute/unmute is a click away, I think I'll stick with that for now
<vila> looks like I lost my micro :-/
<poolie> wow i like the Darth Vader effect :)
<fullermd> You should get a macro instead.  They're easier to find.
<jelmer_> vila, jam, poolie: https://wiki.ubuntu.com/JelmerVernooij/PerPackageUploaderApplication
<vila> poolie, jam, jelmer: I just learned the 'jackhammer' word, that's what they are using under my windows, so, sorry for the bad audio today :-/
<poolie> haha seriously?
<poolie> not angry ghosts?
<jam> vila: it went ok. Though you should configure push-to-talk rather than push to unmute. The ding when you started talking was a bit annoying.
 * jelmer_ looks up jackhammer..
<vila> hehe,yeah seriously :-/
<jam> http://en.wikipedia.org/wiki/Jackhammer
<jam> that ding
<jelmer_> ha, thanks jam
<poolie> what is it in fr/nl?
<soren> Wikipedia tells you, too. Lower left corner has links to other languages.
<soren> Drilboor in nl, Marteau-piqueur in fr :)
<mr-russ> what conference tool are you using?
<vila> mumble, quite amazing audio quality even compared to POTS from europe to australia
<vila> soren: hehe, yeah, I went the opposite route to get the english word :)
<soren> vila: Wikipedia is a surpringsly good translation tool that way. :)
<vila> soren: yeah, at least you can ensure that you use the right word
<mr-russ> Poolie in AU?
<poolie> quite amazing audio quality _when you consider one participants has jackhammers in the background_ :)
<poolie> yes
<mr-russ> poolie: where in AU, I'm in northern Melbourne.
<vila> mr-russ: sydney
<vila> LOL
<vila> mumble shorcuts are *global* so I should definitely *not* use 'm' as a shortcut :)
<mr-russ> that would be bad.
<poolie> desktop-wide?
<jelmer_> vila: Ah, I remember what the issue with the 2.3.1 upload was. The python-configobj triple quotes patch hasn't made it into the python-configobj package yet
<vila> are always use type m twice :)
<jelmer_> vila: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=618349
<ubot5> Debian bug 618349 in python-configobj "python-configobj: ConfigObj writes out the wrong kind of triple quotes" [Normal,Open]
<vila> jelmer: ooooh, bad bad bad
<jelmer_> I've forwarded the patch to the packager a couple of days ago, will ping and nmu
<jelmer_> Odd_Bloke: hi :)
<maxb> vila: whoops. I can do 2.3.1 in ~bzr tonight
<vila> maxb: that would be awesome !
<poolie> hi maxb, odd_bloke
<poolie> and good night
<jelmer_> g'morning maxb
<jelmer_> have a good evening poolie
<vila> poolie: g'night poolie
<maxb> morning indeed
 * maxb should go to work :-)
<vila> jelmer: argh, no 'Nominate for series' for me on bug #707075, ISTR encountering the issue last time but not the workaround...
<ubot5> Launchpad bug 707075 in Bazaar 2.4 "[sru] lp-propose fails with a 404 error" [High,Fix released] https://launchpad.net/bugs/707075
<vila> using https://bugs.launchpad.net/ubuntu/+source/bzr/+bug/707075 doesn't help
<ubot5> Ubuntu bug 707075 in Bazaar 2.4 "[sru] lp-propose fails with a 404 error" [High,Fix released]
<vila> jam or james_w : care to review https://code.launchpad.net/~vila/udd/608563-requeue-all-of-type/+merge/53527 ?
<Odd_Bloke> jelmer_: o/
<jelmer_> Odd_Bloke: hi! How's things?
<jelmer_> jam: I reviewed some of the easier loggerhead branches, looking at page_loading now..
<Odd_Bloke> jelmer_: Not bad, thanks.
<Odd_Bloke> Busy couple of weeks at work, as we're delivering training every Friday.
<Odd_Bloke> Yourself?
<jelmer_> Odd_Bloke: Pretty good - enjoying hacking on bzr fulltime.
<Odd_Bloke> :)
<jelmer_> Odd_Bloke: I filed a report against python-configobj about a bug that's blocking a bzr upload to sid. I was wondering if there was any chance of an upload or if it was perhaps ok if I did one?
<Odd_Bloke> jelmer_: You're welcome to do so.
<Odd_Bloke> I'm going to be writing training material for what feels like the rest of my life, so won't have time. :p
<jelmer_> heh
<jelmer_> Odd_Bloke: what's the training on?
<Odd_Bloke> jelmer_: FreePBX, an Asterisk front-end.
<jelmer_> ah
<vila> and now we are *too* fast ? wth ? http://babune.ladeuil.net:24842/job/selftest-hardy/430/testReport/junit/bzrlib.tests.test_selftest/TestTestResult/test_test_reporting/
<jelmer_> vila: is there a package associated with the 2.2.4 SRU?
<vila> jelmer: I don't think so nor do I know how to build one
<spiv> vila: -2ms, nice.  System clock got updated during the test run?
<vila> spiv: vbox....
<vila> spiv: but yeah, probably some weird thing like that...
<fullermd> Surely such a thing couldn't happen with vbox's punctilious attention to precision timekeeping...
<jelmer_> vila: okay, I'll prepare one
 * vila afk trying to address a violent headache :-(
<vila> at least the jackhammers have stopped (but that's probably their lunch brea k:-/)
<jelmer_> vila: done
<jam> mgz: poke about test_tar_export
<jam> did you get anywhere?
<mgz> I had to stop shortly after posting the patch-thus-far, I was trying to get plain_tar_export to fail, but it was not doing what I expected
<mgz> and I need to leave in ~5mins, but will be around later
<mgz> *plain_tar_exporter
<mgz> it also opens a file in non-binary mode before passing it to tarfile.open, and doesn't seem to have a seperate test in test_export currently
<jam> mgz: do you have it somewhere for me to start from?
<jam> jelmer_: update to configurable_logging: lp:~jameinel/loggerhead/configurable_logging
<jam> I updatet setup_logging so it can be reused by both places
<jam> care to look at it?
<jam> or shall I just land?
<mgz> nothing committed on the branch, still at experiment-and-poke stage
<mgz> http://paste.ubuntu.com/581048/ <- diff of tree
<mgz> something's wrong with that test I was trying to add, was too tired to work out what I'd messed up.
<mgz> your idea to change those open functions sounded good, also adding 'b' to tarfile.open and GzipFile in the same file would be clearer even though those functions will fix up the flags for you.
<jelmer_> jam: I guess the init_logging bit could also be inline in loggerhead.main as it's just two lines and specific to the standalone loggerhead
<jelmer_> jam: either way, +1
<mgz> (relying on your random data trick and not asserting the compressed contents contain a \n is probably right, worst case is a spurious pass and it'll catch regressions)
 * mgz is off
<jam> mgz: catch ya later
<jelmer_> vila: hmm, perhaps we should do the UDD thing and propose the SRU using a MP
<maxb> jelmer: I'd be tempted to eschew UDD for bzr, given we already have nice packaging branches which the importer unnecessarily reimports - my 2.2.2 sru attempt was derived from the bzr.debian.org branch
<jelmer_> maxb: There isn't much benefit in using the packaging branches though, especially for something like a SRU
<vila> jelmer_: thanks. Looking at the branch, am I right guessing that your merged lp:bzr/2.2 and then add the debian/changelog entry (most of the work there) and commit ? Or did you need more work ?
<jelmer_> vila: no, that's it. I also fixed the watch file. So if you have a newer bzr builddeb it's a matter of:
<jelmer_> bzr branch lp:ubuntu/maverick-proposed/bzr sru && cd sru && bzr merge-upstream && dch && debcommit -r && bzr push
<jelmer_> s/bzr push/bzr push lp:~jelmer/ubuntu/maverick/sru-2.2.4
<vila> yup, got that ;) Trying to reproduce locally
<vila> hmm, Using version string 2.3.1. doesn't look good ;)
<jelmer_> vila: hmm?
<vila> looks like I need to use ' bzr merge-upstream --version 2.2.4'
<jelmer_> vila: when merging 2.2.4 ?
<jelmer_> vila: ah, the issue is probably that you hadn't updated debian/watch
<jelmer_> vila: so it would use the latest version
<jelmer_> vila: that bit is fixed in my branch
<jelmer_> r-2
<vila> hmm, ok, so I should do that *before* merge-upstream, trying
<vila> oic
<vila> indeed, better
<vila> only difference is now the bzrlib/tests/per_tree/test_is_executable.py file which has a different file-id :-/
<vila> jelmer_: hehe, tried the same trick for 2.1 which failed because the https://launchpad.net/bzr/+download doesn't contain the 2.1 series :)
<jelmer_> vila: we should probably the link in debian/watch to point at 2.1 series page
<vila> yup, looking into it
<vila> hmm, there is no such thing as a 2.1 download page it seems...
<jkakar> Hi!  Is there a way to edit old commit messages in a Bazaar branch?
<jkakar> I have a trunk branch that uses a specific commit message format... a few revisions don't use the format, and I'd like to clean them up, if it's reasonably easy to do so.
<soren> jkakar: It's not.
<jam> jkakar: it isn't particularly hard to do recent commits, but really old ones is a problem
<vila> jam, jelmer: care to join mumble to test my new setup ?
<jam> vila: do I dare? :)
<vila> jam: yeah, should far better, the jackhammers are gone too ;)
<jam> I don't hear you saying anything
<jam> but I see the lips go red for you
<jam> vila: do you hear me?
<vila> jam: I hear you
<vila> wow, weird, mumble gives feedback as if it hear something but you don't :-/
<fullermd> Maybe it just doesn't like what it hears, and refuses to repeat it   :p
<vila> :)
<vila> jelmer_: bug #646961 has been fixed ub 2.3b4, since natty already ships 2.3.0, I can mark it FixReleased for bzr(Ubuntu) right ?
<ubot5> Launchpad bug 646961 in bzr (Ubuntu) "resolve --take-other produces AttributeError" [Undecided,Confirmed] https://launchpad.net/bugs/646961
<vila> jelmer_: or does that need to go through the packaged debian/changelog or are both correct ?
<CaMason> hello. I have a commit (a few commits back) that I need to remove (more specifically, undo)
<CaMason> what's the proper way to do this? I know which revision(s) need to go
<jelmer_> vila: sorry, must've missed a notification while I was getting coffee
<jelmer_> vila: yes, please close it as FixReleased if the version that fixes it has already been uploaded
<vila> ok
<vila> jelmer_: can you have a look at lp:~vila/ubuntu/lucid/bzr/sru-2.1.3 and tell what you think ?
<vila> jelmer_: (2.1.4 is planned for 2011-03-24 so this is only a warm-up ;)
<vila> jelmer_: and the debian/watch trick is horrible but I've filed bug #736145
<ubot5> Launchpad bug 736145 in Launchpad itself "no series specific download pages" [Low,Triaged] https://launchpad.net/bugs/736145
<vila> hmm, I just made him fall from his chair unplugging his laptop...
<kazade> Quick question, how do I tell if there are more recent revisions on a remote branch without just pulling them in?
<CaMason> how can I get bazaar to output a patch with binary data includeD?
<beuno> kazade, bzr missing REMOTE_BRANCH
<kazade> thanks beuno
<kazade> hmm, does that work the other way too? (e.g. if you have a commit that remote doesn't)
<vila> kazade: yes
<vila> CaMason: bzr send
<beuno> kazade, there's a flag
<beuno> --just-mine or soemthing, see "bzr help missing"
<kazade> --mine-only
<kazade> thanks
<vila> CaMason: did you sort out how to merge the changes you wanted to reverse ?
<CaMason> I did 'merge . -r 123..122' and that undid them nicely
<vila> CaMason: exactly
<CaMason> thanks. I then needed to get those changes *back* in, but on a different branch
<CaMason> I tried 'bzr send' but the patch file didn't contain the binary data
<gypsymauro> hi
<gypsymauro> I'm designing my repository, there is a way to export just a subfolder of a project?
<beuno> gypsymauro, bzr export can export a tarball of a dir
<vila> CaMason: oh it does, but not in the human-readable part
<CaMason> hm, well a `patch -p0 < file.patch` didn't update the binary files
<vila> CaMason: ha no, sure, but bzr merge will ;)
<CaMason> oh guff - would it? xD
<CaMason> I don't see any binary data in the patch
<CaMason> unless it's that 'begin bundle' bit at the bottom
<vila> CaMason: it's in the bundle yes
<vila> CaMason: in fact *all* is in the bundle, but there is a human-readable patch added for.. humans (and they don't grok binary for most of them)
<CaMason> aha! I will retru
<CaMason> the human readable part is huge (3000) but the bundle bit is only 4 lines
<vila> CaMason: try 'bzr help send' for more details
<vila> CaMason: well, if the target share some history with the source only the relevant revids have to be transmitted
<gypsymauro> beuno:  perfect :) tanx
<vila> CaMason: so it all depends on SUBMIT_BRANCH and PUBLIC_BRANCH and what *needs* to be sent, if the target already knows the revisions involved there is no need to transfer their *content*
<gypsymauro> another thing, suppose I've two bzr projects , what's the best way to move a folder from a project to the other?
<CaMason> ok, thanks :)
<gypsymauro> I've tried to add a folder from nautilus, then I committed the change, but in nautilus I saw that subdirectories weren't added, so I added it manually now  I've a mess, then I tried do remove the folder and when I try to commit it says Conflict: can't delete zope because it is not empty.  Not deleting. \n Conflict because zope is not versioned, but has versioned children.  Versioned directory.
<gypsymauro> any hint?
<jkakar> jam: Hmm, interesting.  The two revisions I want to edit are -1 and -3.
<magcius> jam, my changes to loggerhead *should* be deployed by now, right?
<magcius> jam, if so, can you help me look at the stack trace for the OOPS IDs that I'm getting?
<flacoste> abentley: I'm struggling with pipelines, do you think you could help?
<abentley> flacoste: sure.
<flacoste> abentley: i have a pipeline of one branch, and would like to create a new pipe before the current one
<flacoste> the instructions on the wiki don't seem to work
<flacoste> but first, i think the submit: idea is screwed
<abentley> flacoste: which wiki instructions?
<flacoste> http://wiki.bazaar.canonical.com/BzrPipeline
<flacoste> "Splitting a change into two pieces"
<flacoste> that's similar to what i want to do
<flacoste> like i said, i think it's because its idea of submit: is broken in my config somehow
<flacoste> if i do bzr diff -r submit: in my branch
<flacoste> it doesn't show any change
<flacoste> might be related to my standard bzr conf (Launchpad-style)
<flacoste> but i don't know where to start to untangle this
<abentley> flacoste: okay, so do you know what revision you actually want to use as the basis for the first pipe?
<flacoste> abentley: trunk
<flacoste> or the revision from which i branch from trunk
<flacoste> to be more precise
<flacoste> http://pastebin.ubuntu.com/581248/
<flacoste> shows a bzr info in my current tree
<abentley> flacoste: so then -r ancestor:path/to/trunk
<flacoste> abentley: is it a known bug that remove-pipe doesn't remove the branch file (if i remove-pipe and then try to add-pipe with the same name, it fails)
<abentley> flacoste: yes, it is, and there's the --branch option  to remove the branch file as well.
<flacoste> abentley: -r ancestor:trunk did the right thing :-)
<abentley> flacoste: so not a bug, a feature.
<flacoste> well, not sure it's a feature, but at least, it's by design :-)
<abentley> flacoste: just because you don't want the branch participating in the pipeline doesn't mean you want to destroy the branch.
<flacoste> i can understand that point of view, although from a naive user, this behaviour was surprising
<flacoste> s/although/as a/
<flacoste> any way, to have submit: works as a short-hand for ancestor:.../trunk ?
<abentley> flacoste: I guess it is, and asymmetrical too.  But I am reluctant to delete branches whithout explicit user request.
<abentley> flacoste: you'll want to add a section to your locations.conf.  Let me work it up.
<flacoste> abentley: i can understand, that's hard to fix, maybe just pointing that out in the user  message would make this much more friendly
<flacoste> after remove-pipe: something like
<flacoste> 'Leaving branch in ... Use XXX to remove"
<flacoste> and in the error message in add-pipe
<flacoste> anyway, just my $.02
<abentley> flacoste: here's what you'd add to locations.conf: http://pastebin.ubuntu.com/581252/
<abentley> flacoste: I noticed your push location was also wrong.
<flacoste> abentley: yeah, will this fix it too?
<abentley> flacoste: yes, it should.
<flacoste> i put this in $HOME/.bazaar/locations.conf ?
<abentley> flacoste: right.
<flacoste> abentley: wouldn't that be [/home/francis/canonical/tuolumne/BRANCH/.bzr/pipes/]?
<flacoste> since there is no .bzr/pipes in the repository
<flacoste> BRANCH is 'dashboards' in this case
<abentley> flacoste: According to the URLs you posted, your branch is at /home/francis/canonical/tuolumne/.bzr/pipes/dashboards
<abentley> flacoste: no, wait.
<flacoste> confusing bzr output i think
<abentley> flacoste: I guess there's no indication of your CWD.
<flacoste> yeah
<flacoste> the branch is ~/canonical/tuolumne/dashboards
<flacoste> ~/canonical/tuolumne is the project repository
<flacoste> and i have generic entry in locations.conf to map to LP
<abentley> flacoste: the branch is `pwd`.bzr/pipes/dashboards
<flacoste> right
<flacoste> `pwd` is a lightweight checkout
<abentley> Right.
<flacoste> but i should put `pwd`/.bzr/pipes in locations.conf?
<abentley> Yes.
<flacoste> any way, i could do this in a generic way?
<flacoste> otherwise, i'll guess i'll have to add this whenever i have a new pipepline?
<abentley> flacoste: to do this in a generic way, keep the branches in your normal location, and don't use reconfigure-pipeline.
<flacoste> abentley: hmm, that doesn't work without me changing my normal location (since i don't normally use lightweight checkout)
<abentley> flacoste: I proposed a patch to make the config system work with reconfigure-pipeline, but it is stalled: https://code.launchpad.net/~abentley/bzr/appenddir/+merge/50060
<abentley> flacoste: of course, there's nothing stopping you from keeping lightweight checkouts in your normal branch location, in addition to the branches.
<abentley> flacoste: I've always kept my lightweight checkouts separate, though.
<flacoste> abentley: thanks for the help
<abentley> flacoste: you're welcome.
<poolie> hi all
#bzr 2011-03-17
<spm> looking at bug 726584 and the corresponding RT. we have 2.3b5 on jubany atm. I can find a ppa from max for 2.3.0-1; but it's unclear to me which version matches up to revno? I'm guessing by the dates that we need 2.3.1 or possibly .2?
<ubot5> Launchpad bug 726584 in Ubuntu Distributed Development "flash-kernel import fails apparently mismatching maverick and natty branches" [Undecided,New] https://launchpad.net/bugs/726584
<spiv> spm: let me double check
<spm> ta
<spiv> spm: yes, 2.3.1
<spm> coolio, do we have a ppa of that already I can backport from?
<spiv> spm: none that I can see.
<spiv> (There's the daily builds from trunk PPA, but I think that's a bit riskier than we want to use)
<spm> okidoki. I'll update the RT with a request for a PPA we can backport off. ta spiv
<spiv> spm: Thanks!  Glad to have progress :)
<spm> heh, nothing quite like being down 1-2 folks in a team of 4. :-)
<spiv> Yeah, I bet.
<poolie> maxb, hi, could you update the ppas some time?
<maxb> poolie: hi
<maxb> yes, I promised to do that this evening and have so far failed, due to Rocket Bunnies :-)
<maxb> I shall do it before I sleep
<poolie> thanks mate :)
<poolie> i sympathize about the bunnies
<maxb> yikes, there have been 19 revisions in the debian packaging branch since the last PPA release
 * maxb is confused
<maxb>  How can I be getting conflicts in files when merging 2.3.1 into ppa/natty ?!
<maxb> upstream files, that is, not debian/*
<Peng> Cherrypicking, maybe?
<AfC> Is there a way to force Bazaar back to the original behaviour of not attempting to use empty commit messages and just straight up cancelling a commit if it gets one?
<lifeless> that changed?
<AfC> lifeless: yeah. It's rather off-putting. Now, every time I go "oops, not ready to commit all that after all", quit editor without saving, and it asks you a stupid "do you really want to commit empty" question, to which I have to answer 'n'.
<AfC> lifeless: it used to just say "no commit message specified, quitting" which, as far as I can tell, is how it's supposed to work :(
<spiv> Was probably changed for https://bugs.launchpad.net/bzr/+bug/530265
<ubot5> Ubuntu bug 530265 in Bazaar "Not modifying a suggested commit message commits anyway" [Medium,Fix released]
<spiv> I don't think there's a setting to disable that prompt, but I guess it'd be possible to write a plugin to intercept ui_factory.get_boolean("Commit message was not edited, use anyway") and return a hard-coded answer.
<lifeless> spiv: or handle empty messages specially
<echo-area> Say I want to revert an old change in the trunk, I can do this: (in trunk) bzr merge -r old-rev2..old-rev1 && bzr ci -m "Undo an old change".  Say there are many changes committed after this reversion.  Later on, I want to bring that undone change back, I can do this: (still in trunk) bzr merge -r old-rev1..old-rev2 && bzr ci -m "Bring that old change back".  I tried and this worked.  But is this the canonical/recommended way?
<poolie> yes
<poolie> hi jam
<echo-area> poolie: Thanks
<vila> hi all !
<jam> hi po
<jam> hi poolie
<jam> and vila, too!
<vila> _o/
<maxb> Does bzr actually use per-file DAGs to assist merging?
<maxb> I'm getting all sorts of spurious conflicts in criss-cross situations, even though the specific files conflicting didn't criss-cross
<maxb> e.g. the current merge of loggerhead trunk into daily-ppa
<maxb> and in fact, 4 files which didn't conflict drastically failed to have their changes merged correctly
<vila> maxb: not as well as it should, jam knows the best about this specific point
<jam> maxb: merge --weave does
<jam> (does what you want)
<jam> maxb: thats the main problem with re-landing code :)
<jam> but I'm trying to at least make sure that I do the work of merging into experimental
<jam> I didn't realize the ppa branch would have that problem, too
<maxb> --weave ... did not do what I wanted :-(
<maxb> At least for the daily-ppa branch I can just revert all the non-debian bits to the pending merge tip and be done with it
<jam> maxb: can you point me to the branches you are merging? I can give it a look over
<jam> maxb: I would guess the daily ppa would have tried to build the old trunk tip
<jam> which has been removed from history
<jam> which is going to confuse the hell out of everything
<maxb> Most recently I was trying to merge lp:loggerhead into lp:~bzr/loggerhead/daily-ppa
<jam> maxb: right, and you actually need to revert all of the 'experimental' branch back out of the daily-ppa, since it used to be in lp:loggerhead
<jam> maxb: so probably the best thing is as you said
<maxb> But that had already been done in the past
<jam> maxb: but not in the trunk branch, so things get really weird in history
<maxb> evidently :-)
<jam> daily-ppa basically has a change for almost every file that supersedes what is in trunk
<jam> what was in trunk
<jam> but then trunk updates == conflicts
<maxb> ugh
<maxb> bzr really ought to understand "I merged foo and reverted to its version" as "I'm happy to accept foo's changes in future"
<jam> maxb: if we had reverted trunks contents using "bzr revert -r OLD; bzr commit", and then rebuilt experimental from there
<jam> it would work better for you
<maxb> right, I'd better get myself to work now. I'll re-stare at trees
<maxb> later
<jam> vila, mgz: ping about tarfile exports. "tarfile.extractfile()" seems to hang indefinitely if you give it corrupt data. Which does exercise the test, but means it has a really bad failure mode
<vila> weird, what is hanging ?
<jam> f = tarfile.extractfile('path'); f.read() the .read() is hanging
<vila> O_o
<jam> I'll try to trace into it to give better detail
<vila> is there a pipe there ?
<jam> vila: nope, it is reading from disk
<vila> O_O
<poolie> hi jam, vila
<vila> _o/
<jam> vila: ah, maybe it is "assertEqualDiff being unhappy trying to match 800 lines of gobbledy-gook
<jam> vila: yeah, stopping the hang shows it in difflib
<jam> so better and worse :)
<vila> 800 lines ? That's a lot...
<jam> yeah, swapping out assertEqualDiff made it happier
<jam>     _file_content = ('!\r\n\t\n \r'
<jam>                      + '\n'.join([osutils.rand_chars(80) for i in range(800)])
<jam>                      + '\n')
<jam> doesn't seem very big to mee
<poolie> wow, that's a bit bad it would hang
<jam> me
<vila> hmm, please don't use rand_chars in tests, it is *guaranteed* to fail one day or another
<jam> poolie: it might just go O(N^2) and die, or it might have a real bug in the diff code.
<jam> vila: it is meant to
<jam> how do you expect it to fail?
<jam> (I need a way to force '\r' and '\n' in the compressed streams)
<jam> which has all sorts of "tar header", etc.
<jam> I can hand-craft something today
<vila> because you will encounter a combination that while unlikely will break the test ?
<jam> or I can throw enough random data at it, that I'm sure it has at least one char
<jam> vila: this is file content itself
<jam> if we are not managing to preserve exact fidelity
<vila> yeah, hand crafting is better, it's stable ;)
<jam> we have a problem
<jam> vila: except there are timestamps, and mtimes that will vary
<jam> which means that the real data may change its compressed form
<vila> still deterministic
<jam> vila: deterministic in the sense that time.time() is always changing?
<vila> yes, in predictable ways (except on vbox slaves but I digress ;)
<vila> so modulo restting the system clock, you can run the same twice and get the same result
<vila> introducing randomness is the opposite of test isolation :)
<jam> vila: still isolated tests
<jam> each test does not depend on the other
<jam> I can run 'osutils.rand_chars()' manually and hard-code it in the file, but that just bloats the test file (IMO)
<vila> and give us data to analyze if the test ever fails whereas rand_chars won't
<vila> and of course you're supposed to provide a sample that is not 80*800 chars long...
<vila> or said otherwise: if the test fails with 80*800 random chars, how would you debug it ?
<poolie> do we have any tests using rand_chars?
<vila> hmm, not much but grep rand_chars in bzrlib/tests find 15 matches (not all of them are relevant though)
<vila> ./test_lockdir.py:394:            lf1.nonce = osutils.rand_chars(20) seems valid for example
<poolie> mm
<vila> well, almost, there should probably be an assertion that we don't collide
<jam> poolie: indirectly almost all of them via 'gen_file_id()"
<poolie> we should probably make them deterministic
<poolie> right
<maxb> 2.3.1 is up in ~bzr/proposed - testers appreciated
<poolie> thanks maxb
<poolie> i'll install it
<poolie> jelmer, can you help me think of some other options?
<jam> vila: I used hard-coded data. Now the test fails intermittently
<jam> (explicitly not fixing the bug so that I know I should have a failing test.)
<jam> it was failing reliably with 64k data
<jam> it seems the timestamps are having a pretty strong effect on the compressed steram
<jam> stream
<vila> jam: then your data are not good enough ? Or you should isolate the test from the timestamps
<jam> vila: I can make it 64k data and be done with it
<jam> (which I had)
<jam> poolie: other options for? (and shouldn't you be sleeping by now?)
<vila> jam: huh ? You said bloating the test wasn't good no ?
<jam> vila: osutils.rand_chars(65536) isn't many characters in the file
<vila> <vila> or said otherwise: if the test fails with 80*800 random chars, how would you debug it ?
<jam> [osutils.rand_chars(80) + '\n' for i in xrange(800)] isn't much bigger
<vila> s/80*800/65536/
<vila> jam: how will you debug it if it fails ?
<jam> vila: if we are corrupting the data stream, it doesn't matter what the content is, IMO
<jam> vila: start looking for missing binary streams
<jam> if it is 100 random chars, does that help debugging?
<jam> same problem
<vila> yes the problem is the random part
<jam> to trigger it, needs enough random data, that you can't eyeball the corruption
<jam> vila: note that we also want to trigger it for raw tar, .tgz and .tbz2, and .tar.xz
<jam> and .tar.lzma
<vila> if the test is random it's not a reliable reproducing recipe, do we agree on that ?
<jam> vila: no
<vila> as I mentioned earlier, if the bug is too hard to reliably reproduce, I don't care about having a test for it as long as the diagnosis is 100%: we must use 'wb' and be done with it
<jam> vila: if the chance of failing is 1 in 2^256
<jam> I'm fine with that
<vila> but you're pulling this number out of thin air right ?
<jam> 65k bytes, compresses down to about 40kb. If you then have 1-in-256 chance per byte to be a '\r' or '\n', then your total chances are (let me grab a calc)
<vila> since you can only prove it to be right by establishing which inputs are valid/invalid
<jam> vila: given 10k compressed characters, the odds it not having what we want is  10^-17
<jam> vila: what bounds would you be happy with?
<vila> 0
<jam> vila: note, zlib changes the compressed stream from source from time to time
<jam> it is allowed to
<jam> for the same compression settings
<jam> as long as the actual decompressed content is the same
<jam> vila: I can't give you 0
<jam> I can give you epsilon
<vila> that's my point
<jam> vila: it means we can't force the compressed stream, but we can be really darn certain
<vila> the options are:
<vila>  1) no test
<vila> 2) test with a hard-coded reduced length
<vila> 3) test with random data
<vila> (3) is the worse because, a) it can't be debugged if it fails b) it will fail
<jam> vila: I disagree on (b)
<jam> if we are failing because of the content of files
<jam> then we have *serious* problems internally
<vila> do you have a fix for the bug ?
<jam> vila: certainly, but I would like to make sure we are testing all of them. Since mgz was kind enough to notice we had the same bug in other exporters
<vila> jam: can you seed rand_chars and guarantee you will get the same chars  ?
<vila> jam: can you still haven't answer: "How would you debug it ?"
<jam> vila: with 800 random characters I had 2 accidental successes in 30 runs
<jam> vila: looking at the stream isn't a way to debug it, regardless.
<jam> unless you know a way to debug a gzip stream
<vila> Is that a way to say it can't be debugged ?
<jam> especially a gzip(tar) stream
<jam> vila: it can be "oh it isn't getting the data back properly, I must have missed something"
<jam> but analyzing the data stream probably isn't the way to debug it
<vila> then how about forgetting about the compressed stream and ensures we never corrupt it instead ?
<jam> vila: we are corrupting the compressed stream
<jam> how do we forget about it?
<jam> 'bzr export -' is writing the stream to stdout, and we weren't setting the binary flag
<vila> by using a mock compressor ?
<jam> 'bzr export foo.tar.gz' was opening the output file without the binary flag
<jam> vila: the bug was both in the command
<jam> and in the individual code ptahs
<jam> paths
<vila> right
<vila> and the issue is that it was corrupted because somewhere 'w' was used instead of 'wb'
<jam> vila: if it was just the 'export -' we could put '\r\n' in the file content and 'plain_tar_export' it.
<jam> vila: right
<jam> plus the fact that GzipFile(mode='w') automatically sets 'wb'
<jam> so we had 'w' before
<jam> but we switched to GzipFile(open('w'))
<jam> and ooops, it broke
<vila> if you can't reliably inject a stream that would be corrupted because you don't control how it's transformed, I'm saying: control it
<jam> vila: GzipFile is going to be python-version dependent, and possibly platform dependent
<vila> indeed
<jam> how do you want to control it, since we want to be testing the specific code path
<jam> BzipFile happened to be ok, plain_tar_export was bad, GzipFile was bad
<jam> ZipFile I think was ok
<jam> I'd like to make sure that transforming the code paths in ways that look fine, still are actually fine
<vila> 'make sure' != 1e10-17
<jam> vila: osutils.rand_chars(65536)
<jam> 10^-17 is sure for me
<jam> if you prefer, I can make it
<jam> 10^-999
<vila> yeah, some japanese may disagree :-/
<jam> vila: /me => lunch, bbiab
<poolie> i've been feeling sad about that
<jam> poolie: ?
<jam> I didn't mean to go to lunch and make you sad :)
<poolie> :) the Japanese disasters
<poolie> hello inada-n, i hope you're doing ok
<inada-n> hello, poolie.
<inada-n> About earthquake?
<poolie> yes
<inada-n> I'm OK in Tokyo.
<poolie> good
<vila> good
<inada-n> Thanks, a lot.
* vila changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: poolie | 2.3.1 is officially out, 2.4b1 has been frozen
<jml> goaeruaeos
<jml> I have to figure this out every six months
<jml> how to get a list of landings I've done on launchpad
<vila> jml: some filtering from qlog maybe ?
<jml> vila: ahh, never mind. I apparently wrote a little plugin called pqmstats that does what I want
<vila> hehe :)
<vila> jml: don't tell me, you went: "Let's write a plugin to do X and let's call it pqmstats, oh wait, here is one !" :-D
<jml> vila: yeah, exactly like that
<vila> good, I'm not suffering from Alzheimer then ;D
<jelmer> hehe
<vila> jelmer: I think you miss my msg yesterday about lp:~vila/ubuntu/lucid/bzr/sru-2.1.3
<jelmer> vila: I think I might - what was it?
<vila> jelmer: can you have a look at it (no urgency), there is a dirty trick in debian/watch but I filed bug #736145 about it
<ubot5> Launchpad bug 736145 in Launchpad itself "no series specific download pages" [Low,Triaged] https://launchpad.net/bugs/736145
<vila> jelmer: 2.1.4 will be released soon so it's just a warm-up to see if I get it right
<jelmer> vila: what about https://launchpad.net/bzr/2.3 ?
<ubot5> Error: Could not parse data returned by Ubuntu: 2 (https://launchpad.net/bugs/2)
<jelmer> vila: it's only got the latest release, but that should be sufficient in our case
<vila> EPARSE, what about 2.3 ?
<vila> and what is your last remark about ? 2.1 or 2.3 ?
<jelmer> vila: there is https://launchpad.net/bzr/2.1 as well
<ubot5> Error: Could not parse data returned by Ubuntu: 2 (https://launchpad.net/bugs/2)
<jelmer> vila: So in the watch file we can just use the series-specific page, which will always contain the latest release in that series. For debian/watch that's sufficient
<vila> haaa, for watch file!
<jelmer> vila: well, that /is/ what you were asking about.. :)
<vila> jelmer: but these pages doesn't mention the tar.gz
<vila> jelmer: but these pages don't mention the tar.gz
<jelmer> vila: they do
<jelmer> just check https://launchpad.net/bzr/2.1 or https://launchpad.net/bzr/2.3
<ubot5> Error: Could not parse data returned by Ubuntu: 2 (https://launchpad.net/bugs/2)
<ubot5> Error: Could not parse data returned by Ubuntu: 2 (https://launchpad.net/bugs/2)
<jelmer> there's a link on the right hand side
<vila> ooooooh !
<vila> right, so for old stable series and as long as we are fast enough to keep track, yeah, far better than my dirty trick
<vila> jelmer: otherwise, is this branch a good base for 2.1.4 ? AIUI the first line in changelog should mention lucid instead of UNRELEASED but the rest should be ok ?
<vila> jelmer: or will 2.1.4 require a roundtrip via debian  (squeeze provides 2.1.2) ?
<jelmer> vila: the version should be 2.3.1-0ubuntu1
<vila> 2.1.3-0ubuntu1 you mean ?
<jelmer> vila: (your version is not intended to be uploaded to Debian but to Ubuntu, in case of debian it would be 2.3.1-1)
<jelmer> vila: sorry, yes
<vila> ok
<vila> 0 because 2.1.3-1 will come from debian and override it ?
<jelmer> yes, exactly
<jelmer> vila: it looks good to me otherwise
<vila> ok, thanks !
<jelmer> vila: one minor nitpick - maybe this is loggerhead's formatting - there should be one extra level of indentation for the + signs under "New upstream release"
<vila> oh, not loggerhead
<vila> the '+' should below the 'N'ew ?
<jelmer> it should have one more space than the *
<jelmer> so it should be below the space in the previous line
<vila> ha no
<vila> sry, was looking at wrong file
<vila> yeah, below the sapce
<vila> space
<g0nzal0> hello #bzr
<vila> hello  g0nzal0
<g0nzal0> I'm using bzr 2.2.1 with the svn plugin (version 1.0.4)
<g0nzal0> I'm trying to branch an svn repository, but said repository has a commit of a file named \
<philsf> I forgot to add a part of a message to a commit. is there a simple way to edit a log? This is a simple versioned directory, not a remote branch, fwiw
<vila> philsf: uncommit/commit if it's the last commit you did
<g0nzal0> the svn plugin conveniently checks for this and raises an exception
<g0nzal0> is there a way around that? I can't get a full copy of that svn repo with bzr otherwise :(
<maxb> g0nzal0: Actually, I think the forbidding of backslashes in pathnames is done in the core of Bazaar
<maxb> this means there's no way you can have such a file in a Bazaar branch, that you can work with using an unmodified copy of Bazaar
<g0nzal0> maxb, yes it is (tried commenting out the check on the svn plugin and got an exception from bzr)
<g0nzal0> magcius, the file is removed in the svn repo in a later commit
<g0nzal0> *removed from
<g0nzal0> I mean, maxb
<maxb> I'm not sure that will help you
<g0nzal0> it doesn't, bzr branch stops when it hits the commit that adds that backslash-named file :(
<jelmer> g0nzal0: the best way to work around it is to "svnadmin dump" the repository, eliminate the backslash and reload it
<g0nzal0> jelmer, ah, I don't think I have permissions to do that, but I can talk to the sysadmin and try that, thanks!
<jelmer> g0nzal0: there is a bug report in bzr about this, but it hasn't seen much activity recently
 * jelmer will be back later
<cr3> hi folks, someone seems to have merged changes in from a branch and merged into trunk. now, the revno in the trunk is 30 numbers smaller than before, what might've happened?
<beuno> cr3, they merged trunk into a branch and pushed that up to trunk
<cr3> beuno: that resulted in lots of commits being conflated into one, might there be a way to revert that or do something reasonable about it?
<beuno> I guess someone could push --overwrite
<beuno> if they have trunk
<cr3> beuno: yeah, "if they have trunk" is the problem, I just pulled from trunk so mine is reverted now :(
<beuno> hm
<beuno> not sure how to revert that easily
<cr3> beuno: I'm about to take the last snapshot I had, reproduce the commits that were done previously and then try to push that. I expect that to be a lot of work, so looking for the quick fix
<cr3> beuno: would the person that merged trunk into the other branch and pushed had to use --overwrite as well? ie, would bzr have provided somekind of warning to prevent this and required explicit action on the part of the user to proceed?
<beuno> cr3, no, no --overwrite
<beuno> you can, however, set a flag that won't allow this to happen again
<beuno> append_only or something
<beuno> I forget where to set it
<cr3> beuno: sounds like a good lead, thanks so much!
<philsf> vila: it was not the last commit. Can I uncommit/commit and still preserve the original revision number?
<cr3> beuno: I found that I can add this line to .bzr/branch/branch.conf: append_revisions_only = True. however, not sure how I can commit that so it applies to everyone branching the project
<beuno> cr3, that's a good question
<beuno> maybe lifeless knows
 * jelmer waves
<beuno> heya jelmer
<maxb> cr3: "commit" it? It applies to a particular copy of a branch, not a project.
<maxb> Usually you would set it on the branches on a server that people share
<maxb> Bazaar might copy it to new branches 'bzr branch'-ed from that - I'm not sure, you'd have to test.
<maxb> cr3: Before you try to regenerate any commits manually: You really do not need to. No data has been lost. Bazaar has just been instructed to understand it differently?
<cr3> maxb: I just tried locally: 1. created file .bzr/branch/branch.conf with append_revisions_only = True; 2. branched project to other directory; 3. looked at .bzr/branch/branch.conf in other directory: branch.conf does not get branched
<maxb> cr3: Is this project public? It would be easier to explain with specific examples. If not, I can explain more generically
<cr3> maxb: I managed to regenerate the data already and the diff (not bzr diff, just /usr/bin/diff) of my new branch and the one on the server seem the same now
<maxb> cr3: However I would still advise you *NOT* to push --overwrite that
<cr3> maxb: the project is public and, if you happen to have a moment, I wouldn't mind understanding how to resolve this kind of situation
<maxb> We can fix your revnos without forcing everyone else to "pull --overwrite" and potentially have to replay their own local commits
<cr3> maxb: really? why not?
<maxb> I don't understand the "why not?" question
<cr3> maxb: good point. although there are probably not that many people branching the project, I try to do things right when possible
<maxb> Ok - give me the URL for the branch concerned, and I'll have a look
<cr3> maxb: I meant "why not push --overwrite", but you answered before I hit enter :)
<cr3> maxb: lp:checkbox
<maxb> fetching..... meanwhile, have you used "bzr qlog" previously?
<maxb> I find it an awesome tool for understanding revision graphs
<cr3> maxb: the problematic revision is 864 and no, haven't used qlog before
<maxb> yikes, that revision merged an awful lot of trunk changes, didn't it :-)
<cr3> maxb: totally :)
<cr3> maxb: about 30 revisions worth :)
<cr3> well, 30 revisions based on difference of current revision in trunk and what it should be
<maxb> OK, so here's how we go about restoring the "left hand" or "first parent" ancestry that determines revnos
<maxb> First you branch lp:checkbox at 863
<maxb> oh, sorry
<maxb> I don't mean 863, 1 sec
<maxb> hmm. We need to find the revision which was the tip of lp:checkbox which was before that erroneous merge was pushed
<maxb> Ah, OK, so I think that was the current 862 "Merged from testsprint-checkbox-base-sru-changes."
<maxb> Right, let me start again, and get the numbers right this time
<cr3> maxb: I'll follow what you say in qlog
<mgz> vila: that was my impression with rand_chars as well, but jam is right. provided that the (teeny) chance of the randomness working against us results in a spurious pass rather than a spurious failure, it's the best way to write that kind of test.
<maxb> So, we branch from lp:checkbox 862, because that is the last revision that is part of the old mainline, which is still on the mainline.
<cr3> maxb: why not 863?
<maxb> Having looked at the history, it looks to me like the "bad" merge was an attempt to land the revision which is currently 863 on trunk
<maxb> More importantly, 863 is diverged from the long string of revisions which we want to put back on the mainline
<cr3> maxb: exactly, now I understand where you're getting at
<maxb> OK, so having done that, for the sake of illustration, you might choose to turn on append_revisions_only = True in the local branch
<maxb> then we're going to pull, not merge, r862.2.31 of lp:checkbox
<maxb> (and yes, we could just have branched that directly - this was either my mistake or a fortuitous illustration of exploring the history)
<maxb> :-)
<maxb> After that, we *merge* the formerly "bad" merge commit - i.e. we 'bzr merge -r 864 lp:checkbox'
<cr3> maxb: I'm doing bzr branch -r862 lp:checkbox then bzr pull -r862.2.31 lp:checkbox, right? I'm waiting for the first branch to finish, this is taking a while unfortunately
<cr3> aha, after that pull, I get: Now on revision 893.
<cr3> which is sounding very sane!
<maxb> And commit that with a message of something like "Land translation work by Mahyuddin Susanto via Michael Terry."
<cr3> maxb: you didn't forget 863, right?
<maxb> No, this is intentional - the one merge is going to pull in 863 & 864
<cr3> of course, my bad :)
<maxb> Once you've done this commit, you are back in the rough "shape" of the tree that you wanted to have kept all along
<cr3> maxb: this is amasing, really!
<maxb> The remaining thing is to merge (one by one if you want to preserve their mainline revnos in full) the remaining commits. Fortunately in this case there is only one.
<cr3> maxb: Thanks so much for taking the time to explain this to me, I'm keeping this irc log and framing it somewhere :)
<maxb> So, "bzr merge -r 865 lp:checkbox" (or for that matter just "bzr merge lp:checkbox")
<maxb> And commit
<maxb> and we're in our final desired state. Only thing remaining is to then push back to lp:checkbox - *without* --overwrite
<cr3> makes perfect sense
<cr3> excellent, so my contributors will not need to pull --overwrite themselves. win!
<maxb> To prevent it happening again, you can enable append_revisions_only on the Launchpad copy of the branch
<cr3> maxb: how can I ssh/scp/ftp there again?
<cr3> I once accessed the server to rm branches but that was a very long time ago
<maxb> If your local bzr is new enough, you can just run "bzr config -d lp:checkbox append_revisions_only=True"
<maxb> um
<maxb> wait a moment, I think that may not work
<maxb> bzr config -d bzr+ssh://bazaar.launchpad.net/+branch/checkbox append_revisions_only=True
<maxb> owing to a bug in current bazaar, you need to not use the lp: shortcut here
<philsf> I forgot to add a part of a message to a commit. is there a simple way to edit a log? This is a simple versioned directory, not a remote branch, fwiw. it was not the last commit. Can I uncommit/commit and still preserve the original revision number?
 * jelmer waves to spiv
<poolie> hi all
<jelmer> poolie: g'day
<poolie> hi jelmer
<poolie> jam, still around?
 * spiv waves back
<jelmer> spiv: Why do we never store directory service URLs but always resolved URLs? Is it since the way a directory service resolves a URL might differ per user?
<spiv> jelmer: I think it's just by accident, rather than design
<spiv> I'm pretty sure there's a bug or two about how we should store unresolved directory service locations.
<jelmer> spiv: I was looking at one of the bugs that the linaro folks were hitting, where we are calling urlutils.normalize_url() on a URL that can contain e.g. "lp:bzr"
<spiv> There is a bit of an issue that directory services might resolve differently, or even be not present at all, for different users.
<spiv> So I guess if we start storing them we should take care to handle that gracefully
<spiv> I wouldn't want my bzr to crash with a traceback just because someone else's branch I access has a parent_location with a custom directory service URL.
<jelmer> right, that makes sense
<jelmer> spiv: so I guess then a related issue is: is "lp:bzr" something that urlutils should handle gracefully?
<spiv> Hmm
<spiv> We're really mixing different types of variable
<jelmer> On the one hand it would be a nice solution here, but I'm worried about misinterpreting what could be a proper URL with an entirely different meaning
<jelmer> yeah
<spiv> "URL" and "location" might be good names for those types, if we had statically typed variables.
<spiv> Or "URL" and "BRL" ;)
<spiv> So in my ideal world, we'd never all normalize_url on something that isn't a proper URL
<jelmer> your ideal world has URLs ? :-P
<spiv> But we sometimes use them interchangeably, although sometimes not (the CLI isn't consistent about what it accepts)
<spiv> s/all/call
<spiv> To be pedantic, strictly speaking I didn't imply my ideal world would have to have URLs ;)
<poolie> <spiv> jelmer: I think it's just by accident, rather than design <-- i agree
<spiv> Anyway, given we mix URLs and not-quite-URLs quite a bit now, we have two options that I can see:
<spiv> 1) make functions like normalize_url that expect URLs also cope with not-quite-URLs
<spiv> 2) try to be stricter about not using not-quite-URLs interchangeably with URLs
<spiv> Maybe there are other options.
<poolie> i think 'lp:' is a proper url
<poolie> or 'should be treated the same'
<spiv> Or another way to look at it perhaps is: why is linaro calling normalize_url?  Is it because they really want "normalize_location" and that's the closest we have?
<jelmer> spiv: This is the stacked-on argument to cmd_push()
<spiv> Ah, right.
<spiv> So, essentially, yes :)
<jelmer> spiv: yes, indeed
<spiv> I don't feel strongly about which route we should take, but I do feel strongly that the current situation is a problem :)
<jelmer> :)
<jelmer> I think in the short term it would probably make sense to do the directory lookup in cmd_push for --stacked-on, as it's consistent with how we treat directory URLs in other places.
<lifeless> there is a bug on directory lookups in push :parent as well IIRC
<lifeless> so you'dfix more than one bug :>
<lifeless> sorry, I mean, while you're there consider doing more ;)
<spiv> I was about to say, I'm not sure that's the same bug (although I'm sure it's related)
<jelmer> is :parent a directory as well? It seems odd that it breaks in that case, as "bzr push lp:foo" works
<lifeless> jelmer: it needs to double dereference
<lifeless> jelmer: when :parent returns lp:foo it breaks
<jelmer> lifeless: ahh
#bzr 2011-03-18
<poolie> hi spiv?
<spiv> Hi poolie
<poolie> how are you?
<spiv> poolie: extra good now that I just hit "propose merge" on https://code.launchpad.net/~spiv/bzr/lockcontention-pushing-tag-733350-2.3/+merge/53947 :)
<ubot5> Ubuntu bug 53947 in mplayer (Ubuntu) "incorrectly disables gnome-screensaver" [Medium,Fix released]
<spiv> ubot5: uh, no
<spiv> poolie: and thinking that my timing with the changelog_merge plugin is pretty serendipitous!
<poolie> with linaro gcc?
<poolie> yes, it is
<spiv> I really only devoted more attention to it recently because it looked like relatively easy work for my cold-addled head last week.
<spiv> poolie: I'm still really enjoying the kanban board btw
<spiv> Even if some days I can't make things move as fast as I'd like
<poolie> i'm glad
<poolie> i'd like to make it read/write some time
<poolie> done
 * poolie goes to file a bug asking for 'tweak' state
<poolie> https://bugs.launchpad.net/launchpad/+bug/373078
<ubot5> Ubuntu bug 373078 in Launchpad itself "code review merge status and docs need clarity, particularly for 'tweak' cases" [High,Triaged]
<poolie> spiv, is https://bugs.launchpad.net/udd/+bug/653312 anything like the other importer bugs you were working on?
<ubot5> Ubuntu bug 653312 in Ubuntu Distributed Development "Import fails with NoSuchRevision" [High,Triaged]
<spiv> poolie: probably not, at a guess it'd be more like the "someone has done push --overwrite to a package branch that the importer doesn't know about" bugs
<mgiuca> Hello
<mgiuca> Can anyone tell me how to run the test suite?
<mgiuca> I am just trying to run 'python bzrlib/tests/test_log.py' for example, but nothing happens (because there is no test runner in that file).
<spiv> mgiuca: 'bzr selftest'
<spiv> mgiuca: or for just that file, 'bzr selftest -s bt.test_log' is quickest
<mgiuca> Oh, cool.
<spiv> see 'bzr selftest --help' for more details
<mgiuca> Thanks! I have done it before but I completely forgot.
<spiv> (Don't forget to use ./bzr if you want to test the bzr you're hacking on rather than the system one)
<mgiuca> Yup.
<mgiuca> OK got it working now. Cheers.
<mgiuca> (Had to download a custom version of testtools)
<vila> hi all !
<vila> poolie:, jam: I tried to better explain the fix for bug #735477, please re-review ;)
<ubot5> Launchpad bug 735477 in Ubuntu Distributed Development "some imports survive a kill -SIGTERM leading to massive log output and no kill" [High,In progress] https://launchpad.net/bugs/735477
<maxb> hmm, I should dust off my changes for better ordering of package imports when catching up
<vila> maxb: yeah for 2.3.1 in bzr/ppa !
<vila> maxb: so you ended up using dh_python for all series ?
<maxb> I ended up just not merging the change to use dh_python2 for now
<maxb> I think for the manually built PPAs it might be easiest to simply stick with whichever of python-support / python-central the package was previously using, for maverick and below
<maxb> For the recipe builds for {karmic,lucid,maverick} & {natty} ... we really want a solution which builds all series out of a single branch
<maxb> I have some evil machinations in mind
<vila> ha, excelllent, I was wondering if that was the sore point (using different packaging for different series and the associated fallouts)
<maxb> Mainly involving a PPA with packages for the older series which install a fake dh_python2 which actually runs dh_pysupport/central
<vila> sounds pragmatic to me (but not understanding the details...)
<poolie> maxb, yes, thanks
<poolie> vila, are you able to give any ideas on https://bugs.launchpad.net/udd/+bug/653312?
<ubot5> Ubuntu bug 653312 in Ubuntu Distributed Development "Import fails with NoSuchRevision" [High,Triaged]
<vila> poolie: isn't it a dupe of a bug fixed by spiv waiting for a more recent bzr version deployed on jubany ?
<poolie> i asked spiv and he thought it was something different
<vila> ha :-/
<vila> then no idea, I'm not yet to the point where I can retry such failures locally but I'm working towards this goal
<vila> poolie: err, just checking camlp5 and it's listed as failing due to bug #653320 instead
<ubot5> Launchpad bug 653320 in Ubuntu Distributed Development "Import fails with "marked but not imported"" [High,Triaged] https://launchpad.net/bugs/653320
<vila> couhdb is *not* listed as failing though
<jam> morning all
<vila> couchdb
<poolie> i don't know where couchdb has gone
<vila> (yeah, searched the right one in http://package-import.ubuntu.com/status/ ;)
<vila> hey jam !
<poolie> just an update for them might be good
<vila> poolie: well, if it's not listed as a failure, it's supposed to succeed ;)
<poolie> right, exactly
<poolie> it's possible the package changed name
<poolie> oh, would there be no page at all if it's passing?
<poolie> that seems unlikely
<vila> poolie: I think that's the way it works now: pages are created only for failures (and deleted once the import succeeds ?)
 * poolie looks
<poolie> sometimes the simplest answer is the best
<vila> poolie: in categorize_failures.py get_info() calls remove_obsolete_pages()
<poolie> perhaps we should leave them to avoid confusion?
<poolie> well, write "succeeded at blah"
<poolie> hooray
<vila> poolie: I think there is a bug asking to list succeeding imports too (where jam said we should have a different page for all the succeeding ones)
<jam> vila: yeah, I don't know if there is a bug, but certainly I've wanted it.
<jam> It is good to see the failures, but strange to have the page just disappear when they succeed
<vila> select * from revids where package='couchdb'; in meta-db hints that it succeeded at couchdb|1.0.1-0ubuntu9|natty|james.westby@ubuntu.com-20110129025244-i6nzlenngh54woq7|247954e4e2d02da1b1f49dfd059c0eb2aab39b75
<vila> jam: I'm pretty sure you *wrote* it somewhere :)
<poolie> the last commit was today which seems plausible
<vila> err, I meant the comment, not the page ;)
<vila> poolie: err, where do you see that ?
<jam> vila: I write stuff all the time. :)
<poolie> bzr log lp:ubuntu/couchdb
<poolie> or https://code.launchpad.net/~ubuntu-branches/ubuntu/natty/couchdb/natty
<vila> oh, bah, of course ;)
<poolie> i didn't think of it til i spoke to you
<poolie> i thought the absence of a page meant failure
<vila> Somthing escapes me there, the url above mentions 1.0.1-0ubuntu12 but not 1.0.1-0ubuntu9 and the opposite seem to be true on jubany (but maybe I don't know how to properly look on jubany)
<vila> wow, 1.0.1-0ubuntu13 appeared as we speak...
<vila> ha no, commit messages /tags misreading
<vila> right, seems like the packagers are faster than the importer then
<vila> 1.0.1-0ubuntu9 is revno 47 so this was created by the importer
<poolie> that's a big cover letter :)
<vila> oooh, so were ubuntu13 !
<vila> poolie: hehe, ryeah, sorry about that but I thought there were far too many hidden assumptions in my fix that led to far too many misunderstandings
<vila> did qlog always displayed the author instead of the committer or do I realize this only now because I don't often browse branches where they differ ?
<vila> s/displayed/display/ no ? I suck in English there :-/
<vila> I wonder if we should not use a private bzr version for the importer...
<vila> ISTM that if we rely on the system one we will sooner or later encounter cases were we are not allowed to deploy a fix system-wide for an import failure
<vila> related to that, turning the package importer into a bzr plugin may also make it easier to implement some features...
<Merwin> Hi. I've got a question : I work on openerp, which is a big project, and doing a bzr branch on it take a long time over my slow connection. So each time I need to create a branch, I have to wait almost 1 hour...
<Merwin> How could I avoid that?
<vila> Merwin: use a shared repository
<Tak> use a local shared...yeah
<poolie> Merwin, well, you should make a local repository, branch into that
<poolie> then just update your copy of trunk
<Merwin> So I branch for the origin location, and then re-branch for any modifications from my local directory ?
<Merwin> s/for/from
<poolie> correct
<Merwin> I there any options to pass for the 1st pull to specify that it's a shared repository?
<poolie> Merwin, you'll want
<poolie> 'bzr init-repo openerp'
<poolie> cd openerp
<poolie> bzr branch lp:openerp trunk
<poolie> then
<poolie> bzr branch trunk my-branch-1234
<Merwin> Ok, thanks !
<vila> Merwin: no, that's a local configuration which you can change after the fact with 'bzr reconfigure' but poolie typing faster than me explain what you should do when starting from scratch ;)
<spiv> vila: the upgrade to 2.3.1 will fix the 44 failures like http://package-import.ubuntu.com/status/adduser.html#2011-03-15%2022:54:36.634617
<vila> spiv: yeah, that was my understanding
<spiv> vila: I don't know of any other fixes in that update relevant to the package-importer
<vila> spiv: I thought the CHK ones weren't covered by one of your fix (landed in 2.3.[01] ?)
<vila> s/fix/dixes/
<vila> fixes even
<mr-russ> hehe, that was a piece of comedy to begin reading the channel.
<spiv> vila: the CHK ones already fixed
<vila> mr-russ: my pleasure :)
<spiv> vila: by deleting the damaged branches
<vila> haaaaa
<spiv> vila: and restarting those imports from scratch
<vila> and shouldn't the ones related to bug #653312 be deleted as well ?
<ubot5> Launchpad bug 653312 in Ubuntu Distributed Development "Import fails with NoSuchRevision" [High,Triaged] https://launchpad.net/bugs/653312
<spiv> vila: the revisions involved appear to all be quite old, so the best guess is it's some nasty bug we never even knew we had
<spiv> vila: but that we fixed ages ago
<poolie> i think i should stop
<poolie> good night all
<spiv> vila: it was pretty baffling, I don't 100% confident about the fix because the failure was pretty scary, I simply cannot see how we ever could have that sort of problem
<spiv> poolie: yes, probably :)
<spiv> poolie: good night
<poolie> thanks
<vila> spiv: I was under the impression that it was due to the too old bzr version used on jubany (before the 2.3b5 upgrade) and that we couldn't realize that without fixing 1) the branches on lp, 2) the bzr used on jubany 3) restart the imports from scratch
<spiv> vila: I don't know about 653312
<vila> poolie: enjoy your week-end
<spiv> vila: no, too old bzr was a theory we tried, upgraded, no difference
<spiv> vila: read the extensive bug comment history for the gory details :/
<vila> spiv: but did you do 1, 2 and 3 above or only part of them ?
<spiv> vila: I don't know what 1) means
<vila> argh, 1) delete the branches on lp
<spiv> vila: we did 2), upgrade to 2.3b5, but it turned out to be irrelevant
<spiv> In the end we completely deleted the branches on lp, the import records, everything
<spiv> There was a false start where we *thought* we'd deleted all the branches on lp, and some didn't get deleted.
<spiv> (Again, not sure why!)
<vila> yeah and doing that fixed the issue, hence me wondering about whether we should also delete the branches for the packages mentioned in bug #653312
<ubot5> Launchpad bug 653312 in Ubuntu Distributed Development "Import fails with NoSuchRevision" [High,Triaged] https://launchpad.net/bugs/653312
<spiv> It was an immensely difficult and confusing bug, the bug comments are your best reference :)
<spiv> Well, as I say I don't know about 653312
<spiv> It sounds like a different sort of problem to me
<jam> spiv: about the RetryWithNewPacks. I have the feeling there is something specific about what bzr-svn is doing differently from normal fetching
<jam> in particular, I believe it fetches N revs at a time
<spiv> The other one was about two different repos disagreeing about the contents of one revid
<spiv> (as in significantly different file contents!)
<spiv> 653312 is NoSuchRevision, which on the face of it sounds like a different category of problem
<spiv> jam: it's possible
<spiv> jam: but on my reading of the code I don't see how N revs vs. 1 rev or whatever could lead to the state that causes a traceback
<jam> sure
<jam> what I mean is that as it is fetching, it creates intermediate pack files
<vila> spiv: ok
<jam> so when it is done, it has many packs (some of which may have been autopacked, etc.)
<vila> spiv: and 2.3.1 is good to deploy for the 44 failures right ?
<spiv> jam: the main difference is that it always passes a hint
<jam> I agree that I'm not sure how it would have an effect, but we haven't seen it with just bzr
<spiv> jam: but the code path for dealing with hints looks robust
<spiv> And the test we wrote passes a hint
<jam> spiv: I believe it wasn't at one point, but should now
<spiv> vila: yes
<spiv> jam: I can't speak for the past, just for the code I've read recently :)
<spiv> jam: anyway, hopefully when exarkun re-enables the offending configuration we'll be able to get more insight
<jam> spiv: A note on the LockingContention issue
<jam> I like caching the master branch,
<jam> I don't like uploading a potentially large tag dict ,that we just downloaded from the master
<jam> I believe I missed the other problem, which is that fetching a new tag was correctly trying to also upload it to the master, but the master was still locked from the fetch
<jam> so that part I certainly like
<spiv> jam: oh, I meant to mention that in the cover letter
<spiv> jam: the master branch is write-locked throughout
<spiv> jam: which means the tags dict we just wrote it cachec
<spiv> *cached
<spiv> and so merge_to won't actually trigger any more actual reads and writes to the master's tags
<spiv> It'll do get_tags_dict, which will return the cached answer, and it'll be the same as the one we would write (usually anyway!  It would be possible but rare to have a situation where a master has more tags than an up-to-date bound branch), and so it would just return
<spiv> It would be a bit more direct, and not depend on caching of tags, to tell _basic_push to ignore the master, but also more disruptive to the API.
<spiv> (And caching the master is probably a good idea anyway)
<jam> it seems to be relying on happy coincidence, vs explicit statements, but I'm happy enough with it for now, then
<spiv> Either happy coincidence or robust performance design ;)
<spiv> I think _basic_push smells a bit, especially how it is actually not treated as private by bzr-svn
<spiv> So it'd be nice to perhaps try replace it with something better one day
<jelmer> yeah, it's a bit odd how all that works
<jelmer> vila: The plan is to have 2.3.1 in natty, right?
<vila> jelmer: sry was afk, but yes, it's our latest stable so it should go into natty. FFe AIUI but I don't know the process for that
<jelmer> vila: we need to do one for bzr-builddeb as well
<vila> jelmer: ok, does the fact that we have a MRE (Micro-Release Exception) for bzr has any influence on FFes (Feature Freeze exceptions right ?)
<jelmer> vila: I'm not sure, I'm not all that familiar with MRE
 * jelmer looks at the wiki
<jelmer> vila: do you know if MRE is documented anywhere?
<vila> jelmer: AIUI, MRE basically says: you're allowed to go into -updates so, IMHO, it should also takes precedence over FFe
<vila> yes, just a sec
<vila> https://wiki.ubuntu.com/StableReleaseUpdates/MicroReleaseExceptions
<jelmer> vila: Thanks
<jelmer> vila: It doesn't seem to mention FFe's, but I guess it would make sense if it did
<jelmer> vila: https://bugs.launchpad.net/ubuntu/+source/configobj/+bug/737491
<ubot5> Ubuntu bug 737491 in configobj (Ubuntu) "Sync configobj 4.7.2+ds-2 (main) from Debian unstable (main)" [Undecided,New]
<jelmer> https://bugs.launchpad.net/ubuntu/+source/bzr/+bug/737499
<ubot5> Ubuntu bug 737499 in bzr (Ubuntu) "Sync bzr 2.3.1-1 (main) from Debian unstable (main)" [Undecided,New]
<vila> jelmer: thanks, very informative
<vila> jelmer: what's the '+ds' ?
<jelmer> vila: I have no idea :)
<vila> lol
 * vila stops his internal TLA guesser (no, that's not debian stable ;)
<jelmer> heh
<jelmer> Ah, the changelog says:  * +ds version, as release zip file contains root-level __MACOSX directory.
<vila> ooh, hmm, so probably related to the fact that OSX loves to create .DS_Store files all over the place (hidden in the OSX finder so few people notice)
<vila> I don't really know what is stored there but at least icons positions and some finder prefs... should be totally irrelevant :-/
<vila> well, as far as packaging for non OSX oses is concerned at least
<jelmer> That's probably why Stefano removed it
<vila> jelmer: just noticed your discussion in #ubuntu-level with pitti :-/
<vila> jelmer: so what should be done then ? "Just" an SRU ?
<jelmer> vila: no, just the sync request I mentioned here earlier
<vila> jelmer: ha, ok.
<vila> I *will* understand one day, I will
<jelmer> vila: 2.3.1 is for natty, so there's no need for a Stable Release Update, as natty is not out yet
 * vila facepalms
<jelmer> vila: However, natty is past the feature freeze date. So releases that add new features require an exception (FFe).
 * maxb throws a build of 2.3.1 using dh_python2 in natty into bzr/proposed for sync semi-validation
<vila> maxb: because you built 2.3.1 directly in bzr/ppa right ?
<maxb> No?
 * vila blinks
<maxb> I previously built 2.3.1 using the old python-support / cdbs packaging in bzr/proposed
<vila> maxb: ghaa, that's the step I missed
<maxb> Now I'm building essentially the same package but with dh_python2 / dh7 packaging
<vila> the thing I love with silly questions is that I really learned something when I'm wrong :-}
<vila> nothing beats learning :)
<maxb> Later I will have the fun of backporting the cdbs->dh7 to maverick, but avoiding the python-support->dh_python2
<jelmer> maxb: why backporting of the cdbs->dh7 to maverick?
<maxb> Just to minimize unnecessary delta between series
<arand> I'm trying to "bzr checkout . . -r81" but I can't for the life of me figure out the syntax (I get error file exists ... ./.bzr)
<beuno> arand, . .?
<beuno> checkout into itseld?
<beuno> *itself
<maxb> "bzr checkout -r81" ?
<arand> Well I want to change the working dir to the state of revision 81
<arand> maxb: Same error: bzr: ERROR: File exists: u'/home/arand/utv/poppler/.bzr': [Errno 17] File exists: '/home/arand/utv/poppler/.bzr'
<maxb> arand: huh... could you pastebin 'bzr info' output please?
<arand> http://paste.debian.net/111121/
<jelmer> "bzr co" creates a working tree, that doesn't work if you already have a checkout
<jelmer> arand: try "bzr up -r81"
<arand> That seems to work, so I basically only had the log in text and no data for the history?
 * jelmer can't believe he wasn't aware of BZR_TEST_PDB before
<vila> jelmer: yeah, really handy when you need it ;)
<jam> vila, jelmer: I'm off to pick up the family. Have a good weekend
<vila> jam: same to you !
<jelmer> jam: You too, fijn weekend !
<psynaptic> I have a bound heavyweight branch checkout and have been committing locally using bzr commit --local
<psynaptic> I need to push a set of the commits to the upstream branch
<psynaptic> to avoid dumping thousands of line changes in one merge proposal
<psynaptic> is there a common workflow for this?
<jelmer> psynaptic: you should be able to unbind the branch and rebase
<psynaptic> so unbinding is like removing the central server info from the branch?
<jelmer> yeah - "bzr unbind"
<psynaptic> ok, done that
<psynaptic> there doesn't seem to be help for bzr rebase in our version
<jelmer> psynaptic: it's part of the bzr-rewrite plugin
<psynaptic> right, thanks.. will need to speak with infra about getting this added
<maxb> So, you want to squash lots of commits into a single one?
<maxb> psynaptic: ^ ?
<jelmer> psynaptic: you should be also be able to install it locally in your home directory
<psynaptic> maxb: nope, this is what I need:
<psynaptic> I have say local 50 commits
<psynaptic> I want to pick a point in time (a revno) and push all commits up to this point to the upstream branch
<psynaptic> I'd like to keep the history intact
<psynaptic> is this possible?
<maxb> Oh, so you don't want bzr rebase at all then
<psynaptic> oh ok
<maxb> "bzr push -r whatever"
<psynaptic> thanks, will try that
<psynaptic> need to speak with the reviewer to see what he wants merging first, will try in 10
<jelmer> psynaptic: has the mainline been merged since you did your first local commit?
<psynaptic> yeah
<psynaptic> I need to up
<psynaptic> but last time I did that I got all the commits dumped into my working copy with pending merge tips for each commit
<jelmer> psynaptic: In that case you indeed want bzr unbind + bzr rebase
<jelmer> bzr push -r will complain about diverged branches
<psynaptic> right
<maxb> Is rebase strictly necessary here?
<psynaptic> this is starting to get confusing!
<psynaptic> but it's hard for people to review 5000+ line *changes*
<jelmer> maxb: to avoid the merge commit, yes
<maxb> I'd be inclined to unbind, branch the local commits aside to a new branch, reset the working branch to current mainline, and then merge *some* of the local commits back from the second local branch
<jelmer> psynaptic: even with a merge the individual commits are still accessible for others to review
<psynaptic> jelmer: sure, but we use launchpad and the reviewer just sees the whole review as a bundle to review, if that makes sense
<psynaptic> also, my changes don't leave the working tree in a perfectly working state
<psynaptic> which is a pain
<jelmer> psynaptic: that doesn't really change if the revisions are all on the mainline though
<zyga> Hi, I was using branch.get_rev_id(revno), is there a similar method that would work with tags?
<jelmer> zyga: you can use branch.tags is the tag dictionary
<zyga> thanks!
<exarkun> On a Windows 7 machine (that I do not have direct access to), 'bzr checkout' is failing with this error message:
<exarkun> bzr: ERROR: File exists: u'C:/cylon/buildslave/bs/windows7-64-py2.7/.bzr/repository/upload/hvb53sfw5m0wa72323g6.pack': [Error 183] Cannot create a file when that file already exists
<jelmer> hi exarkun
<jelmer> exarkun: what version of bzr is that? It looks like one of the bugs spiv fixed earlier.
<exarkun> Hm.
<exarkun> I don't know what version it is.  Probably the version that was packaged in a Windows installer as of about a week ago.
<jelmer> actually, it's a different one
<jelmer> bug 376895
<ubot5> Launchpad bug 376895 in Bazaar "HPSS cannot rename-over packs on win32" [High,Confirmed] https://launchpad.net/bugs/376895
<psynaptic> jelmer: my revisions are all local, does this affect it?
<jelmer> psynaptic: does it affect what?
<psynaptic> jelmer: I may just be able to push all my changes afterall, will find out
<exarkun> jelmer: Okay, thanks.
<cr3> maxb: thanks again for all the help yesterday, much appreciated!
<maxb> Hello
<grettke> Question: I've got a checkout, and I want to "undelete" a directory that was removed in a previous commit... is the best way to do a pull of that directory at that previous revision?
<maxb> grettke: I think the simplest way is "bzr revert -r past-revision-number-or-id-or-tag path/to/subdirectory/that/no/longer/exists"
<knighthawk> is there a rpm for bzr-svn?
<knighthawk> or is it a plugin?
<maxb> The two are not mutually exclusive
<maxb> Answers are "Almost certainly" and "Yes".
<maxb> But I'm a Debian/Ubuntu person and shudder at the thought of RPMs
<knighthawk> lol -
<knighthawk> I'm almost 100% certain I've done a rpm install in the past but can't seem to find one today.
<OnionRings> hi
<OnionRings> ...
<thomi> Hi - I'm trying to use bzrlib.log.logger to generate a log of just the mainline branch revisions. I'm specifying 'levels=1' in 'make_log_request_dict', but I still get all levels. Any ideas what I'm doing wrong? Here's the four lines of code involved: http://pastebin.com/Wh7sP7nd
<thomi> hmm, it seems that I have to do something in my log formatter - I expected the settings in the request dict to determine what the formatter gets as input.
#bzr 2011-03-19
<cody-somerville> jelmer, Hey.
<jelmer> hey Cody, how's your evening?
<cody-somerville> jelmer, Not too shabby. Yours?
<jelmer> Pretty good too - fixing samba bugs :)
<cody-somerville> :)
<cody-somerville> jelmer, Quick question (IIRC, you're on the bzr team now - right?). I was giving a quick tutorial to a new hire on the OEM Services team the other day. Got him to install bzr on his recently installed Ubuntu 10.10 system. When I got him to run bzr launchpad-login he got this error: Unable to copy ownership from '/home/jagosta' to '/home/jagosta/.bazaar': IOError: [Errno 1] Operation not permitted: '/home/jagosta/.bazaar'. I see LP #657
<cody-somerville> 553 and LP #661678 regarding the same/similar error. Are there any consequence to this failure? Its also weird that such an error occurs on his nearly fresh install so I'm wondering if there is another issue at play.
<ubot5> Launchpad bug 657 in mozilla (Ubuntu) "mozilla-calendar no longer installable" [Medium,Invalid] https://launchpad.net/bugs/657
<ubot5> Launchpad bug 661678 in bzr (Ubuntu) "bzr whoami: unable to copy ownership from '$HOME/.bazaar' to '$HOME/.bazaar/bazaar.conf'" [Undecided,Invalid] https://launchpad.net/bugs/661678
<cody-somerville> It was the first bzr command he ran fyi
<jelmer> cody-somerville: It's indeed weird that this sort of thing happens on a fresh install
<jelmer> cody-somerville: are the permissions on his home directory reasonable?
<cody-somerville> jelmer, I asked if he changed them and he said no.
<jelmer> cody-somerville: hmm, did he perhaps install etckeeper or something else that runs bzr under sudo ?
<cody-somerville> jelmer, Impossible. I got him to install bzr so it was the first time bzr was run on the system.
<jelmer> cody-somerville: well, etckeeper is just another package - it will invoke bzr by itself
<cody-somerville> jelmer, It depends on bzr
<cody-somerville> jelmer, Installing etckeeper requires installation of bzr.
<jelmer> cody-somerville: right, that's what I mean
<jelmer> cody-somerville: I'm wondering if perhaps he installed etckeeper before he ran bzr as a regular user - etckeeper invokes bzr but with the wrong home dir set somehow and triggers the creation of ~/.bazaar as root.
<cody-somerville> (or another vcs to be accurate but I doubt he had installed another vcs). No. I was on the phone with him while he installed bzr.
<jelmer> cody-somerville: so ~/.bazaar exists - what are the permissions of that directory?
<cody-somerville> jelmer, I'm not sure. Didn't investigate much as we had quite a bit to talk about on the call and saw the other bug reports and see it was non-fatal.
 * cody-somerville can get further details on Monday.
<jelmer> cody-somerville: that'd be great
<cody-somerville> jelmer, He said it also printed out 'No handlers could be found for logger "bzr"' before the error about chown.
<jelmer> cody-somerville: Ah, that's useful info. That happens (among other situations) if bzr can't open ~/.bzr.log
<jelmer> so it sounds like his home directory had weird permissions somehow, that would be good to double check.
<leo2007> hello, I am behind unstable connection. Is there a way to resume cloning a branch?
<leo2007> The connection is also no fast.
<cody-somerville> leo2007, You could try incrementally fetching sets of revisions manually.
<cody-somerville> leo2007, ie. create a checkout of revision 1 then update another n set of revisions over and over until you get to the latest revision.
<leo2007> cody-somerville: thanks. I am new to bzr. I want to commit to https://savannah.gnu.org/bzr/?group=emacs
<leo2007> I have heard that the initial is about 2G.
<leo2007> 'initial checkout'
<cody-somerville> leo2007, ah. They let you use rsync to fetch it
<leo2007> that's faster is it?
<cody-somerville> leo2007, lt handles resuming well. Should help you create initial checkout faster yes if you have connection issues.
<lvh> Hi!
<lvh> Is there something that supports Bazaar that does something similar to merge proposals but isn't Launchpad?
<lifeless> lvh: reitvald I think
<lvh> lifeless: rietveld does code review, which I suppose isn't completely unrelated, but...
<lvh> Hm.
<lifeless> lvh: merge proposals are all about review
<lvh> Right: that expression was somewhat unfortunate
<lvh> They're a particular way of doing code review that makes it easy to review code when it matters (ie when it reaches trunk)
<lvh> I suppose the largest difference is that most external code review tools are, unlike Launchpad and Github, typically not aware of new commits after initial reviews
<lifeless> goes with the territory
<lvh> Yeah :-(
<lifeless> do you need something private? or inhouse? or <...>?
<lvh> In-hopuse.
<lvh> house, too.
<lvh> Helping someone else pick something: if it were up to me I'd just use Launchpad already.
<lvh> (Or github -- but they like git for some reason.)
<lvh> (On a similar note: why is bug tracking still such a pain?)
<lifeless> its hard ;)
<lvh> that's what we said about version control before bzr
<lifeless> A:0
<lifeless> bah
<lifeless> :)
#bzr 2011-03-20
<kingos> hi all, I am trying to hack together something, and just need some basic info
<jelmer> hi kingos
<kingos> Given I have a revision, how can I call bzrlib/diff.py show_diff_trees
<kingos> hi jelmer :)
<kingos> specifically, where do I get the old_tree and new_tree from
<jelmer> kingos, you can get old and tree new from a repository
<kingos> ok
<jelmer> kingos, more specifically, from the revision_tree() method
<jelmer> alternatively, either one of them can be a WorkingTree instance
<kingos> I want to do the equivalent of diff -c
<kingos> I already have a revision, must have it from a repository I guess.
<kingos> so do I do something like repository.revision_tree(revision)?
<jelmer> kingos, a revision object you mean?
<kingos> yeah
<kingos> I already have a revision object.
<jelmer> revision_tree takes a revision id - so e.g. revision.revision_id
<kingos> ok
<jelmer> if you want -c like behaviour you'd need the left hand side parent
<jelmer> so revision.revision_id for new_tree, revision.parent_ids[0] for the old_tree
<kingos> so I should be able to do repository.revision_tree(revision.revision_id), repository.revision_tree(revision.parent_ids[0])
<kingos> sweet
<jelmer> kingos, yep
<kingos> do I need to worry about all this locking?
<jelmer> kingos, not for these calls
<kingos> jelmer: is there a way I can get a repository from a revision?
<kingos> jelmer: don't worry, passed it in from earlier
<kingos> bzr: ERROR: exceptions.NameError: global name 'osutils' is not defined
<kingos> bzr.dev/bzrlib/commands.py", line 926, in exception_to_return_code
<spiv> kingos: presumably you need a "from bzrlib import osutils" among your imports
<kingos> so, I know this is probably basic python, but if I just declare a variable (ie. string) like:
<kingos> str = ''
<kingos> then call ret = show_diff_trees(old_tree, new_tree, str)
<kingos> is that ok?
<kingos> ok, as well, now that I import osutils, I still have a problem with that exception_to_return_code.
<Buttons840> i've decided my current revisions are no good; i hate to throw my work away so i'm going to branch what i've done -- how can i create a new branch with the changes in my working tree (i don't want to commit or revert in my main branch)
<kingos> I presume that must be because show_diff_trees is probably throwing an exception right, and for whatever reason it thinks I am trying to hook that exception up to a return code.
<jelmer> Buttons840, create a new branch with the revisions you want, then run "bzr merge --uncommitted ../original-branch" in that branch
<kingos> more specifically, IndexOutOfRange in "exception_to_return_code"
<jelmer> kingos, Can you pastebin the full backtrace? exception_to_return_code is probably not where the actual exception is being raised from
<Buttons840> jelmer: thank you
<jelmer> Buttons840, np
 * jelmer gets some sleep
<kingos> jelmer: it doesn't like the parent_ids
<kingos> ie. old_tree = repository.revision_tree(revision.parent_ids[0])
<spiv> kingos: can you pastebin the full traceback?
<kingos> well, that is pretty much it
<kingos> I mean, it is code I am writing.
<kingos> I have a revision object, it correctly has a revision_id, but parent_ids is empty.
<kingos> when I print revision.parent_ids, I get: parent_ids is : []
<spiv> So it is a revision with no parents.
<kingos> ok
<spiv> Presumably then its revision_id is "null:"
<kingos> no
<kingos> revision id is:  blah@bblah.com-20100905084816-c0d6456c1d5bec4e
<spiv> Oh, it's probably the first revision.
<spiv> As 'null:' isn't used as an explicit parent
<kingos> it is revision 4 in my trunk
<spiv> Then it has at least one parent, revision 3, by definition.
<kingos> ah hang on, you are right
<spiv> What does "bzr log --show-ids -r revid:blah@bblah.com-20100905084816-c0d6456c1d5bec4e" show
<kingos> it must be the first revision
<kingos> I forgot I was iterating over all revisions :)
<kingos> so I guess now I need to work out if show_diff_trees handles a null old_tree
<kingos> which it doesn't :(
<kingos> is there an "empty tree"?
<spiv> Sure
<spiv> from bzrlib.revision import NULL_REVISION; empty_tree = repo.revision_tree(NULL_REVISION)
<spiv> (where 'repo' is your repository object)
<kingos> ok, that looks like it is working :)
<kingos> now I tried passing a string into show_diff_trees, but it has no attribute "write"
<kingos> what python object do I need to pass in?
<kingos> don't want stdout, I just want the equivalent of a c++ stringstream
<kingos> I appreciate trying to learn python by hacking bzr is probably not the best way of doing things
<spiv> See the StringIO module in Python's standard library
<spiv> (or the cStringIO module for a faster implementation of the same thing)
<kingos> spiv: thanks a lot, think this is going to work :)
<spiv> Learning python by hacking bzr is probably not the best way, but it's far from the worst!
<leo2007> hello
<leo2007> How to synchronise local branch to remote one?
<leo2007> My tree is at rev 103687 where the remote is already at 103690
<bob2> bzr pull <someurl>
<leo2007> Some files are changed in my local tree. Can I go ahead and do that?
<bob2> well, you should commit them
<bob2> guess it depends if you use a bound branch or not, too
<bob2> ugh bound branches
<leo2007> bob2: thanks. I am behind slow connection which does make my experience a bit miserable. Anyway, I have encountered 'Text conflict in lisp/ChangeLog'.
<spiv> leo2007: the bzr-changelog-merge plugin (which will be distributed with bzr 2.4 when that is ready) is likely to help there
<spiv> leo2007: but probably it's not too hard to just open that file and resolve the conflict by hand.
<leo2007> I have three files extra: .BASE .THIS and .OTHER
<leo2007> excellent, seems resolved.
<leo2007> How to set up a default url for bzr pull?
<bob2> --remember
<leo2007> Thanks very much.
<leo2007> Is bzr push the way to propagate local commits to remote?
<sobersabre> hi.
<sobersabre> I want to create a tree which I can branch/checkout from out of a subdir of a root repository folder.
<sobersabre> say /project is a repository.
<sobersabre> inside it I have /project/module1
<sobersabre> I want to create a REPOSITORY from /project/module1
<sobersabre> I thought if I ran bzr split /project/module1
<sobersabre> and then I ran bzr co /project/module1 mymodule1 somewhere I'd get what I want.
<sobersabre> but what I got was: mymodule1/module1 which is NOT what I wanted.
<sobersabre> I wanted to have mymodule, mapped to /project/module1 for commits/etc.
<sobersabre> I found out I needed to commit some things.... works now!
<sobersabre> thanks
<x97mdr> hey all
<x97mdr> Was wondering if anyone here has tried bazaar with the very latest releases of IronPython?
<mgz> nope, but it will have the same issues the previous release had.
<mgz> particularly, lack of an implementation for bzrlib.lock and lack of some required modules like zlib and bz2
<mgz> see my old post to the bzr list for more details.
<mgz> oh, and it's horribly slow.
<mgz> they got the startup down from tens of seconds to single digit seconds, but that's still painful for a command line tools, you'd not want to use it unless you were keeping a process running.
<x97mdr> ahhh ok, thanks.  was toying with the idea of adding Visual Studio support and thought maybe IronPython would be a good candidate to try implementing it with
<mgz> it might be, and would probably work.
<x97mdr> would love to see bazaar used more in my organization but without "visual studio support" the microsofties there likely won't look at it
<x97mdr> wouldn't do anything crazy with it, mainly push/pull/commit sorta stuff
<mgz> if you can get the c# stuff needed for vs integration done, calling out to bzr for those operations isn't hard.
<mgz> either by launching cpython, or merging up my noncpython branch and running directly
<x97mdr> wth vs2010, writing source control providers is much easier than it was in previous versions
<x97mdr> ok thanks, i'll look into it more.  i see there was a project that attempted an integration before but i guess it never came to fruition?
<mgz> yeah, not to my knowledge.
<x97mdr> thanks again
<mgz> https://lists.ubuntu.com/archives/bazaar/2009q2/060028.html <- mailing list post I was talking about
<mgz> since then, got fixes for most of the file handling issues landed in ipy, refcounting issues and a few unicode things fixed in bzr
<mgz> you'll need my lock implementation, sys.platform changes, and jeff hardy's zlib module still.
<x97mdr> i noticed that zlib is included in the official release now (2.7)
<mgz> ah, one of the benefits of not being a ms-only project anymore then.
<x97mdr> might need your lock implementation and sys.platform changes still though
<mgz> I can merge up the old branch to current quite easily if you get as far as needing it.
<x97mdr> i just tried compiling lp:bzr with this command line (%IPYDIR%ipy setup.py build_ext --allow-python-fallback install_lib --no-compile install) and got an ImportError: no module named tty
<x97mdr> I guess I will try your noncpython branch instead :)
<mgz> yeah, try that to start.
<mgz> it's lp:~gz/bzr/noncpython
<x97mdr> it's unfortunate one has to go through all this work to get vs integration when its really not necessary.  some people just can't let go of the "checkin/checkout" idea in visual studio i guess :)
<x97mdr> if i can get your noncpython branch built, then i should try merging in the latest lp:bzr and retry?
<mgz> it will probably be a somewhat painful merge, yell at me instead and I'll do it
<x97mdr> ha! fair enough.  it looks like its been disconnected for a couple of years now?
<x97mdr> i guess this was your post on stackoverflow was it: http://stackoverflow.com/questions/1909057/bazaar-vcs-under-ironpython
<mgz> yup, both jython and ipy have just been too far off practicually usable, though there's still occasional interest
<mgz> ironpython is mostly there (as zlib is now in, yeay), provided you're not launching processes all the time, which is just tooo slow still.
<mgz> jython needs proper file handling code written for it that bypasses java.
<mgz> ^and yup, that's me.
<x97mdr> i guess one could try to keep a single process open and reuse it?
<mgz> I'm not sure how VS wants things done, but you can probably run the code directly in-process
<x97mdr> while i'm here i have to pass along kudos.  i've been using bazaar for over a year now as a subversion "super-client" and its been magical, jut a great piece of software
<x97mdr> ok trying the compile on the noncpython branch
<x97mdr> hrm, seems to have mostly worked, getting a few errors though.  keep in mind this is purely downloading ironpython 2.7 and your noncpython branch.  no other extensions or changes
<x97mdr> looks like its having trouble loading 'changelog_merge', 'news_merge' and 'weave_fmt' plugins
<x97mdr> other than that its working like a charm
<mgz> ha. yeah, I'd be suprised if many plugins worked... but those are from the latest version, which implies they got left over from your previous install attempt
<mgz> (and should be removed)
<x97mdr> i removed the plugins and 'bzr plugins' works like a charm now
<x97mdr> sorry, the above was for mgz :)
<mgz> x97mdr: it would be good to post to the list if you make any progress with VS integration, there's been a fair bit of interest in that in the past
<x97mdr> i will, thanks for the assist!
<abli> Hi! is there a maintained gitosis-like thing for bzr? bazitis appears to have been last updated in 2008, and I am getting 'Permission denied' when I try to check out the admin repository, even though I am following the instructions to the letter.  I would really like to use something gitosis-like, ie. where I can set permissions by commiting in a given repo, I assume others like this way of operation, too.
<abli> What is the recommended for light-weight, permission-controlled hosting of read-write bzr repos (i.e so one can branch from and push to the hosted repo)
<mwhudson> abli: there's a new thing by thumper called 'sloecode'
<mwhudson> it's not gitosis-like wrt access control, though that might not be that hard
 * abli checks out sloecode
<abli> well, that looks (from the announcing blogpost) more like a 'launchpad lite'
<abli> And the "Installing [...] is a bit messy" part is what I would like to avoid.
<mwhudson> i said it was new :)
<abli> Anyway, I managed to get bazitis work, so I might stick to that.
<mwhudson> ah cool
<thumper> abli: sloecode is designed to do primarily code hosting right now
<thumper> abli: projects have repos and branches
<thumper> abli: there are several active developers who are wanting to push it forwards
<thumper> abli: the LP bits were the ssh authentication and plugin bits used as a starting point
<coreGrl> hi
<coreGrl> I've a little project under bzr, I want to backup it on dropbox, what's the best way to .."clone" a repository? cp? :)
<mgz> what interfaces does dropbox provide you? you may just be able to `bzr push ftp://...`
<mgz> otherwise (with a few caveats, like shared repos) cp is fine too.
<coreGrl> mgz, uhm dropbox syncs a folder to with a web service, so you can sync this folder on different locations, suppose to have a repository at work, then copy it to dropbox, at home you can access to this folder with the copier repository
<mgz> oh, it has its own client you run on your machines? ...why don't people just use the standard mechanisms...
<mgz> anyway, yeah, that will work fine provided #1 you sync the bottom most folder that contains a .bzr directory and #2 the sync doesn't happen while bzr in running and then doesn't notice the full changes
<coreGrl> mgz, cause it's for free :) they gives u more than 2GB of free space
<mgz> I know that the ubuntu cloud thing amusingly didn't work with bzr (at one point at least), but anything that does file access sensibly should be fine, and windows locking will protect you better than nix does
<mgz> if it's a click-to-sync rather than auto-sync then you can just make sure bzr has finished before you trigger it.
<coreGrl> tank you mgz
 * mgz is crushed under the caterpillar tracks
<GungaDin> I'm trying to rebind my checkout to a different branch with reconfigure but keep getting an error saying my directory isn't a branch
<GungaDin> how do I do that?
<maxb> with reconfigure?
<maxb> Surely you want bind for that?
<fullermd> You probably want switch...
<maxb> ahh... yes - don't use the word 'bind' here, it means something different in Bazaar terminology
#bzr 2012-03-12
<Freejack> Alright. I've installed bazaar and I'm using directories in my home directory from the working directory, but I've set up another directory/partition under /opt/archives for the repository. What's the proper way for getting bzr to use this configuration, since I'm not using anything network related.
<poolie> hi wgz
<poolie> Freejack, just make the repository in /opt and check it out locally
<poolie> bzr checkout --lightweight /opt/archives/project/trunk ~/work/projcet
<Freejack> Heh. That simple eh?
<spiv> Freejack: I'm sure we can find a way to make it more complex if you want ;)
<Freejack> That's alright. This'll do.
<bob2> was lightweight originally a plugin?
<spiv> bob2: not that I recall
<Freejack> Hrmmm....need to set up the permissions properly. Commit fails.
<Freejack> It works!
<Freejack> Got some hacking to do. bbl.
<Noldorin> hey poolie, jelmer
<poolie> hi there
<poolie> hi all
<vila> hi all !
<mgz> morning all
<ggherdov> HI all. Is there any news about this request https://bugs.launchpad.net/bzr/+bug/269095 , or the page contains the most up to date info (i.e., it's unassigned and low priority) ?
<ubot5`> Ubuntu bug 269095 in Bazaar "bzr missing "cp" command for forking files /w history" [Medium,Confirmed]
<ggherdov> oh, that bot is cool indeed.
<mthaddon> hi folks - I consistently get a traceback when tab completing in precise for a bzr command, but apport tells me the bug is fixed released - https://bugs.launchpad.net/ubuntu/+source/bzr-git/+bug/903639
<ubot5`> Ubuntu bug 903639 in bzr-git (Ubuntu) "bzr crashes on bash tab-completion" [Medium,Fix released]
<mthaddon> jelmer: you seen anyone else with that issue in precise? ^
<mgz> if you run `bzr plugins` what version of bzr-git does it say you have?
<vila> jelmer: bug 941672 is said to be fix released in 2.5.1 but doesn't appear in lp:bzr/2.5 O_o
<ubot5`> Launchpad bug 941672 in Bazaar ""bzr help branches" crashes with bzr: ERROR: exceptions.AttributeError: 'Option' object has no attribute 'get_help_topic'" [High,Fix released] https://launchpad.net/bugs/941672
<vila> jelmer: but is merged on trunk with a news entry in 2.5 >-/
<mthaddon> mgz: not installed
<mgz> mthaddon: then it's not actually the same bug? and fdt...
<vila> mgz: morning !
<mthaddon> mgz: sure, but apport keeps directing me to that - so I should just file a new one?
<mgz> run `BZR_PDB=1 bzr bash-completion` and see what the actual plugin with the missing option is?
<mthaddon> mgz: http://paste.ubuntu.com/880112/
<mgz> u
<mgz> u
<mgz> p name
<mthaddon> review-submit
<mgz> okay, er... which plugin provides that? :)
<mgz> bzr help commands|grep review-submit
<mgz> anyway, new bug against that plugin should do, if it's on the latest version
<mgz> and I shall fix.
<mthaddon> review-submit      Submit a review. [lpreview]
<mgz> ^morning vila!
 * mgz branches lp:bzr-lpreview
<mthaddon> I have an out of date version - let me update and check
<mgz> seems to be unchanged in trunk, resolving it now
<mthaddon> yeah, still getting the same with trunk
<vila> mgz: can you vote on https://code.launchpad.net/~vila/bzr/940164-native-texinfo/+merge/96796 ?
<vila> not super important but a bit of a pain for me to not be able to run the full test suite anymore :-/
<vila> (the laternative being to uninstall sphinx which I rather avoid ;)
<vila> alternative even ;)
<mgz> yup, will flag that approved
<mgz> hm, don't have push rights to bzr-lpreview
<vila> ta
 * mgz proposes
<vila> sudo push
<mgz> mthaddon: lp:~gz/bzr-lpreview/dry_run_option_not_global
<mthaddon> thx
<mgz> so...
<mgz> bzr-svn is broken because I didn't update the version in the all-in-one installer
<mgz> bzr-git is broken because I did update the version in the all-in-one installer
<mgz> how am I meant to know what versions to include again?
<mgz> this was with my special copy-what-doxxx-does method, which apparently isn't enough
<vila> mgz: well, basically, as a packager, you should either release the tip *OR* rely on upstream to flag the version you're supposed to package
<vila> i.e., you're responsible but not gulty ;)
 * vila bbl
<jelmer> argh, getting the right plugins together for a release is still a nightmare :-/
<jelmer> mgz: sorry about that
 * mgz hugs jelmer :)
<jelmer> \o/
<jelmer> This keeps coming up though, I wonder what the best approach here is. We do quite a bit of automated testing for individual projects but not for the thing as a whole.
<mgz> yup.
<mgz> well, one thing is I'd like to run selftest after install and have it actually pass, which would catch some dumb stuff like this.
<maxb> mgz: Well, if it helps at all the ppa appears to be installable, and I don't see any complaints running 'bzr plugins' with all the packages installed
<mgz> maxb: and what's your method of knowing what versions of plugins to include? perhaps I can copy.
<maxb> mgz: This is also known as the mostly-copy-what-jelmer-does-in-sid method :-)
<mgz> heh.
<maxb> Or slightly more usefully, take the latest release of everything, and bump up to a snapshot where something complains
<maxb> Though my view of latest release is slightly skewed since I use Debian sid as a convenient aggregator of latest versions
<mgz> package management does solve a few issues :)
<jelmer> a related issue (I think) is that it should be possible to just run "bzr selftest" and have everything pass, even with plugins installed
<jelmer> some plugins currently break in that case - e.g. bzr-search registers some hooks which add extra HPSS calls and then break some of the blackbox tests
<mgz> yeah, I saw that bug
<mgz> there was a thread a while back
<jelmer> I'm also seeing a really weird bug where bzrlib.tests.test_msg_editor seems to be running vim
<mgz> about whether it was right to run tests with plugin hooks installed or not
<mgz> there were arguments both ways, makes them less reliable if you do, but doesn't test real world situation if you don't
<mgz> jelmer: sounds very possible, probably an isolation issue, there's a msg_editor command that will fallback to vim if earlier things fail
<mgz> s/command/function/
<jelmer> mgz: the weird thing is that it only happens if I run bzr selftest with (some) plugin installed
<Ng> hmm, if I run into a NoSuchId error while committing with bzr 2.1.4, is that something that's likely to be repairable?
<Ng> I had about 12 processes committing from scripts, and presumably two of them have clashed somehow
<jelmer> Ng: can you provide some more context? NoSuchId just means something wasn't found
<Ng> jelmer: sure, I'll get you the error
<Ng> (pasted in private)
<Ng> all sorts of weirdness is now going on, the current revno is claimed to be 1, but the older revisions still somewhat exist, so they end up being claimed to be negative
<Ng> (if it's relevant, there are 58395 revisions in total)
<vila> jelmer: hi !
<vila> jelmer: did you see my previous msg about bug #941672 ?
<ubot5`> Launchpad bug 941672 in Bazaar ""bzr help branches" crashes with bzr: ERROR: exceptions.AttributeError: 'Option' object has no attribute 'get_help_topic'" [High,Fix released] https://launchpad.net/bugs/941672
<vila> jelmer: landed on trunk but not on 2.5
<vindolin> how do I extract a subdirectory from an existing bzr repo into a new repo while keeping the history?
<mgz> vindolin: broadly two options, `bzr help split` or fast export, filter, fast import
<mgz> the first keeps the entire repo history unchanged, which may not be what you want if most changes are unrelated to that subdir
<mgz> the second creates a new history that looks like the old one, which will be smaller but can be confusing
<jelmer> vila: ah, I'll have a look at landing it on 2.5 too, seems appropriate for there
<vila> jelmer: especially given the bug milestone ;)
<vila> jelmer: and the news entry !
<vila> :-D
<jelmer> Ng: hmm, that does look pretty odd
<jelmer> Ng: can you perhaps try running 'bzr rm' (no arguments) before commit?
<vila> mgz: meh, can't find back the bugs about running the smart server as an external process for tests
<jelmer> Ng: other than that, I don't have any idea what this might be..
<Ng> jelmer: doesn't help I'm afraid
<mgz> vila: bug 866111
<ubot5`> Launchpad bug 866111 in Bazaar "Run tests against out of process smart server" [Medium,Confirmed] https://launchpad.net/bugs/866111
<Ng> jelmer: shall I file a bug? It's going to be kinda hard to reproduce
<jelmer> Ng: is there any chance you can try with a more recent version? 2.1 is really old
<vila> damn it, selftest tag tot test
<vila> mgz: ta
<Ng> jelmer: I've copied the borked tree over to a machine with 2.5.0 on it and that can't commit either, running the plain "bzr rm" there hasn't helped
<jelmer> Ng: in that case, it would be great if you could file a bug
<Ng> jelmer: sure thing
<Modnar> hi
<Modnar> I'm trying to do a branch on Windows 7 & keep getting this error bzr: ERROR: short readline in the readvfile hunk: 'Bazaar pack format 1 (introduced in 0.18)\r'
<vila> mgz: commented on https://code.launchpad.net/~gz/bzr/https_proxy_host_matching_944696/+merge/96803, we can discuss further when you're available
<mgz> neat, thanks vila, will probably have lunch first :)
<vila> ha yeah, that weird TZ ;)
<Ng> jelmer: 953005 filed, thanks
<Timara> hi all!
<Timara> could someone please help me in using bzr+trac?
<Timara> I have a problem with the post-commit hook, and got confused about the many support pages I read
<smoser> ok... stupid question
<smoser> bzr diff -r $(bzr revno)
<smoser> and
<smoser> bzr diff
<smoser> should basically be the same thing
<smoser> right?
<jelmer> hi Timara
<jelmer> smoser: yes
<Timara> Hi jelmer!
<smoser> yeah.
<jelmer> Timara: what's your question?
<smoser> i have some local branch that i've beeen doing udd on that is now in a state where it thinks bzr revno is '80'
<smoser> and 'bzr revert' does nothing
<smoser> but bzr diff -r $(bzr revno)
<smoser> shows diff
<Timara> a have set up a trac server on a remote machine and would like to use: bzr commit -m "Fixed an awful bug" --fixes remote:123
<Timara> trac-bzr plugin is installed on the remote
<Timara> sorry, bzr commit -m "Fixed an awful bug" --fixes remote:123 bzr+ssh://centralhost/proj1
<Timara> trac wouldn't show the ticket 123 fixed
<Timara> when I issue a trac-admin changeset added /srv/bzr/proj1 4
<Timara> nothing happens
<Timara> what configuration shall be done in the local or the server side to update trac with each commit?
<jelmer> smoser: it sounds like your tree is out of date with your branch; does "bzr up" do anything?
<jelmer> Timara: I don't think trac can look at revision properties for recognizing fixed bugs yet
<smoser> jelmer,
<smoser> $ bzr up
<smoser> Unapplying quilt patches to prevent spurious conflicts
<smoser> bzr: ERROR: Unable to unapply quilt patches for 'other' tree: rmdir: failed to remove `.pc/69_issue93_fix_trace_in_write_pxe_file.patch': No such file or directory
<jelmer> smoser: ah, ok - you're hitting an issue with the quilt integration; looks like the revision you're updating to has an invalid quilt state
<jelmer> smoser: 'bzr up --no-plugins' should work around that
<jelmer> I'm also working on improving the quilt integration to be more robust against this sort of issue
<smoser> jelmer, right. i seems i didn't comit the .pc dir :-(
<Timara> jelmer: it seams that the Trac plugin "Commit Ticket Updater" does exactly this
<Timara> i have enabled it
<Timara> as I understand, it would be enough to issue a "trac-admin changeset added <repo> <rev>"
<jelmer> Timara: as far as I know that only looks at the commit message, it doesn't have the ability to look at any other metadata in commits
<Timara> i see
<jelmer> Timara: (such as the data set with --fixes)
<jelmer> I'd be interested in hacking things up so it does, but last I checked there were limitations in trac that prevented this
<smoser> jelmer, you're right.
<smoser> i was missing  a .pc/<patch_name>
<smoser> i've committed that locally, moved the tag, pushed...
<smoser> all is well now
<smoser> sorry for spam.
<jelmer> smoser: still, that's a nonobvious way of failing so we should really get that fixed
<smoser> thank you, and looking forward to .pc directories being considered metadata
<smoser> jelmer, well, initially when i did the bzr pull, i got an error like bzr up gave me.
<jelmer> smoser: (please don't hesitate to bring this kind of thing up!)
<smoser> but then... i said "oh, thats just buggy"
<smoser> anad 'bzr pull --overwrite'
<smoser> and that got me into the wierd state that i wwas in, with less useful error messgaes
<Timara> thanks for the help jelmer, it seems I have to give it up at least for today...
<jelmer> Timara: IIRC this is a limitation in trac rather than in bzr (there is no access to the revision properties there)
<jelmer> Timara: you can still close bugs in the commit message, outside of --fixes.
<Timara> jelmer: how do you do that?
<Timara> by -m "This mod fixes bug #123"
<ubot5`> Launchpad bug 123 in Launchpad itself "There's no direct way to see the project info when translating it" [Medium,Fix released] https://launchpad.net/bugs/123
<Timara> ?
<Timara> and the commit message parser at Trac finds this subtrinsg and marks the bug as solved?
<jml> what version of bzr does pkg-import use in production?
<jml> james_w, vila: ^?
<vila> jml: bzr revno 6468
<Timara> have to go now, thank you for the help...have a good day
<jml> vila: thanks.
<mgz> vila: time to talk https?
<vila> mgz:
<vila> yup
<vila> mgz: first of all, I think you should land your proposal as it fixed a bug already affecting users
<mgz> there's also a polite post from Andreas on the bzr list about issues he's having post cert-ocalypse with webdav that we should respond to
<vila> mgz: then, my suspicion is that https + https will still be broken. Can you test this ?
<mgz> vila: that's broken by being broken though, in general
<vila> as in: only weird people will use that ?
<mgz> in that the whole point of checking certs is that you then can't me MIM-ed
<mgz> so if someone is running a proxy that sends requests then resigns them, bzr is now designed to fail
<vila> err, not sure we're on the same page
<vila> no, it shouldn't
<mgz> there are two kinds of https proxy
<mgz> one just does CONNECT over http and forwards the data
<mgz> the other intercepts the traffic and resigns the data
<vila> well, you can connect to the proxy with https and *then* CONNECT to the real site via the proxy
<vila> it's useless but not forbidden
<mgz> I'm not certain you can...
<mgz> can you link me a description of how that works?
<vila> I fail you see while you won't
<jml> vila: what's distro-info/python? (as referred to in lp:udd's etc-init.d-mass-import)
<vila> mgz: err, meh, indeed, the client won't be able do decode ssl twice...
<vila> mgz: dunno why I kept this idea in the back of my head
<vila> jml: james_w will know better, it's a python package to centralize some data about various distributions
<vila> jml: it was installed on jubany because it wasn't packaged for lucid at the time
<mgz> jml: just install python-distro-info, no?
<jml> mgz: not available in lucid
<jml> mgz: am trying to deploy udd on a fresh lucid ec2 instance
<mgz> jml: ah, yeah, it's recent. maybe get it from the debian git branch?
<jml> mgz: it'd be nice to know what production is using
<mgz> http://anonscm.debian.org/gitweb/?p=collab-maint/distro-info.git
<jelmer> 'bzr branch apt:distro-info' :-)
<jelmer> (if you have bzr-git and bzr-builddeb installed)
<james_w> jml, apparently it is using a bzr branch with no repository
<james_w> bzr+ssh://bazaar.launchpad.net/%2Bbranch/debian/distro-info/
<james_w> 6 package-import@ubuntu.com-20111025231956-gzif3z6okqmzaag8
<james_w> so I'm not exactly sure how it got there
<vila> james_w: as fast as possible to avoid more import failures ;)
 * jml branches revno 8 and hopes for the best
<vila> eerk, no repo indeed :-/
<mgz> vila: thanks for replying to the webdav post
<mgz> jelmer: did we work out why lp:dulwich doesn't have any of the latest tags?
<jelmer> mgz: bzr-git doesn't always push tags yet
<jelmer> mgz: fixed now I think
<jelmer> (changed the development focus to the main bzr branch rather than an import from git)
<mgz> jelmer: yep, that did it, thanks.
<maxb> jelmer: What is the relationship between those branches exactly?
<maxb> (Especially as I pushed new ppa branches stacked on the
<maxb> ~vcs-imports one yesterday)
<jelmer> maxb: they have the same contents
<jelmer> or rather, are supposed to have the same contents.. there is obviously still an issue regarding tags
<Modnar> Hi. I'm trying to get a branch under windows 7 x64 & keep getting this error: bzr: ERROR: short readline in the readvfile hunk: 'Bazaar pack format 1 (introduced in 0.18)\r'
<wgz> Modnar: read through this thread <https://lists.ubuntu.com/archives/bazaar/2012q1/074297.html>
<wgz> short version, try branching over bzr+ssh rather than http
<Modnar> ok so how do I ssh then?
<Modnar> well so far this bzr is useless then since ssh doesn't work either off hand... I just have to smack the dev & tell him to use something that works like git or svn
<Modnar> yeesh
<poolie> hi jelmer
<jelmer> hi poolie :)
<mgrandi> hi peoplez.
<Pikkachu> how to make Bazaar ignore all but one single file?
<bob2> you can just ignore all and explicitly add that one file
<Pikkachu> ok thanks
#bzr 2012-03-13
<vila> hi all !
* vila changed the topic of #bzr to: Bazaar version control <http://bazaar.canonical.com> | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: vila
<jelmer> yo vila
<vila> jelmer: hey !
<poolie> hi all
<jelmer> hi poolie
<mgz> morning all
<vila> mgz: hey
<poolie> hi mgz, jelmer
<poolie> :)
<vila> mgz, jelmer: 'bzr st' says 'bzrlib/locale' is unknown, any idea where it's coming from ?
<mgz> the build
<mgz> it should probably be added to ignores
<mgz> mo files get put in there
<mgz> (otherwise it's a pain to test locale stuff in place)
<vila> ooooh, and a full test suite run triggers a build...
<vila> bad isolation :-/
<vila> ok, thks
<vila> yeah, probably worth adding it to .bzrignore
<mgz> hm, yeah, selftest really shouldn't build mo files in place
<jelmer> mo files mo problems
<vila> LOL
<vila> jelmer: in other words: config options are good to test command-line parameters before making them official, I'm far from convinced that --overwrite-tags should be an official cmdline parameter (which is totally different from being convinced that *right* now (including 2.5) we *need* a way to overwrite tags)
<mgz> vila: do you have any idea why doing -Olaunchpd_username= isn't enough to revert from bzr+ssh to http?
<mgz> also, is there a way of unsetting a value, rather than using an empty string?
<fullermd> launchpd?
<mgz> ...irc tyop only
<fullermd> Oh, right, I missed that you were talking to vila.  Yeah, gotta keep it in his dialect  ;p
<vila> mgz: the missing 'a' is a typo right ?
<vila> mgz: ha ! authentication.conf ! lp-login creates a section there :-/
<vila> crap, read the log before replying vila...
<mgz> aha, and authentication.conf is still a special case.
<jelmer> vila: I disagree, if we add a configuration option for something before making it official then that means that we have to update all format implementations twice, plus all of the skew that comes with API changes
<vila> jelmer: meh, your're assuming it will become official...
<jelmer> vila: you did :)
<jelmer> 10:51 < vila> jelmer: in other words: config options are good to test command-line parameters before making them official,
<vila> test doesn't imply success
<jelmer> what do you want to test in that case?
<vila> that pull and push are the right place to add the parameter for example which is not obvious 'bzr tags' or something along the way to versioned tags may well be better suited
<vila> ghaa, miss punctuation
<vila> that pull and push are the right place to add the parameter for example ; which is not obvious. 'bzr tags', or something along the way to versioned tags, may well be better suited
<vila> if push and pull is not appropriate your arguments about API skew will then apply to the removal
 * fullermd finds the whole discussion a little bizarre...
<vila> fullermd: see https://code.launchpad.net/~jelmer/bzr/overwrite-tags/+merge/91277 and https://code.launchpad.net/~jelmer/bzr/overwrite-tags/+merge/94551
<jelmer> vila: I really don't see why this would need be tested in that way
<jelmer> vila: if you think pull and push are inappropriate for this option, then I think it's fair to bring that up during review
<jelmer> vila: I don't see why this is something we would want to test and then perhaps later revert, or why 'bzr tags' might be more appropriate
<vila> without a better definition of versioned tags, I can't
<fullermd> Oh, I've seen the discussion.  It just seems wacky.
<jelmer> fullermd: what's wacky about it?
<vila> since there is a way to bring in the feature *without* adding a parameter that may be removed later, I prefer the less intrusive path which address the issue now and leave us room to decide later
<fullermd> The whole idea of using the "config option" tool for the "vary how the command works this one time I invoke it" job leaves me wanting a drink.
<jelmer> vila: I don't see why the configuration option leaves us more room to remove it later.
<vila> removing the cmdline param
<jelmer> vila: what about removing the cmdline param?
<jelmer> removing the cmdline parameter and configuration option both break backwards compatibility.
<vila> not adding the cmdline param means we won't have to remove it
<jelmer> vila: but then we'll have to remove the configuration option
<jelmer> Using a configuration option is just a slightly implicit way of passing the information along from the command-line to the underlying code
<vila> which is less intrusive, opt-in and less work overall than a cmdline param in term of support down the road
<jelmer> vila: how is it any less intrusive *or* opt-in?
<jelmer> in both cases the backends will need to be updated to support the new functionality
<vila> but not the front-ends
<jelmer> the frontend change is trivial, and without it it is really hard to discover this functionality
<vila> you may consider it trivial but its fallouts are not
<jelmer> which fallouts?
<vila> If we have --overwrite-tags, I can argue that during pull in a dirty wt, I also want an option that will overwrite my local changes if they conflict with the versions I'm pulling
<vila> there is no end to that
<vila> --overwrite-tags is a work-around for lack of versioned tags, can we agree on that ?
<jelmer> vila: partially, overwrite tags makes perfect sense with versioned tags too
<jelmer> vila: I don't see how a working tree is relevant here, tags are associated with branches
<vila> if you go that route, --take-other on bzr pull also makes perfect sense, where do you draw the line ?
<vila> the working tree analogy is relevant in the context of versioned tags where bzr provides a way to resolve tag conflicts
<vila> --overwrite-tags is a simplification, I may well cherry pick which tags I want to override
<jelmer> vila: so is --overwrite, which currently *already* overwrites tags
<fullermd> That whole really sounds like a perfect-enemy-of-the-good sort of argument.
<fullermd> Pull is already a bit of a mess of confused branch-vs-wt actions.  This sorta continues in that vein and doesn't really make it better.  But I'm not sure that it really makes it _worse_.
<vila> jelmer: no, --overwrite will works the same with versioned tags, it resets the branch tip
<jelmer> vila: it would also reset the tags, I hope
<vila> jelmer: me too
<jelmer> vila: so I don't see why it's so odd to also allow people to *just* overwrite the tags, not the branch tip
<vila> because it's only one out of several choices which only make it more obvious that the UI is broken until we have versioned tags
 * quicksilver wonders if jelmer recommends any *particular* drink for working with bzr config options.
<vila> so rather than adding one option now and another (or several later), I'd rather say: look, we know we have an issue there, this option will address the most obvious shortcoming *until* we have a more complete solution
<jelmer> vila: by that reasoning, we should have never added the current unversioned tags in the first place
<vila> no
<vila> :)
<vila> tags are they exist today address valid uses cases
<jelmer> vila: This still brings us down to the same basic question: how is a configuration option less permanent than a command-line option?
<vila> because we can say so :)
<jelmer> vila: We can do so with a command-line option too.
<jelmer> quicksilver: :)
<vila> it doesn't carry the same weight
<jelmer> vila: Why not?
<vila> and doesn't have to be tighted to a particular command
<vila> if you call it tags.overwrite for example it can be used by both pull and push today and by tags tomorrow and will better reflect the feature itself rather than the command behavior
<jelmer> vila: I don't see how you would want to use this with 'bzr tags' tomorrow, even with versioned tags. Why does that matter if people are going to specify this on the command-line to push and pull?
<vila> jelmer: bzr tags or whatever command we add to deal with versioned tags
<jelmer> vila: why does that even matter? It will still require code changes to the backends *and* it will require users to change their use of bzr, both with a command-line option and with a configuration option.
<jelmer> I'm sorry, this whole point just seems surreal to me.
<vila> we're running into circles if you keep ignoring my objection about adding a parameter to commands which shouldn't have to handle tags in the first place :-/
<vila> the distinction seems pretty clear to me: an option makes it clearer that we working around an issue, it feels dirty to add official parameters for each and every workaround
<vila> whatever is needed for the front-ends, the backends should be updated to address the issue, split that part and the issue is addressed
<mgz> vila: tags are clearly a special case, and pull isn't drowning in switches
<vila> mgz: good, let's not start then
<mgz> in many ways I think a config option is worse
<mgz> this is likely to be something most people will only want to do on occasion
<mgz> whereas encouraging them to turn it on all the time without thinking is likely to lead to mistakes
<vila> hold on, where did I encourage anyone to turn it on all the time ?
<fullermd> In the term 'config option'.
<mgz> by suggesting a config option rather than a switch, that's the direction we're poking people in
<vila> .. which doesn't say anything about the default value :)
<fullermd> It may functionally be a distinction without a difference, but it's still conceptually a distinction.
<mgz> it's an encounter problem once, set config option, forget you did it, kind of scenario
<mgz> whereas with a switch you need to pass it every time you want the different effect
<vila> -O is not persistent and should be the recommended use
<vila> mgz: this perfectly applies to -O
<mgz> we have this even with https cert optionss where we suggest -O in errors but people are unsuprisingly setting the option globally
<vila> the distinction I make between the cmdline param and the option is that the cmdline param says: we will support it for this cmd, whereas the option is more blurry about being tighted to the cmd or not
<vila> mgz: that's yet another bug (already filed) that we don't provide a way to set it on a per-host basis, different use case
<jelmer> vila: a configuration option should apply to all things where it is relevant
<vila> jelmer: exactly, that doesn't mean the set of things can't evolve
<jelmer> vila: the point is, 'bzr pull' and 'bzr push' already deal with tags. my branch isn't changing anything about that, it just gives users a bit more control over how tags are handled.
<mgz> I think --overwrite-tags is the right thing for now, and it's not that hard to deprecate switches if we completely change how tags work in the future, especially one that basically becomes a noop
<vila> and that's my objection: we don't know yet whether it will always apply to push/pull and we already know it doesn't really fit well there, it's the only reasonable place today
<jelmer> vila: sure, but how is a configuration option better in that regard?
<vila> read above
<mgz> my objection is the reverse, the mp is too worried about how things may change, rather than just fixing the tags problem :)
<jelmer> vila: if we remove tag dealing from bzr pull then whether users use 'bzr pull -Otags.overwrite=true' or 'bzr pull --overwrite-tags', we'll have to break backwards compatibility.
<vila> jelmer: and it will be less work for an option than for a cmdline param, that's the point
<vila> well, one point
<vila> the other being that we won't have added an option fully knowing it wasn't the right place for it
<jelmer> vila: we probably don't want to silently ignore that option but print some sort of warning; I'm not sure if a configuration option is easier in that regard
<vila> grr a cmdline param not an option
<jelmer> vila: either way, it shouldn't really be a big difference either way
<jelmer> s/either way//
<mgz> vila: but you also would want a -Ooverwrite=true config option? That's asking people to make mistakes.
<mgz> this isn't a configy thing.
<vila> mgz: no, --overwrite makes perfect sense for a branch
<vila> there were discussions when tags were introduced with concerns about leaks, this is one more leak
<vila> people are already sometimes confused because you can pull (or even push locally) into a dirty tree, this will add to the confusion
<jelmer> vila: pull and push *already* deal with tags, this doesn't make it any worse, it just gives users more control.
<vila> using an option recognizes that we know this is a workaround
<mgz> I'm with fullermd, I don't really thing it makes the current status worse
<vila> well, obviously we're not making progress and we can't reach a consensus, to me, this means there is something wrong. I don't see what I can add to clarify further :-/
<fullermd> That generally means we're all pointing at somewhat different things as being The Problem.
<fullermd> There _are_ various differences in the implications of removing command line options vs. config options.  I don't think they're particularly relevant though (partly because I just don't see how removal gets on the forseeable horizon anyway).
<fullermd> But I'm outside the circle that really gets a say in it, and I've got a meeting in ~9 hours I really should get some sleep before, so...
<vila> fullermd: enjoy your sleep !
<jelmer> fullermd: Thanks for trying to help resolve it
<jelmer> We indeed don't seem to be making much headway
<vila> fullermd: you have a say in it
<jml> if I want to fetch a get a local tree for a particular revision of a remote branch, what's the fastest way to do that? checkout? export?
<jelmer> jml: it should be export
<mgrandi> hi, wondering if anyone could answer a question about bzr-git for me :
<jelmer> mgrandi: sure
<mgrandi> so, you probably remember i was pushing a bzr branch to github
<mgrandi> when i branched it originally, it had some git commits, then i made some in bzr
<mgrandi> and those commits had bzr revision ids
<mgrandi> and then when i pushed to github, those were replaced with the git-v1:<sha> revision ids
<mgrandi> i was just wondering if the bzr ones were saved somewhere or they revision ids just changed when you start pushing to a git repo?
<jelmer> mgrandi: the original revisions are still in the repository, just no longer in the branch
<mgrandi> so the branch essentially just has two sets of revisions, the bzr ones and the git ones?
<mgrandi> err repo*
<jelmer> mgrandi: the new revisions are created by fetching the changes that were pushed into git back into bzr
<jelmer> mgrandi: the bzr ones are no longer used after 'bzr dpush'
<jelmer> mgrandi: you can keepusing the bzr revisions in your local branch by using 'bzr dpush --no-rebase'
<jelmer> but if you do that, your local branch and the remote git branch will have diverged
<mgrandi> ah ok
<mgrandi> so this way you are theoretically the same as the git branch, albiet being in bzr
<jelmer> mgrandi: yes - and using 'bzr dpush' will discard all information that can not be represented in git
<mgrandi> it will discard it in the local branch as well?
<jelmer> mgrandi: unless you specify --no-rebase
<mgrandi> ok. is it necessarily a bad thing if you use --no-rebase ? will it still show up as one branch on the git side or will it show as merges from another branch sorta
<jelmer> mgrandi: if you use --no-rebase then your local branch will diverge from the remote git branch
<jelmer> because the revisions have different contents and different revision ids
<mgrandi> yeah, but all i'm doing is really just mirroring my changes on github
<mgrandi> and pushing to github occasionally
<mgrandi> so in that case it wouldn't really matter if my local branch diverged since i'm working in bzr mostly
<jelmer> in that case 'bzr dpush --no-rebase' should probably work sufficiently well
<mgrandi> ok. cool =)
<jelmer> mgrandi: but you'd have trouble pulling in changes from people who base their work on your git branch
<mgrandi> keyword "probably" =P
<mgrandi> ah.
<jelmer> mgrandi: at some point bzr-git will support 'bzr push' itself and just store bzr metadata in git revisions for things that can't be natively represented in git
<mgrandi> in that case i'll just leave it be. what sort of things cannot be represented in git, just curiously?
<mgrandi> ah thats cool!
<mgrandi> would it be stored as a file or something or does git have a metadata thing
<jelmer> mgrandi: revision ids, file ids, revision properties, ghost revisions
<jelmer> it would be stored as a magic file and in git notes
<mgrandi> magic file as in just a file that only bzr uses?
<jelmer> yeah
<mgrandi> thats cool =) thanks, i was just curious
<mgrandi> and something to keep in mind if i ever care about the revision ids
<jelmer> mgrandi: well, you care about the revision ids if you e.g. want to use 'bzr dpush --no-rebase' and merge in contributions from people using git :)
<mgrandi> yeah
<mgrandi> cause then it gets all confused im assuming
<jelmer> mgrandi: well, not really confused; they are in fact different revisions :)
<mgrandi> yeah, which would make merging harder then it should be
<mgrandi> so i'll just leave it without the --no-rebase thing for now in case i ever need to merge something back in it
<mgrandi> also, i'm intereted in perhaps participating in the GSoC thing, even if i don't actually 'offically' participate in it, but it would be cool to work on something
<mgrandi> i dunno if anyone decided on what stuff to do for it, although i saw people on the list were talking about netbeans support, which i assume is a java ide, and i know java fairly well
<jelmer> mgrandi: there is a page with GSoC ideas
<jelmer> let me find the link
<mgrandi> (although i feel an eclipse plugin might be better, since many things use eclipse, android, flashbuiler, eclipse itself, etc)
<jelmer> mgrandi: http://wiki.bazaar.canonical.com/SummerOfCode2012
<jelmer> mgrandi: I think we would be happy to mentor you, whether as part of SoC or outside of it
<mgrandi> yeah.
<mgrandi> quick question, what in bzr uses CPython?
<mgrandi> re the 'porting bzr to python 3'
<jelmer> mgrandi: apparently bzr works reasonably well in pypy, LarstiQ should know the details
<mgrandi> well i mean
<mgrandi> bzr is written in python, so i dont see why it was saying good knowledge of cpython is needed unless there are C excentions or something
<mgrandi> unless its referring to porting bzr to pypy or something, not just making it work with python3
<jelmer> mgrandi: well, there are a bunch of implementation details in Python3 you have to know about to do the porting
<jelmer> especially regarding character encoding handling
<mgrandi> true
<mgrandi> thats always fun
<LarstiQ> note that while pypy has 3.x support in the works it currently implements python 2.7 api
<LarstiQ> so working in pypy doesn't help with working in python 3
<LarstiQ> imo the two paragraphs under "Alternative Python implementations" are unrelated
<mgrandi> yeah
<mgrandi> thats what confused me xD
<LarstiQ> mgrandi: there are, afaik, two eclipse plugins
<mgrandi> last i heard they didn't work too well
 * LarstiQ nods
<LarstiQ> not that I'm an eclipse user, but that is indeed my impression
<mgrandi> might be good to start with. although eclipse is a beast within itself haha
<thomi> Hi. I have a bzrlib Branch object, a relative path within that branch, and some line numbers, and I'd like to work out who wrote those lines (essentially like annotate, but only for certain lines in a file).
<thomi> it looks like I need a VersionedFile object from a branch, but I can't see any easy way to get one. Any hints?
<spiv> thomi: you should be able to resolve the path to a versionedfile via branch.repository
<spiv> Although I forget the exact method
<thomi> spiv: ok, thanks. I'll poke around :)
<spiv> But basically it's the branch's repository that actually holds all the records about the history
<spiv> (You may need the current revision ID, branch.last_revision(), to pass to whatever repo API you need)
<spiv> I'd start by looking at how annotate works :)
<thomi> cheers
<thomi> spiv: I'm so close to having this working - the problem I have now is that bzrlib.annotate.annotate_file_tree calls _print_annotations, but I just want to get the annotation information...
<thomi> I could reimplement annotate_file_tree in my code I guess..
<spiv> thomi: yeah, the core of it is just a call to branch.repository.texts.annotate((file_id, file_rev_id))
<spiv> thomi: (as you might have already found, file_rev_id might not be branch.last_revision(), you need to consult the branch.repository.inventory to map your file path to the file_id,rev_id pair to use)
<thomi> yeah.
<spiv> Er, not quite literally branch.repository.inventory, but you know what I mean I think :)
<thomi> I hadn't seen the repo.texts thing, i was trying to do it some other way
<spiv> (I'm getting rusty at bzrlib clearly!)
<thomi> yep
#bzr 2012-03-14
<thomi> spiv: hmmm, I can't see how to get a rev_id for a give file_id in the branch.repository inventory
<thomi> ahhh, this works (bug is kind of ugly): dict(inv.entries())[relpath].revision
<thomi> spiv: got it! Are you able to tell me if I;m doing anything really wrong in this: http://pastebin.ubuntu.com/882561/ please?
<lifeless> thomi: inv[inv.path2id(relpath)].revision
<lifeless> I think there is a more direct one still
<thomi> ahh, I didn't realise the inventory was usable like a dictionary :)
<Pikkachu> hi, how can I keep an up-to-date reference in my code to submit or push branch?
<Pikkachu> in the specific case, it's the branch url used as project home
<Pikkachu> does bazaar allow to create a commit hook at least?
<Pikkachu> or is it better to just write an enclosing shell script which performs the changes before committing (for example using sed)?
<spiv> Pikkachu: you can create commit hooks, yes
<spiv> Pikkachu: I don't entirely follow what you're asking for, though
<spiv> Pikkachu: you want the text you commit to contain the location of the submit or push branch?
<Pikkachu> no, I want every commit to trigger the references in code to be updated before the commit is performed
<Pikkachu> I think I can enclose the commit with a previous look into .bzr and subsequent update of required files...
<Pikkachu> with a shell script, I mean
<Kamping_Kaiser> is it possible to diff one bzr branch against another branch at an arbitrary revision?
<Kamping_Kaiser> i want to find out if foo/ (at rev 13) was merged into bar (at rev 191) at any point
<spiv> Kamping_Kaiser: bzr help revisionspec, see revno:
<spiv> Kamping_Kaiser: e.g. -r revno:13:foo/..revno:191:bar/ I think
<Kamping_Kaiser> spiv: i'll have a try, thanks.
<Pikkachu> thanks spiv anyway
<spiv> Oh!  It sounds a bit like Pikkachu wanted keyword expansion.
<mwhudson> noone really wants keyword expansion do they?
<bob2> lots of people think they do though
 * fullermd does.
 * bob2 expands fullermd's keywords into merge conflicts
<fullermd> I didn't say I want a crap implementation of keywords   :p
<bob2> haha
<poolie> hey all
<vila> hmm, internet access issues here :-/ Rare but painful event, seems to to come from ADSL itself which is worrying
<ggherdov> vila: totally OT, but you hit a point that bothers me when I have unstable connections: i am conversating over IRC, then I am cut off from the internet, the person I'm talking with continues writing, but I miss part of the chat. Is there any kind of "IRC buffering thing" I can install on a remote server I have (which has reliable internet), in order to proxy my IRC connection thru a "stabilyzer"?
<mgz> morning all!
<vila> ggherdov: probably what IRC proxies are about, I don't use one myself :-/ (On the other hand, since I'm connected via ADSL I think the availability have been like 99.999999% or something...)
<vila> mgz: hey !
 * ggherdov IRC proxies... interesting.
<Peng> ggherdov: They're frequently known as bouncers.
<ggherdov> Peng: good to know. thx.
<Peng> ggherdov: Personally, I prefer to run a command-line IRC client, and I usually run it on something with a stable connection that I have SSH access to. (That's what I'm doing now.)
<ggherdov> Peng: I see your point. But is the SSH part of the connection is faulty, you risk to miss stuff. You still need you remote-cmd-line-irc-client to buffer stuff for you, and send all the stuff you missed when it sees you again.
<ggherdov> s/is/if
<Peng> ggherdov: I use GNU screen, so the SSH connection doesn't have to be reliable.
<Peng> Sorry, I should've said so, but I think of screen/tmux as a given when using SSH.
 * ggherdov Peng got game
<ggherdov> Peng now I see. wow a powerful combination
<ggherdov> btw, using tmux since 2 months and it's a great util.
<Peng> I've never tried tmux. screen's good enough for me.
<ggherdov> Peng: I use tmux in order to split my terminal in several shell in a tiledfashion. didn't know of the fault tolerance thing untill now.
<ggherdov> shells*
<Peng> Ah. I don't tile stuff.
 * ggherdov nobody's perfect :-)
<Peng> :(
<nigelb> Peng: tiling irssi leads to really really claustrophobic typing space :)
<Peng> But but I need to IRC in six channels at once.
<nigelb> haha
<ggherdov> there was an option to 'bzr rm'  in order to bzr-remove a file that you had already bash-removed. what was that ?
<jelmer> ggherdov: there is no special option necessary
<jelmer> ggherdov: 'bzr rm' (without other arguments) should also pick that up
<ggherdov> ah good.
<ggherdov> thx jelmer
<ggherdov> I was mixing up with 'bzr mv --after'
<jelmer> vila: hah, the main user of .revision_history() is bzrlib.tests.per_branch.test_bound_sftp, but all tests there seem to be skipped for some reason
<vila> jelmer: hmm, did I tyoped set_revisions_history ?
<vila> in the line above ? yes :)
<mgz> "Not a local URL"
<mgz> fun.
<vila> mgz: huh ?
<vila> jelmer: so, having read your review (thanks !), I'm talking about *set_revision_history* not revision_history, probably related but still different beasts
<mgz> we don't really have a way of detecting test success->skip regressions
<mgz> without carefully watching babune test counts across runs
<vila> jelmer, mgz: By the way, I didn't touch code deprecated in 2.5.0, I can't remember what our rule is ? n+1, n+2 ?
<vila> meh, rule to delete code deprecated in series n that is
<mgz> vila: what you did seems fine, 2.4 gone in 2.6 seems right
<vila> anyway, there is still a bunch to remove before touching code deprecated in 2.5
<vila> k, thought it was a bit conservative but since there is still a bunch to do before touching that...
<vila> I think I saw code that was deprecated without any version attached which is... bad :)
<vila> but again, let's get rid of what we can safely remove first
<mgz> jelmer: those tests seem too be skipping all the way back to 2.2
<mgz> it might make more sense to work out what they're trying to do, write new tests, and delete the module
<mgz> there's already bug 728252 for those tests skipping, so just proposed deleting them to reduce the chance of us rediscovering that again in future
<ubot5> Launchpad bug 728252 in Bazaar "All tests in bzrlib.tests.per_branch.test_bound_sftp are skipped always" [Low,Confirmed] https://launchpad.net/bugs/728252
<mgz> "Ran 1 test in 102.260s" heh...
<ams_cs> bzr: ERROR: bzrlib.errors.BzrCheckError: Internal check failed: Cannot add revision(s) to repository: missing chk node(s) for id_to_entry maps
<ams_cs> anybody know what I can do about that?
<jelmer> hi ams_cs
<jelmer> ams_cs: can you provide some more background?
<ams_cs> I'm trying to merge lp:gcc/4.7 into (a clone of) lp:gcc-linaro/4.7
<ams_cs> I've tried it on two machines and get the same result, so it doesn't appear to be some local corruption
<jelmer> ah, hmm
<jelmer> I didn't realize those two branches had related history
<jelmer> that usually indicates branches having a slightly different view on shared history
<jelmer> can you file a bug? I'll try to look into it.
<ams_cs> hmm, lp:gcc-linaro/4.7 was originally branched from lp:gcc/trunk
<ams_cs> upstream branched 4.7 from trunk (in SVN) a week or two ago
<ams_cs> doko imported the new branch as lp:gcc/4.7, but they should share history right up to the svn branch point
<ams_cs> and lp:gcc-linaro/4.7 has not diverge far from lp:gcc/trunk
<ams_cs> jelmer: any luck?
<jelmer> ams_cs: still fetching the branches
<ams_cs> jelmer: yeah, that'll take a while. BTW, there's no need to have a local copy of lp:gcc/4.7 to reproduce the problem ... although maybe to debug it
<jelmer> ok
<mgz> vila: did you file a bug for the bzrlib/locale thing?
<vila> mgz: nope, sry
<vila> mgz: this test_bound_sftp stuff is... worrying :-/
<mgz> I think it's less worrying than it looks.
<vila> how d'you know we're not reducing coverage here ?
<mgz> because the tests have never (at least since 2.0) actually been run.
<mgz> we certainly lack functional style testing on various real world things with both the smart server and other remote branches
<vila> revno 5030 (2.1 => 4857, 2.2 => 5120) says otherwise (but I can't run the tests there due to some testtools/subunit issue)
<vila> well, not 5030 but rather 5017.3.33
<vila> but what worries me is that we didn't notice it earlier
<mgz> we did!
<mgz> spiv filed a bug :)
<vila> # ?
<mgz> linked from the mp.
<mgz> bug 728252
<ubot5> Launchpad bug 728252 in Bazaar "All tests in bzrlib.tests.per_branch.test_bound_sftp are skipped always" [Low,Confirmed] https://launchpad.net/bugs/728252
<vila> gha, I parsed that as added by lp :-)
<mgz> anyway, deleting these certainly doesn't reduce coverage, and I don't think there's much worth salvaging from their logic
<vila> ... color me confused but how to you know these doesn't reduce coverage ?
<vila> s/to you/do you/
<mgz> we have pretty good unit testing for bound stuff, and we know we have holes for functional testing
<vila> ha, ok
<mgz> vila: eg. bt.per_branch.test_branch.TestBound
<jelmer> it does seem kindof odd to have these kinds of tests in bt.per_branch
<mgz> we're not testing against remote branches, but that's been true for... ages
<vila> yeah, yeah, I mis-interpreted :)
<vila> indeed, looks like very old bb tests
<vila> approved by the way
<jelmer> uhoh
<jelmer> I guess that means https://code.launchpad.net/~jelmer/bzr/remove-branch-history/+merge/97411 will conflict
 * vila reviewing, was about to mention
<mgz> jelmer: you made them run again?
<vila> nope, he made them keep skipping ;)
<vila> instead of erroring :)
<mgz> well, I better win the race then :)
<jelmer> well, I kept them around but at least avoided the calls to the functions I was removing
<vila> which is a bit unfortunate :-/
<vila> err, I mean, it's unfortunate you spend time on them not knowing they were skipped anyway
<jelmer> vila: in what way? It should be trivial to resolve the conflict..
<jelmer> ah
<jelmer> well, not the worst thing in the world :)
<Pikkachu> what a straightforward way to make automated pre-commit (1) validations and/or (2) source code modifications? I'm just thinking of using shell script or the like
<LarstiQ> Pikkachu: you could look at how the bzr-text-checker plugin works
<ams_cs> jelmer: any news?
<jelmer> ams_cs: I'm still looking, but I'm pretty sure it'll take a couple of days squash this bug. I'm not really familiar with this bit of the code.
<jelmer> ams_cs: I'll file a bug about it and subcribe you - who are you on Launchpad?
<ams_cs> ams-codesourcery
<ams_cs> jelmer: thanks, I was hoping there'd be a work-around :(
<alansaul> If I push over the top of a respository, can get get the previous one back?
<jelmer> alansaul: yes, by using "bzr pull -rREV ."
<jelmer> alansaul: yes, by using "bzr pull -rREV . --overwrite"
<mgz> one jelmer always tells the truth, and the other jelmer always lies
<mgz> how can you tell which command to run?
<alansaul> Lol
<alansaul> Uh oh
<mgz> okay, so maybe I'm an idiot, and someone would have pointed the problem out by now if it was actually the case but...
<mgz> don't the .mo files never actually get installed?
<mgz> so... all that translation stuff we did for 2.5 isn't actually enabled?
<vila> mgz: as in: on debian/ubuntu you mean ?
<mgz> well, I'm looking at the code in setup.py
<vila> I thought we had bug reports about that and that you even fixed some of them... may be we are 2 idiots :)
<mgz> it may be that the way debian builds it the files are included, but they don't seem to be in the windows installer
<LarstiQ> how does gettext on windows work btw?
<mgz> badly.
<mgz> ehem...
<vila> it misses a leg or two may be...
<mgz> python has it's own implementation, so you just point it at a directory of specially arranged .mo files
<vila> . o O (post-install tests)
<mgz> hm, there are .mo files in python-bzrlib
<mgz> so, however we're building for debian works somehow at least
<vila> WARNING: gnome-keyring:: couldn't send data: daemon closed connection
<vila> while running the full test suite
<vila> does that ring a bell ?
<mgz> but the code seems to need the build artefact to exist at setup.py invocation to include it
<mgz> which... implies you must run setup.py twice for it to function
<jelmer> mgz: translations seem to work here..
<mgz> jelmer: how do you build for debian exactly?
<mgz> the intersection of makefile and setup.py is a little confusing
<mgz> I'm trying to fix the inplace creation of .mo files but don't want to accidentally break you.
<jelmer> mgz: don't worry about that
<mgz> oh but I do :)
<Pikkachu> sorry, pidgin crashed, who was talking to me?
<Pikkachu> the text checker plugin seems overkill
<LarstiQ> Pikkachu: sure, but the interest for you is the pre-commit machinery?
<wgz> what was that thing from lifeless about not using "should" in bug titles?
<wgz> I'm struggling to phrase things without it
<jelmer> wgz: I think the point was mainly that bug reports should primarily describe problems
<jelmer> as opposed to a ticket tracker I think
<LarstiQ> wgz: I find that hard too
 * LarstiQ looks it up
<wgz> I think it was on google+ so good luck ever finding it again...
<Pikkachu> LarstiQ: I don't want a machinery that's why it's overkill, I want some simple concept
<Pikkachu> LarstiQ: I don't need to set up and configure any machinery for using an enclosing shell script with the custom rules for each branch, for example
<Pikkachu> wgz: maybe because it's implied
<wgz> Pikkachu: that's contradictory
<Pikkachu> how so?
<wgz> you want to do something pre-commit, but not have to worry about any machinery for doing things in response to actions?
<LarstiQ> wgz: actually, it is the second hit on "bug should" in my circles
<Pikkachu> wgz: I mean for example "Bazaar should grep revisions from diffs" => "Grep revisions from diffs in Bazaar"
<LarstiQ> wgz: https://plus.google.com/u/0/105660309458564946897/posts/BLhnbgoouXV
<Pikkachu> wgz: ah you mean my case, ok
<wgz> LarstiQ: logging in and being in Robert's circle is cheating :)
<Pikkachu> wgz: it's not contradictory, it's you who's not understanding
<LarstiQ> wgz: isn't that how you find stuff on g+? ;P
<LarstiQ> Pikkachu: could you explain some more what you're trying to do?
<wgz> Pikkachu: I mean, sure you can write a shell script that does something and then calls bzr commit, and use that rather than commit itself
<Pikkachu> wgz: doing complex things may require a machinery setup or not, making the former case unnecessarily complex, that's what I mean. In this specific case, I don't want to depend on some plugin installed and configured for anyone willing to commit to the branch. This can be completely avoided
<Pikkachu> wgz: the shell script has the advantage of not requiring any installation, it's self-contained in the branch and ready for use for anyone who branches the repo
<wgz> provided they remember to run it instead of using commit
<Pikkachu> wgz: READE.BEFORE.COMMITING :)
<Pikkachu> wgz: or seriously, for a single file branch, commit.sh will call user's attention unless he's dumb
<wgz> doesn't seem that different from having an instruction in there to cp commit_hook.py to ~/.bazaar/plugins
<wgz> but whichever you like.
<wgz> it would be nice to have a better mechanism for branch-specific thingies, but there are reasons it hasn't happened
<Pikkachu> wgz: that's why I was looking for a even better solution, but pre-steps like installing and configuring stuff *so that* I can achieve what I want is a non-go. This step can be completely replaced with a shell script already there and ready for using
<wgz> mostly because the idea of branching something then meaning it automatically runs arbitrary code when you do some operation is scary
<Pikkachu> wgz: I think a more straightforward solution was if I was able to register a commit hook natively within the branch without any external setup required
<wgz> there are a few threads on the bazaar list on this topic
<lamalex> jml, with testtools, what's the proper matcher to ensure something is not None?
<jml> lamalex: assertThat(x, Not(Is(None)))
<Pikkachu> wgz: I'd be really surprised that bzr does not support commit hooks though
<wgz> it does, you just need to manually install them, for the above reason.
<jml> lamalex: I guess if you wanted to you could define 'IsNotNone = Not(Is(None))' and then do assertThat(x, IsNotNone)
<lamalex> ha right
<lamalex> thanks
<lamalex> i wasn't reading carefully and skipped over Not :P
<lamalex> whoope
<Pikkachu> wgz: manually install? how so?
<wgz> as mentioned, `cp commit_hook.py ~/.bazaar/plugins/commit_hook.py` or similar.
<wgz> probably want `mkdir -p ~/.bazaar/plugins` first.
<wgz> if you desperately want to write your checking logic in shell you'd have to use subprocess from the commit hook callback
<wgz> jelmer: you're the man today. or maybe the page?
<Pikkachu> wgz: I have no idea what to put within that file
<Pikkachu> wgz: besides a hook should be a hook not what the hook holds
<Pikkachu> wgz: a hook is supposed to just trigger something, not be that very something
<jelmer> wgz: eheh
<jelmer> wgz: This coming from somebody with surname that's just begging for VCS-related puns?
<jelmer> *a
<Pikkachu> wgz: I mean something like $bzr add-hook --pre-commit --system "commit-validation.sh"
<LarstiQ> Pikkachu: in my hazy memory something like that exists
<jelmer> Pikkachu: that is what this is, except it is in Python, not shell.
<wgz> Pikkachu: LarstiQ was trying to help you earlier linking an example
<Pikkachu> wgz: or $bzr add-hook --post-commit afterCommitting => afterCommitting.py, run it directly from within python instead of catching output/return value from a system executable
<jelmer> Pikkachu: hooks are installed per-user, perchance using per-branch configuration data. They don't live in the branch itself, for security reasons.
<Pikkachu> jelmer: if it's like wgz is saying, then it's not really a hook, it's a plugin which catches commit events
<LarstiQ> Pikkachu: branch.Branch.hooks.install_named_hook('pre_commit', pre_commit_hook, 'text-check')
<wgz> apart from a slightly different wrapper, I don't see the difference
<Pikkachu> LarstiQ: 'text-check'?
<LarstiQ> Pikkachu: that is from bzr-text-checker, it is the analog of your `bzr add-hook --pre-commit text-check.py`
<Pikkachu> jelmer: what reasons
<jelmer> Pikkachu: if I download a branch from somewhere, tweak it and then run "bzr commit" I don't want to run arbitrary code that came from that branch.
<Pikkachu> LarstiQ: no it's not, mine is a command line, yours is python code
<LarstiQ> Pikkachu: hence, analog
<Pikkachu> LarstiQ: no
<Pikkachu> LarstiQ: it may be analog but not in the sense I mean
<LarstiQ> Pikkachu: and as I also said, I remember there being something to run arbitrary commands for hooks
<Pikkachu> jelmer: that's easy to fix
<Pikkachu> LarstiQ: ah thanks...that would be interesting....
<jelmer> LarstiQ: there is bzr-shell-hooks, which allows you to define shell commands to run in .bzr/branch/branch.conf
<jelmer> I haven't updated it in a long time though, so it may have bitrotted
<LarstiQ> Pikkachu: apparently, it is called bzr-shell-hooks ;)
<Pikkachu> jelmer: so you're the author? cool... by shell you mean any system command or the underlying shell like bash etc?
<Pikkachu> is it my imagination or can plugins be installed within a branch?
<LarstiQ> Pikkachu: you can have configuration for them in a branch
<jelmer> Pikkachu: plugins can't be installed within a branch, they're installed in the users home directory
<jelmer> Pikkachu: bzr-shell-hooks installs trivial hooks that can run commands configured in the branch
<LarstiQ> jelmer: or well, you _could_ point BZR_PLUGIN_PATH at a branch
<jelmer> LarstiQ: that's true
<lamalex> hi im trying to write a push hook, and i want to get the author of the last commit
<lamalex> really i want all the authors for each commit since the point where its parent was branched
<lamalex> but just the one is fine for now :P
<jelmer> lamalex: your hook should receive the relevant revision ids, which you can use to retrieve the revision metadata
<lamalex> anyone have a tip? i see i can get the revision easily, but i dont see what i can actually do with that
<jelmer> lamalex: The revision object has a .committer attribute which is just a string with the author name and email, and it has a .get_apparent_authors() method which returns a list of strings with authors
<lamalex> ah nice
<lamalex> so would i take that from my target branch
<Pikkachu> LarstiQ: the BZR_PLUGIN_PATH seems a good idea if bzr-shell-hooks is lightweight, this way users would not be required to install it
<jelmer> lamalex: yeah, usually. since you're sure the revision is present there
<Pikkachu> lamalex: how are you writing a bzr hook?
<LarstiQ> Pikkachu: on the other hand, you might not want to forcefully override their plugin path
<lamalex> Pikkachu, http://doc.bazaar.canonical.com/beta/en/user-guide/hooks.html
<Pikkachu> jelmer: well, wasn't you who said about security risks? and yet has such a plugin like bzr-shell-hooks? :P
<lamalex> jelmer, so do i just take that id and make a new revision?
<LarstiQ> Pikkachu: are you confusing me with jelmer?
<lamalex> Revision(id).get_apparent_authors
<jelmer> Pikkachu: that's exactly why bzr-shell-hooks is a plugin, and not part of the core
<jelmer> Pikkachu: also, I don't actually use bzr-shell-hooks myself.. it was just a quick hack a couple of years ago
<Pikkachu> lamalex: that looks like non-branch specific
<Pikkachu> no LarstiQ: "jelmer: Pikkachu: hooks are installed per-user, perchance using per-branch configuration data. They don't live in the branch itself, for security reasons."
<lamalex> Pikkachu, i have no idea what you're talking about. i'm guessing you pinged me due to a misunderstanding
<Pikkachu> lamalex: we're talking about commit hooks, coincidently
<jelmer> lamalex: e.g. something like target_branch.repository.get_revision(id) will return the revision object
<lamalex> ah, im talking about push hooks
<lamalex> but totally unrealted
<Pikkachu> lamalex: I want a commit hook on a specific branch, not wherever I typ bzr commit
<LarstiQ> Pikkachu: that's easily controllable with configuration
 * LarstiQ eats dinner
<Pikkachu> actually I will explain the exact problem:
<Pikkachu> I have a pidgin plugin written in C which needs to provide an URL, I didn't care to register a project in LP so the URL is basically [...]/+junk/branch-name. But it happens that this URL is already contained in .bzr as push/submit branch. I want to keep source code always up-to-date with what's in .bzr. Any ideas?
<Pikkachu> well, actually I think it doesn't matter that much it being in source code, more in the resulting builds...
<Pikkachu> therefore I could implement this as a build step not a commit hook... but I don't want to use make because I would duplicate code from pidgin build environment which is mostly required anyway in windows
<Pikkachu> so any ideas? thanks
<jelmer> re
<jelmer> Pikkachu: I'm not sure I follow what you mean; are you talking about changing the default locations for 'bzr pull' and 'bzr push' ?
<Pikkachu> no... nevermind I think I'll resolve the problem myself
<LarstiQ> Pikkachu: at build time you want to say "this code came from <here>"?
<Pikkachu> at build time it would be like:
<Pikkachu> plugin.c => #define URL "@@PLUGIN_URL@@", then
<Pikkachu> something like using sed for replacing @@@PLUGIN_URL@ from what's within .bzr before compiling it
<LarstiQ> right
<LarstiQ> sort of like the `bzr version-info` use case, but with different data
<Pikkachu> seems like not
<LarstiQ> Pikkachu: where would the url come from? Is `bzr config parent_location` sufficient?
<Pikkachu> $ bzr help version-info => Show version information about this tree.
<Pikkachu> shows, does not change anything
<LarstiQ> Pikkachu: read on
<Pikkachu> ah sorry...
<Pikkachu> nice to know about $ bzr config, I'm not sure if it's submit or push branch, but yes it's either of it
<Pikkachu> unfortunately the submit/push urls are not available there :(
<LarstiQ> Pikkachu: if they're not set probably not
<LarstiQ> Pikkachu: but it depends on your workflow what will be in there
<Pikkachu> the ones listed are {date} {build_date} {revno} {revision_id} {branch_nick} {clean}
<LarstiQ> Pikkachu: e.g., in my bzr.dev copy submit_branch is not set, but in my 2.5-fixes branch it is
<LarstiQ> Pikkachu: ah, in version-info?
<LarstiQ> right, that is what I meant with "different data"
<LarstiQ> Pikkachu: I wonder if it makes sense for version-info to include this data
<Pikkachu> it includes the branch nick already
<LarstiQ> Pikkachu: yeah, but that is more portable
<LarstiQ> Pikkachu: it's actually contained in the commit data
<Pikkachu> I don't get this command though, the example says it will *generate* a C header file?
<LarstiQ> Pikkachu: in the example the template will give valid C syntax
<LarstiQ> Pikkachu: and then you'd direct the output to, say, build_info.h
<Pikkachu> but I don't think it meant to " produce a C header **file**", just a valid header string
<Pikkachu> anyway, I think I can simply seek into .bzr anyway
<LarstiQ> Pikkachu: that is more fragile, but if you want, yes
<LarstiQ> Pikkachu: sure, the example is a valid header *fragment*. The common use of it would be as a single header file though. And of course your template can be more complicated
<Pikkachu> I think the help message needs a small fix
<Pikkachu> fragile in which sense, just missing to be there?
<LarstiQ> Pikkachu: that, and in theory subject to change
<LarstiQ> Pikkachu: what fix to the help message do you propose?
<Pikkachu> LarstiQ: change what, the config format/location?
<LarstiQ> Pikkachu: yeah
<LarstiQ> Pikkachu: you're poking around in internals
<LarstiQ> Pikkachu: that's always at ones own risk
<Pikkachu> LarstiQ: fix: not mentioning it will generate a file, it just generates text output which is supposed to be placed separately into a file (from what I've got of what the command does)
<Pikkachu> LarstiQ: I just forgot, I can use cd branch; url=$(bzr config push_location)
<LarstiQ> Pikkachu: or even `url=$(bzr config -d branch push_location)`
<Pikkachu> oh I tried without -d, cool!
<Pikkachu> now the problem is: I reuse the whole pidgin build infrastructure, because most of it is required anyway
<Pikkachu> a pidgin windows build environment contains everything a regular plugin requires, plus the ability to build them if you place them in the correct place
<Pikkachu> I could duplicate the makefiles and make them point to pidgin root, but I think it's overkill
<Pikkachu> hmm I just had an idea
<Pikkachu> something like build.sh:
<Pikkachu> url=$(bzr config push_location | sed 's/\//\\\//g')
<Pikkachu> cat plugin.c | sed s/@url@/$url/ > "$devroot/pidgin-$version/pidgin/plugins/plugin.c"
<Pikkachu> cd "$devroot/pidgin-$version/pidgin/plugins" && make...
<LarstiQ> Pikkachu: right.
<LarstiQ> Pikkachu: stylistically I would go for including a header instead of rewriting plugin.c, but that's a small niggle
<Pikkachu> LarstiQ: it's overkill to split the plugin into a separate files, and it doesn't rewrite the plugin itself, but the copy from which it will be built
<Pikkachu> the above would be the same as copying the plugin to there then sed -i
<Pikkachu> hmm actually I could use your suggestion to avoid build.sh not being used (if one copy the file to there and $ make it, then the url will remain as "@url@" in the binary)
 * LarstiQ nods
<Pikkachu> if I use #include "plugin.url.h" then 'URL' instead of @url@, compilation will fail if build.sh is not used and no header is manually created...sounds interesting, thanks for the tip LarstiQ
<Pikkachu> thanks all for the constructive discussion!
<poolie> hi all
<poolie> hi lifeless
 * jelmer waves to poolie
#bzr 2012-03-15
<poolie> o/ jelmer
<mgz> morning all!
<vila> mgz: hey !
<vila> mgz: can you have a look at https://code.launchpad.net/~vila/bzr/948339-config-caching/+merge/97256 and give me a quick go/no-go for inclusion in 2.6b1 ?
<vila> wow, I don't know what have changed but ./tools/check-newsbugs.py is faster than ever by a significant margin...
<fullermd> I'll take the credit.
<vila> bad, 3s for 8 bugs in trunk vs 58s for ~141 bugs in 2.5: apples vs oranges
<vila> s/bad/bah/
<fullermd> Hm.  That's 133 bugs less, a month after the branch.  Since it's about 5 months 'till the next branch, that means that 2.6 should have -657 bugs!
<vila> \o/
<vila> mgz: if you haven't started, forget about it, my RM persona said: too late ;)
<mgz> I'vee been looking at it
<vila> ha, thks
<mgz> it's really three different things though, and I don't yet understand one of them, and am not convinced by one
<vila> 3 ?
<mgz> checking the lock count is straightforward, but lacks a test?
<mgz> the list->dict swap for sections I don't see what the bug was previously
<vila> aaron did add a relevant tests IIRC
<mgz> and just changing aaron's tests to assert the things that it was calling out as suspect doesn't really seem useful
<vila> they document the expected compatibility (or not) behavior
<mgz> the comments are nice, but if you're leaving those issues in place, it's not really the best place for it
<vila> well, the core issue is how far we try to stay compatible and my take is that it contradicts the aim of reducing the IOs
<mgz> ^the problem is aaron's test mentioned in that bug, you changed to just assert that the thing that he reckoned was wrong... happened
<mgz> so, overall the mp is probably reasonable, but I'm confused.
<vila> the list->dict swap is covered by a failing test encountered while fixing the bug: spurious warnings were emitted because two different callers got two different MutableSection
<vila> mgz: ok, then that's a no-go, no worries
<mgz> right, that tests for the same section object is makes that clear
<vila> I shouldn't have tried to get it approved anyway, when the RM says: I'm freezing, it's too late, rushing at this point is just making RM's life harder, I should know ;)
<mgz> there's a bug you flipped from 2.6b1 -> None that was just a merge up, was that an accident or is it really not merged?
<vila> it is merged (bzr lp:bzr/2.5 says: nothing to do), I did both cheks at different times may be I should have left the milestone
<mgz> bug 939605
<ubot5> Launchpad bug 939605 in Bazaar 2.5 "qconflicts says that my merge tool is not available. what should I do?" [Medium,Fix released] https://launchpad.net/bugs/939605
<mgz> will be in 2.6b1 right?
<vila> yup
<vila> I think we should set the milestone only when marking the bug fix released and never before
<vila> jelmer, mgz: by the way, to be clear, I'm freezing 2.6b1, no landings please ;)
<vila> Had I started with that I wouldn't have dared asking for a review ;)
<mgz> it's sometimes useful for targetting things that need to be done for a release
<jelmer> vila: hah, ok
<mgz> did <https://code.launchpad.net/~jelmer/bzr/bzr.1-launchpad-commands/+merge/97443> bounce?
<mgz> I don't see it in the PQM queue
<jelmer> it's still in my local mail queue
<mgz> otherwise, vila that's already sent
<mgz> ah, so you can just hold it till vila unfreezes.
<mgz> good post on plugin testing jelmer
<vila> jelmer: +1
<vila> will reply later
<jelmer> thanks
<vila> jelmer: by the way, any news about bzr-notify dangling progress dialog ?
<jelmer> vila: haven't worked on that yet
<vila> sumbitting 2.6b1 to pqm
<jelmer> vila: let me know when I can flush my mail queue :)
<vila> jelmer: I will, waiting for pqm and that's already conflict with my immediate schedule which includes a meeting off the internet in 10 minutes at an 8-minute cycle ride ;)
<mgz> ...98% done, but I'm not sure you can do everything remaining in 2 minutes :)
<vila> 2.6b2 open submitted, will finish 2.6b1 later
 * vila runs
<vila> uuurgh, http code 502: Bad Gateway when submitting :-/
<vila> jelmer, mgz: 2.6b2 opening landed, trunk is free for landing
<jelmer> \o/
<jelmer> hmm
<jelmer> ValueError: 0 not in range -2147483648 to 2147483647
<mgz> ehehe
<vila> use a bigger 0
<vila> mgz: re-reading the log:
<vila> <mgz> it's sometimes useful for targetting things that need to be done for a release
<vila> well, strictly speaking what *needs* to be done for a release ought to be marked critical
<vila> <mgz> otherwise, vila that's already sent
<vila> ECANTPARSE
<vila> At the time I thought you meant you sent your review but there is nothing there so I was probably wrong ;)
<lamalex> is it possible to hook into bzr config from a hook/plugin?
<vila> well, yeah, there are hooks there, what's your need ?
<vila> bzr help hooks
<vila> lamalex: ^
<lamalex> jsut for some general configuration. i was wondering if there was already bzr api for using the bzr configuration, rather than rolling my own
<vila> bzrlib.config is the code, doc/developers/configuration.txt and dov/developers/new-config-rationale.txt may be worth a read too
<lamalex> thanks
<vila> lamalex: if you have a use case that is not covered I'd love to hear about it ;)
<lamalex> i will let you know after some light reading :)
<vila> k
<jml> hey
<jml> I'm making a script to deplo udd to an ec2 instance
<jml> it needs openid credentials for the launchpad stuff
<jml> any thoughts on which user I should use in that script?
<mgz> ~james_w clearly :)
<jml> heh heh
<jml> there are three approaches I can think of
<mgz> can you just make a new one? there are various robotty things, but there's some benefit to keeping them single purpose
<jml> one is to use a fixed use
<jml> user, rather
<jml> the other is to re-use the credentials of the person firing up the instance
<jml> and the third is to make a new user every time
<mgz> I think I favour option 1.
<jml> mgz: I can do that. I wonder what LP would think about it.
<jml> I guess I should ask them.
<vila> jml: what's the purpose of the ec2 instance ? Replacing the jubany one ?
<jml> vila: integration testing.
<vila> no write access to lp then right ?
<jml> vila: uhh, I think I would want it to be as close to production as possible
<jml> vila: but I mostly care about emulating the instance on hadar
<jml> vila: and maybe that only has r/o acccess
<mgz> jml: we have ~bzr-build-bot for instance just for running things on ec2
<vila> jml: uhh ? writing to staging then ? You don't want to interfer with the real one right ?
<jml> vila: I don't understand.
<mgz> if you can get away with not talking to production launchpad creating a new user each time would be more practical
<vila> jml: you don't want to create the same branches than the importer on jubany right ?
<jml> vila: I'm not creating branches at all. I'm not using lp:udd for anything to do with branches :)
<vila> then I don't understand what you're using it for :)
<jml> vila: lp:udd contains a highly robust, field-tested package monitoring system. We're using that.
<vila> ok, no need for write-access then (AFAIR)
<jml> yeah, I don't think so.
<jml> but lifeless insists that the read access be authenticated.
<vila> then I'd go for 2 or 3 (a dedicated user or the one starting the instance), if anything goes wrong you'll get some trail (sp?)
<jml> 'trail' is correct.
<vila> yeah, so he can kill your bot if needed ;)
<james_w> jml, does anonymous with a distinctive token name suffice for him?
<jml> james_w: no, it does not, IIRC. Let me find the thread...
<jml> hmm. I think I might have said user-agent rather than token name...
<james_w> I think they are equivalent in lplib
<james_w> I think it uses the token name in the user agent
<jml> james_w: https://bugs.launchpad.net/udd/+bug/906846
<ubot5> Ubuntu bug 906846 in Ubuntu Distributed Development "Uses authenticated access to Launchpad when anonymous will do" [Undecided,New]
<james_w> thanks
<jml> I'm going to be lazy and go with 1 for now. :\
<kevin|> Kbulgrien is idle?
<kevin|> Given a shared bazaar repository at: /repo and a branch at /repo/prj/bra that contains a folder structure like top/mid/bot, is it possible to make a new branch /repo/prj/mid that has a root at mid of top/mid/bot? IE. A checkout of /repo/prj/mid results in a copy of mid/bot and nothing else from top.
<mgz> kevin|: depends exactly what your goal is
<mgz> doing `bzr branch prj/bra prj/tmp && bzr split prj/tmp/top/mid && mv prj/tmp/top/mid prj && rm -rf prj/tmp`
<mgz> is literally what you're asking for, but perhaps not what you really want.
<mgz> partial checkouts haven't been implemented, so you can't work on a subset of the branch then merge it back
<kevin|> Ok... bummer on no partial checkout but will read up on split.
<kevin|> Thanks for the tip.
<kevin|> Isn't bzr view partial checkout?
<mgz> no, but it might work for what you want
<mgz> it doesn't create a tree with only some elements, rather it restricts operations on an existing tree to a subset
<xnox_> I'm doing the 'fake' cherrypicking a revision from trunk onto maintanance branch, why does it not offer to copy the commit message / author / fixes urls / commiters  upon bzr commit?
<xnox_> or what is the proper way to do cherrypick and copy the commit message?
<wgz> xnox_: nope, a nicer interface for doing cherrypicks would be good
<poolie> hi all
<mgrandi> hihi
#bzr 2012-03-16
<mgz> morning
<vila> mgz: hello !
<vila> mgz: ok, 26b1 being frozen, any chance you could finish this config-caching review ? Pretty please :)
<wgz> :)
<vila> jelmer: I need you brain and its mid-term memory :)
<fullermd> Oh no, midterms?!  I haven't studied all millennium   :(
<vila> When running 'make docs-sphinx' in a *fresh* bzr branch it fails with: http://paste.ubuntu.com/886129/
<vila> or rather as mentioned in the paste, the command there (triggered by make) fails
<vila> but a second run succeeds (not investigated yet, probably make see some file left over by the failure and is happy)
<vila> jelmer: to the point: no default in format_registry ? Surely that should ring a bell
<vila> fullermd: one more joke making the whoosh sound above my head ;)
<vila> mid-term memory is not correct english ? How do you call the memory between short-term and long-term (and don't reply: can't remember, please ;)
<fullermd> Eh?  Who're you?   :p
<vila> hehe
<fullermd> I dunno.  Is there even biophysiologically such a thing?  I guess it's as good a term as any.
<vila> yeah, wikipedia agree with you, only short and long, weird
<vila> gimme my elastic memory back, best vaccine against Alzheimer ;)
<vila> on that topic, I read the last Pratchett and he seems to be doing fine so far (good).
<fullermd> Alzheimers is when you _lose_ your memory.  As long as you never really get it in the first place, you can't get Alzheimers   ;p
<vila> I should remember that...
<fullermd> Better write it down.
<fullermd> After all, the mind is the first thing to...   to...   uh...
<vila> jelmer: adding 'import workingtree' fixes the issue... what's the rationale again ?
<vila> wossname ?
<mgz> 'medium term' would probably be most idiomatic.
<vila> mgz: my saviour :)
<fullermd> Eh, it's English.  You can say any old meaningless thing, and pretty soon it'll become idiomatic.
<fullermd> From the language that brought you "the proof is in the pudding", and "I could care less".
<mgz> 'I couldn't care less' is also valid and means the same.
<mgz> so, you can be both correct and sensicle if you choose.
<fullermd> It's not _also_ valid.  It's the only valid one.  It's just not the one everyone around me says.
<fullermd> My hand gets so sore from smacking them...
<vila> good, so I could add 'because I could care less' to any sentence and leave other fail into the logic trap, very good
 * fullermd rears back his arm.
<quicksilver> earlier this week jelmer was suggesting drink, now fullermd is suggesting pudding
<quicksilver> #bzr becomes more and more hospitable by the day.
<quicksilver> can we have custard?
<vila> isn't it lovely ? ;)
<jml> I've forgotten... how does one get the repo for a Brancch?
<mgz> .repository ?
<jml> fullermd: re "I could care less", http://www.youtube.com/watch?v=om7O0MFkmpw
<jml> mgz: ah yes, thanks.
<jml> mgz: it's not documented on http://people.canonical.com/~mwh/bzrlibapi/bzrlib.branch.Branch.html and other things that I would guess to be attributes are methods...
<mgz> jml: on you udd branch, why fabric not juju?
<jml> mgz: because I'm deploying things to the Canonical data centre, and am thus compelled to use lucid.
<jml> mgz: and similarity to production is a cardinal virtue for a thing like this
<mgz> seems like sticking it on canonistack as well as ec2 might be useful
<jml> mgz: yes.
<mgz> ...which apart from a few hard coded things seems nearly possible
<jml> mgz: a juju charm would be great too
<jml> mgz: I've just done the bits that interested me
<mgz> that's cool, was just curious for reasoning.
<jml> mgz: it's entirely because of lucid.
<jml> roll on precise!
<jml> how do people check for branch equality these days?
<jml> in tests
<fullermd> So, the reasoning used to be lucid, but now it's precise instead?
<mgz> jml: is, or when its not the same object comparing the bits you care about, so transport, url, revision stuff
<mgz> I'm not aware of a neater option.
<jml> mgz: thanks
<jml> fullermd: huh? no. when precise is in the Canonical DC, then I'm going to switch my projects to use juju for their cloud deployment
<mgz> it was an adjective joke :)
<jml> oh huh
<jml> sorry.
<jml> I do have a sense of humour, honest I do.
<mgz> fullermd is a strong cheese.
<fullermd> I'll put you down as a reference on my resume, shall I then?   :p
<alf_> Hi! Is there a shortcut/prefix for specifying a colocated branch, or do I have to use the full file://...,branch=... URL?
<alf_> For example, something like "bzr merge colo:other-branch" (but that doesn't work for me in bzr 2.5.0)
<jml> ok, what about getting a controldir from a brancch?
<jelmer> alf_: hi
<jelmer> alf_: there are plans to add "co:"
<alf_> jelmer: good to hear that, thanks
<jml> hmm, maybe a better question is how do I programmatically create a colocated branch in tests
<jelmer> jml: ctrldir.create_branch(name="foo")
<jml> jelmer: and how do I get a ctrldir from a branch?
<jelmer> jml: br.bzrdir
<jml> jelmer: also, is there a way to get the name of a colo branch given only the Branch object?
<jelmer> jml: br.name
<jelmer> IIRC
<jml> jelmer: thanks :)
<jml> does bzrlib have something that reformats file URLs as paths?
<jelmer> jml: it does
<jelmer> my guess is that it lives in bzrlib.urlutils but I don't remember the name
<jml> ah found it
<jml> local_path_from_url
<jelmer> that's the one
<lamalex> is it possible for a branch to define configuration for plugins inside of itself, so when people branch it that config is set by default?
<mgz> with cooperation from a plugin, yes
<mgz> what specifically do you want?
<lamalex> mgz, im writing a push_hook to integrate with our jenkins instance
<lamalex> so it'd be nice if our projects that are set up in jenkins could define this bzr config, and then developers with the hook installed dont have to do any configuration on their own for the plugin, it's already set up in the project
<lamalex> all they have to do is install the plugin
<mgz> lamalex: that sounds fine
<mgz> can do something like `bzr config --scope=branch plugin_name.option=value`
<mgz> then in the plugin look at the branch config for some behaviours
<mgz> ...bah, but that doesn't propogate
<lamalex> right, i want it to be stored in the remote branch, say on launchpad
<mgz> would have to be a versioned file in the tree with a well-known name then
<lamalex> so would that be a new store I'd have to define?
<mgz> vila may have better ideas
<vila> <shudder> config option propagation...
<vila> open problem right now, will *LOVE* to have it defined properly...
<vila> version controlled config stores, same
<vila> lamalex: could you re-phrase your needs in higer level language for a second, there are a lot of tricks that can be achieved without the two features mentioned above nor implementing your own store
<vila> lamalex: when and where does the plugin run ? On user's machine or on the jenkins slave ?
<vila> or both ?
<lamalex> vila, it runs on the users machine
<vila> lamalex: for example, your plugin can very well write to the remote branch config
<lamalex> vila, when I do bzr push lp:~alexlauni/unity/unity.flaming-launcher-icons my plugin does a bunch of magic to tell jenkins to make a job and start running our unity test suite on my unity branch
<vila> so you can use the remote branch.conf and don't need to implement any more stuff (just make sure you write-lock the right branch and set the config option named as mgz suggested)
<vila> since it's a push_hook, you should already have access to the right branch
<lamalex> yah, im asking about config because i dont want the other developers to have to set anything up
<vila> dunno if it's still locked but since it's pushed too obviously the user has write access
<vila> lamalex: well, the point of the config is that the user is in control *if needed*
<vila> s/the/one/
<vila> s/the/one point/ grr
<vila> bah, tyop crisis
<lamalex> right, the user should be able to disable it or enable it on their own but i'd like our project maintainer to be able to set default for the project
 * vila nods
<ninjix> Hello all. I would like to stop tracking changes to a .htaccess file but leave it it the working tree. Is there a way to do this?
<mgz> ninjix: `bzr rm --keep FILE`
<vila> lamalex: ha, tricky, so from the hook you'd want to read "trunk" and set something in the pushed-to branch ?
<ninjix> mgz: so this will leave the base version for the other devs and users?
<lamalex> vila, hm no not exactly
<vila> please enlight me :)
<lamalex> yah im trying to find the right wording
<vila> there is currently one option I can think of that smells like a project setting: child_submit_to
<mgz> ninjix: no, the normal way of doing something like that is having a template or example versioned, and leaving the real file unversioned
<vila> lamalex: bzr help child_submit_to
<vila> Where submissions to this branch are mailed to.
<lamalex> i dont think that's it
<ninjix> mgz: thank you. you've confirmed my hunch
<lamalex> the option is really jenkins on or off
<lamalex> that's pretty much it
<vila> oh
<lamalex> but i want it to be defined in the trunk branch that lives in launchpad
<lamalex> so when a developer branches, it's set inside their branch and when they push their branch gets submitted to jenkins
<lamalex> but for projects that dont have it set, nothing happsn
<vila> hmm, yeah, project-wide setting
<vila> and your jenkins will walk lp to find such branches ?
<vila> and if the setting is changed on lp's trunk how do you want that to propagate ?
<lamalex> no jenkins won't walk LP that's the point of the push hook- to not have to poll launchpad
<vila> oh, you mean, the user push *and* start a jenkins job then ?
<lamalex> vila, i'd guess like any other new revision? branches of trunk should update on pull
<lamalex> vila, yup
<lamalex> we're working on building a continuous integration workflow  in product strategy
<vila> why not just have the plugin query the trunk's config then >?
<lamalex> as in go over the net and read from trunk's config?
<vila> yup, you already went over the net to push..
<lamalex> right im not whining about network traffic im just making sure i understand
<vila> k
<lamalex> so really you'd be reading from parent_branch though right?
<vila> yes
<vila> ideally I would think this is for merge proposals so the *target* branch would sounds more appropriate
<lamalex> it's not for merge proposals
<vila> k
<lamalex> we want the tests to start running long before that
<lamalex> for the entire development life cycle of the branch
<vila> even if people push multiple times before submitting ?
<lamalex> yah for sure
<vila> k
<lamalex> so by the time you propose a merge you already know your code is clean
<vila> k
<lamalex> and the reviewer knows the code is clean
<lamalex> and has been tested in a clean env
<vila> the only brittle point I see is that parent_branch may be a local mirror of lp's trunk, but you may find a way to fix that
<lamalex> which is why i wanted the config to just come down when you branch trunk
<vila> doomed if you do doom if you don't ;)
<vila> lamalex: starting with parent_location should cover most of the use cases and allow you to validate the whole stuff though
<vila> lamalex: the trunk will always be on lp for your plugin right ?
<lamalex> yah
<vila> lamalex: I thought you already sorted out what the project name was so you may as well just query lp:<project> no ?
<lamalex> ah yah that's valid
<lamalex> so now the question is how do i read from a remote config
<vila> lamalex: you get the branch first then: br.get_config_stack().get(opt_name), done
<lamalex> do you think it's possible to import the bits from the launchpad plugin that translate lp:project into a real url for getting the trunk branch?
<lamalex> vila, ^
<vila> lamalex: sure enough, but bzrlib can probably do that for you
<vila> lamalex: bzrlib.branch.Branch.open('lp:bzr') should just worl
<vila> work
<lamalex> oh far out
<lamalex> that's awesome
<lamalex> ok, i think i've got what i need. that's a lot vila and mgz
<lamalex> vila, hm hah finally how do i set an option on trunk?
<vila> lamalex: bzr config -d lp:bzr i.am=a.happy.camper
<vila> :)
<lamalex> ha, -d saying directory in the help doc is a little misleading
<lamalex> but excellent
<lamalex> thanks!
<vila> lamalex: don't forget to register your option (lazily of possible)
<lamalex> in my hook?
<vila> lamalex: look into the po_merge plugin (one of the last written so hopefully respecting most of the unspoken rules ;)
<vila> lamalex: in your plugin
<lamalex> well, my "plugin" is a push hook
<vila> lamalex: registration gives you 'bzr help <option_name>' for free
<vila> it's a plugin, that's all that matters ;)
<lamalex> heh ok
<vila> mgz: thanks for the review ! Some additional questions in the comments if you don't mind ;0)
 * mgz refreshes
<lamalex> vila, Branch.open('lp:unity') doesn't work, Unsupported protocol for url "lp:unity"- do i need to import something?
<mgz> bzrlib.plugins.launchpad
<vila> hmm, yeah, the lp plugin should be imported first, I wonder how you manage to execute your Branch.open without importing it though... manual testing ?
<LarstiQ> or loading all plugins?
<vila> lamalex: don't worry about importing order though, the way we implemented plugin import relies heavily on python sorting that for us
<vila> ha, good point from LarstiQ (hey !), but from a push hook, I except plugins to be imported well before that
<LarstiQ> vila: ah hmm, good point
 * LarstiQ digs deper
<LarstiQ> deeper
<lamalex> vila, so i set my option on a branch like, bzr config -d lp:tictactoe jenkins.run_on_branches=true
<lamalex> but when i get('jenkins.run_on_branches') i literally get nothing back
<vila> lamalex: what does 'bzr config -d lp:tictactoe' display ?
<vila> lamalex: bzr version ?
<lamalex> 2.5
<vila> k
<LarstiQ> in an ipython shell at least: 'import bzrlib.plugin; bzrlib.plugin.load_plugins(); from bzrlib.branch import Branch; Branch.open("lp:bzr")' works
<lamalex> vila, http://paste.ubuntu.com/886442/
<vila> lamalex: no 'branch:' there, something is wrong :-/
<vila> oh
<vila> bzr config -d lp:bzr doesn not work >-/ bzr config -d bzr+ssh://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/ does
 * vila cries
<lamalex> heh
<vila> lamalex: bug filed, but you shouldn't be affected in your plugin, if you get a branch (and the right one) this should be ok
<vila> bug #957049
<ubot5> Launchpad bug 957049 in Bazaar "bzr config -d lp:bzr is broken" [High,Confirmed] https://launchpad.net/bugs/957049
<lamalex> ;) indeed- which is just a pain for setting the option but ill make a note of that
<vila> jelmer: I just noticed a typo in bzr-webdav info.py in the bzr_plugin_name (wedadv instead of webdav), I wonder what 'bzr_plugin_name' is useful for ?
<lamalex> is there a doc for the error codes? i'm getting Errno 104 when I do some postdata in my plugin and it returns a 303 code
<mgz> 'the' error codes? what's the context?
<lamalex> mgz, i'm sending a bunch of post data to a webservice that spawns a jenkins job. that service is returning a 302 when i do getrespone, and that is causing bzr to give me errno 104  Connection reset by peer
<lamalex> if i just dont call getresponse() everything works fine hah! i think bzr is trapping something and getting mixed up
<vila> jelmer: lintian found a typo ? Can you introduce this nice guy to me ? ;-D
<jelmer> vila: lintian is a tool that checks debian packages
<vila> jelmer: I know :)
<jelmer> vila: lint + debian :)
<vila> but how did it found a typo like that is what makes me wonder ;)
<jelmer> http://lintian.debian.org/full/jelmer@debian.org.html
<jelmer> vila: bzr_plugin_name is used by things like bzr-plugin-info, though that isn't in wide use today
<mgz> I'm guessing the tyop was mine?
<mgz> did you look at the blame jelmer? :)
<vila> mgz: I would take it as a personal offense if you're trying to steal *MY* typos
<vila> :-D
<jelmer> wait, which typo are we talking bout?
<mgz> mine!
<vila> jelmer: wow, amazing
<vila> extention
<vila> see ? MINE ? My preciooouuuuss
<vila> hmm, and fullermd is not even around.... must be spring coming...
<vila> ok, the builtin's one was from Marius and the xml_serializer's one from mgz :-(
<mgz> ha, you'll have to make your own typos
<mgz> jelmer is on a lazy mission.
<smoser> jelmer, around ?
<smoser> i just hit bug again https://bugs.launchpad.net/ubuntu/+source/bzr-builddeb/+bug/923688
<ubot5> Ubuntu bug 923688 in bzr-builddeb "bzr crashed with AttributeError in tree_unapply_patches(): 'DirStateRevisionTree' object has no attribute 'last_revision'" [High,Fix committed]
<smoser> and went looking
<smoser> build failed
<smoser> https://launchpad.net/ubuntu/+source/bzr-builddeb
<smoser> build log: https://launchpadlibrarian.net/95953060/buildlog_ubuntu-precise-i386.bzr-builddeb_2.8.3_FAILEDTOBUILD.txt.gz
<jelmer> smoser: it's on my list of things to fix, but it's an odd bug
<smoser> the build bug?
<jelmer> yeah
<smoser> suck.
<smoser> so i keep hitting this... is there a way i can easily not hit it?
<jelmer> that test failure only occurs as part of a chroot package build, and doesn't happen on sid
<jelmer> smoser: "bzr branch lp:bzr-builddeb ~/.bazaar/plugins/builddeb"
<smoser> gracias
<mgrandi> hey guys
<mgrandi> So, i have a svn 'dump' file by using rsvndump, do you guys know of any way to get this into bzr, or into fast-export or something?
<jelmer> mgrandi: rsvndump?
<jelmer> mgrandi: "bzr svn-import" supports svn dump files
<mgrandi> rsvndump lets you make a 'dump' of the repository when you don't have access to the repo
<mgrandi> k i'll try that
<jelmer> mgrandi: bzr-svn can also operate against remote svn operations directly
<mgrandi> so it can basically get a repo from a svn repo?
<mgrandi> (since i don't have access to the repo, its on some server)
<jelmer> mgrandi: yes, you can just specify "bzr branch svn://path/to/some/branch"
<mgrandi> handy!
<mgrandi> i'll do that if it can't import the dump file
<jelmer> mgrandi: bzr svn-import will actually reconstruct the repository locally, and then talk to that
<mgrandi> ok
<mgrandi> so, when i do bzr-svn import, does that create a repo?
<mgrandi> i told it to create it in a branch and now i think its confused
<jelmer> mgrandi: yes, though it does it on the fly though in a temporary directory
<jelmer> mgrandi: how do you mean?
<mgrandi> it imported it fine, into a folder that was a branch, that i created using bzr init
<mgrandi> it told me to do bzr checkout to create a working tree, but now it says a control directory already exists in the folder
<jelmer> mgrandi: "bzr branch" creates a new branch, so if you specify an existing location it will indeed not work
<mgrandi> so the folder i gave it is now a repo?
<mgrandi> even though it started out as a branch?
<mgrandi> bzr info just says its a standalone tree and i dunno what that is
<jelmer> mgrandi: bzr svn-import creates a repository with multiple branches in it
<mgrandi> ah
<jelmer> mgrandi: the location you specified would be the root of the repository; if you had a standard layout in svn
<mgrandi> it said something like 'using layout trunk0"
<mgrandi> so branch that?
<jelmer> mgrandi: if you go to LOCATION/trunk you can run 'bzr co' there to create the tree
<mgrandi> (this is why i hate svn haha)
<mgrandi> ok
<mgrandi> honestly i think i found a bug
<mgrandi> cause i re did it and now i have a 'trunk' folder
<mgrandi> but before, when i had the TO_LOCATION argument as a folder that was already a branch
<mgrandi> it didn't create any of the folders and was branching 0 revisions, etc
<mgrandi> and before, it said the folder was a 'standalone tree' but when i did it (correctly i guess) it says shared repository now
<jelmer> mgrandi: I guess it said it was a 'standalone tree' because you manually ran 'bzr init' beforehand
<mgrandi> yeah
<mgrandi> i think it just got confused or something, i dunno
<mgrandi> also, im not sure if the 'parent branch' should be set to the temporary folder =P
<jelmer> mgrandi: heh, that's a good point
<mgrandi>  parent branch: /var/folders/hg/sz267ft96k34rjpc5zb23p200000gn/T/bzr-svn-dump-hAFefy/trunk
<mgrandi> not the most useful thing
<jelmer> mgrandi: can you file a bug?
<mgrandi> yeah, on bzr-svn?
<jelmer> yep
<mgrandi> ok. and do you think that the thing i was describing about doing svn-import on a directory that is already a branch is a bug?
<mgrandi> cause it didn't create the trunk/ folder like it was supposed to and it said it had no revisions
<jelmer> mgrandi: I'm a bit unclear as to what you've done exactly
<jelmer> mgrandi: if you can reproduce it, a bug would be useful
<mgrandi> k jelmer, this is what i mean
<mgrandi> http://bpaste.net/show/25314/
<mgrandi> at the bottom, when i cd into trunk there is no "trunk" folder
<jelmer> mgrandi: that's expected behaviour, "bzr init trunk" creates a branch
<mgrandi> and i cant figure out how to check out
<jelmer> mgrandi: "bzr svn-import" creates a repository
<jelmer> mgrandi: and creates directories under the repository for each branch that was in the svn repo
<mgrandi> but here it doesn't though
<jelmer> mgrandi: according to your pastebin it does
<jelmer> mgrandi: in other words, the "bzr init trunk" isn't necessary
<mgrandi> yeah
<mgrandi> i created a trunk folder, made that a branch
<mgrandi> but then when svn-import imports the stuff in there, there is nothing under the trunk/ folder besides .bzr
<mgrandi> as you can see in lines 8-14
<jelmer> mgrandi: try 'bzr svn-import ../ellerrepodump.dat elerrepo'
<jelmer> that will create a repository in elerrepo
<mgrandi> yeah
<jelmer> and a branch in elerrepo/trunk
<mgrandi> i did that, and thats the correct way
<jelmer> you can then run "bzr co" in elerrepo/trunk to crete a working tree
<mgrandi> however i feel that it shouldn't try and import into a branch or else you get a weird state
<jelmer> mgrandi: it doesn't really import into the branch
<mgrandi> yeah
<mgrandi> but then how do you check out when you do this though
<mgrandi> i'm just wondering if this is intended behavior cause it seems like you just have a repo/branch that you can't do anything with
<jelmer> mgrandi: go to elerrepo/trunk (or in your case trunk/trunk) and then run 'bzr co'
<mgrandi> do i create that directory if it doesn't exist?
<jelmer> mgrandi: hmm, if you have an older version of bzr-svn it might create colocated branches
<jelmer> mgrandi: I would suggest just starting from scratch and not using 'bzr init trunk', but just using 'bzr svn-import elerrepo'
<jelmer> ehm
<jelmer> 'bzr svn-import ../foo.svndmp elerrepo'
<mgrandi> i know that is the correct behavior, by just using svn-import <whatever>
<mgrandi> but im just saying it lets you create this weird state
<mgrandi> that oyu can't do anything with
<mgrandi> seems like a bug, and it should not do that
<mgrandi> or error out
<jelmer> mgrandi: what version of bzr-svn are you using?
<jelmer> mgrandi: can you try running 'bzr branches' in trunk?
<jelmer> ah, actually
<jelmer> can you run 'bzr up' in trunk
<mgrandi> svn 1.1.2
<mgrandi> ok, bzr up did it.
<jelmer> mgrandi: this is fixed in 1.2.0 I think
<jelmer> in 1.1.2 it creates colocated branches even if you don't specify --colocated
<mgrandi> what does it do there?
<mgrandi> ahh
<jelmer> in 1.2.0 it would create trunk/trunk
<mgrandi> it doesn't seem to of created a colocated repository
<mgrandi> or i dont know if its using the plugin version where it has like .bzr/branches or whatever
<jelmer> mgrandi: what does "bzr branches --no-plugins" say?
<mgrandi> *(default)
<jelmer> yeah, that's the default colocated branch
<mgrandi> as in a 2.5 coloated branch?
<jelmer> mgrandi: yes
<mgrandi> ok
<mgrandi> so, how do i get bzr-svn the latest verison? just from launchpad? or is there an updated installer
<jelmer> mgrandi: yep
<jelmer> I'm not sure if there is an updated installer
<mgrandi> i'll try and see if it works
<mgrandi> jelmer: doing it with bzr-svn 1.2.1 gives this: bzr: ERROR: Repository CHKInventoryRepository('file:///Users/markgrandi/Desktop/try2/.bzr/repository/') is not shared.
<mgrandi> so i guess that works out
<jelmer> mgrandi: that's correct, indeed
<mgrandi> and bzr-svn still has the parent branch thing so i'll report a bug on that
<jelmer> thanks
<mgrandi> jelmer: https://bugs.launchpad.net/bzr-svn/+bug/957511
<ubot5> Ubuntu bug 957511 in Bazaar Subversion Plugin "svn-import produces branches with tmp directories as parent branches" [Undecided,New]
<jelmer> mgrandi: thanks
<jelmer> mgrandi: (note that this bug is specific to using bzr svn-import with svndump files)
<mgrandi> oh
<mgrandi> i'll edit it
<jelmer> IÃÃÂe already done so :)
<mgrandi> k
<jelmer> mgrandi: done :)
<mgrandi> that was fast!
<jelmer> it was a really simple fix
<mgrandi> yeah, just add remember_parent=False a couple places
#bzr 2012-03-17
<pmatulis> say i've done 'bzr branch lp:foo bah' , how do i change my branch to 'bar' ?
<fullermd> mv?
<pmatulis> just 'bzr mv bah baar'?
<pmatulis> grr
<fullermd> No, just 'mv bah baar'   ;p
<mgrandi> yeah, you don't need to do anything special
<mgrandi> just rename the folder
<fullermd> Or maybe 'mv bah bah bah, bah bah bah-ranne'
<mgrandi> >.>
<pmatulis> srsly? ok
<Pikkachu> hi all, how to get the *http* url for a branch?
<Pikkachu> like $bzr info http_launchpad_home or something
<jelmer> pikkachu: http://bazaar.launchpad.net/~owner/project/name
<Pikkachu> right, how do I get it?
<Pikkachu> owner can be anything, as well as project and name
<Pikkachu> that's why I'm asking
<Pikkachu> I realize I can do some replacements in bzr info push_location, but I ask for a less hacky way
<jelmer> Pikkachu: if you only know the project name, then http://bazaar.launchpad.net/+branch/project should work too
<Pikkachu> I don't know anything about the branch
<Pikkachu> not even if there's an associated project
<jelmer> Pikkachu: what *do* you know about the branch?
<Pikkachu> jelmer: man, I just want something similar to bzr config push_location
 * Pikkachu realized he needs a hack on bzr config output
<Pikkachu> thanks all anyway :(
#bzr 2012-03-18
<jh> Hi. I'm trying to use bzr-svn to checkout a svn-repo. I get a "bzr: ERROR: A Subversion remote access command failed: Server sent unexpected return value (403 Forbidden) in response to PROPFIND request for '/path/to/root/of/repo/'" I don't have rights to read '/path/to/root/of/repo/', only to '/path/to/root/of/repo/sub'... with tortoise svn I can checkout the repo from sub... It seems to be similar to https://bugs.launchpad.net/bzr-svn/+bug/4
<jh> 09668 but that should be fixed. Any ideas?
<ubot5> Ubuntu bug 4 in Launchpad itself "Importing finished po doesn't change progressbar" [Medium,Fix released]
<jh> https://bugs.launchpad.net/bzr-svn/+bug/409668
<ubot5> Ubuntu bug 409668 in Bazaar Subversion Plugin "accesses repository root" [Low,Fix released]
<jh> evil linebreak ;)
<jelmer> jh: bzr-svn still accesses the repository root, though you can work around it by explicitly specifying the repository layout
<jelmer> bug 675104
<ubot5> Launchpad bug 675104 in Bazaar Subversion Plugin "requires manually specifying layout if only part of the repository is accessible" [Low,Triaged] https://launchpad.net/bugs/675104
<jh> jelmer: ok, thx... Now I just have to figure out what to use as "layout"
<jelmer> jh: see 'bzr help svn-layout'
<jh> jelmer: ah! thx again :)
<jh> mh, now I get "bzr: ERROR: WildcardLayout(['projectname/trunk'],[]) does not support co-located branches."
<jh> oh, "Jelmer said on IRC: "Looks like it's just invalid handling of a particular exception at the moment"" https://bugs.launchpad.net/bzr-svn/+bug/798400 :(
<jelmer> jh: You probably want "--layout trunk1" ?
<ubot5> Ubuntu bug 798400 in Bazaar Subversion Plugin "svn-layout failure: "does not support co-located branches"" [Medium,Fix released]
<jelmer> jh: that bug was fixed in bzr-svn 1.1 though, what are you running?
<jh> I just downloaded bzr 2.5 standalone for windows
<jh> seems to 1.1.2 (from svn\info.py)
<jh> +be
<jh> jelmer: if I specify "layout = trunk1" and "branches = path/to/trunk" in the subversion.conf, I get bzr: ERROR: Not a branch: "svn+https://url/path/to/root/path/to/trunk/branches".
<jh> the "branches" in path is wrong
<jelmer> jh: I'm pretty sure that's due to a mismatched bzr-svn/bzr version
<jelmer> I remember there were some issues with the standalone that had a too old version of bzr-svn, but I thought that was fixed
<jelmer> wgz: there?
<jh> 1.1.2 is too old?
<jelmer> yeah, for 2.5.0 you want 1.2.1
<jh> ok
<jelmer> it seems to be fixed in lp:bzr-windows-installers, but perhaps the installer hasn't been rebuilt yet :(
<jh> hm, using the none-standalone version of bzr requires me to compile subvertpy?
<jelmer> yeah, it would :(
<jelmer> you might be able to install the newer bzr-svn into the standalone installer location
<jelmer> which already has subvertpy
<jh> jelmer: yay, that seems to work :)
<jh> at least it's downloading something
<jh> server is incredible slow, but it seems to work... thank you for your help & your plugin, jelmer!
<jelmer> jh: np; sorry about the hickup with the windows installers :-/
<jelmer> hopefully that will be resolved soon
<wgz> the fun thing is various issues need fixing in 2.5 installers
<wgz> so, a rebuild would have the newer bzr-svn, but still no translations currently
<wgz> jelmer, for bug 958511 do you really mean gpg key? push should just be ssh.
<ubot5> Launchpad bug 958511 in Bazaar "can't connection to bazaar" [Undecided,Incomplete] https://launchpad.net/bugs/958511
<jelmer> wgz: ah, oops, yes
<wgz> jelmer: I've questionised it now
<wgz> seems to have just been the normal intermittant connection thing.
<wgz> bug 958551 is interesting, commit builder probably just needs the check already, it's too easy for plugins to screw up.
<ubot5> Launchpad bug 958551 in bzr (Ubuntu) "Crash while committing" [Undecided,Incomplete] https://launchpad.net/bugs/958551
<jelmer> wgz: hmm, indeed
<wgz> the annyoing part it's is not possible to tell from the traceback who messed up setting the commit message, the builddeb hook seems most likely, but I wrote some tests for that
<jh> noooo... "bzr: ERROR: A Subversion remote access command failed: Server sent unexpected return value (403 Forbidden) in response to PROPFIND request for '/pathtorepo/tags'" :(
<jh> i don't want tags
<jh> there are no tags :(
<jelmer> jh: you need the wildcard layout in that case (in other words, remove "layout = trunk1", just use "branches = path/to/trunk")
<jh> jelmer: do i have to re-download?
<jh> i get 'bzr: ERROR: A control directory already exists: "file:///path/trunk/".'
<jelmer> jh: right, you'll have to remove the existing branch (or run "bzr pull" in the existing branch)
<jh> :(
<jh> bzr pull says 'bzr: ERROR: Not a branch: "path/.bzr/branch/": location is a repository.'
<jelmer> jh: ah - it hit that 401 error before the branch was created
<jelmer> removing the branch and starting from scratch is probably easiest
<jh> yes, during checkout
<jelmer> you can also try running 'bzr init' in file://path/trunk and then trying pull
<jh> during 1h checkout :[
<jh> yay, that worked
<jh> thx again
<poolie> hi all
#bzr 2013-03-11
<salsaman> hi
<salsaman> anybody have an estimate of how long bzr index takes to run ?
<salsaman> i have been trying to index a 5GB repository and so far it has taken over 20 hours (system time) and is using 9GB of memory
<salsaman> and 95% cpu
<jelmer> salsaman: on large repositories it can be really slow
<jelmer> make sure you're using the latest repository format ('bzr upgrade')
<salsaman> jelmer, another question - if i kill the process doing the indexing and then restart it, will it continue where it left off, or will it start over again ?
<jelmer> salsaman: I think it'll start over, but not entirely sure
<salsaman> ok thanks
<salsaman> can anybody point me to a document that shows how to set up a shared repository with sftp ? at the moment i have it working but only via http
<jelmer> salsaman: it should be the same with sftp
<bob2> just with more umask fiddling
<salsaman> just replace http://foo with sftp://<username>@foo ?
<jelmer> salsaman: basically
<jelmer> bob2: well, http doesn't allow any writing :)
<bob2> hm, I thought webdav worked?
<salsaman> hmmm i tried, but sftp was giving me an error that the repository didnt exist
<jelmer> salsaman: can you be more specific?
<salsaman> bzr: ERROR: Not a branch: sftp://<user>@a.b.c.d/path/to/repository
<bob2> well it's not a branch
<salsaman> http://a.b.c.d:8080/repository works
<bob2> you do need to use sftp://<user>@a.b.c.d/path/to/repository/somebranch
<salsaman> no, i want to make a local branch from the remote repository
<salsaman> the command is "bzr branch" isnt it :
<salsaman> bzr branch sftp://<user>@a.b.c.d/path/to/repository local.repo
<salsaman> ?
<salsaman> if i use http it works fine
<salsaman> what am i missing :
<salsaman> ?
<bob2> I think you're mixing up branches and repositories
<salsaman> oh ?
<salsaman> so you are saying i should make a local repository from the remote repository ? is that it ?
<salsaman> im just following the instructions here: http://wiki.bazaar.canonical.com/SharedRepositoryTutorial
<bob2> no, I just think you're having trouble due to mixing up repositories and branches
<bob2> what are you trying to do?  create a local branch from a remote branch?
<salsaman> ok, i have set up a remote repository, inside it i have 2 branches (read only, and read/write)
<salsaman> now i want to make a local branch from the read/write branch
<salsaman> at least i think they are branches on the remote machine
<bob2> bzr branch sftp://<user>@a.b.c.d/path/to/repository/somebranch
<salsaman> bob2, that is exactly what im doing
<salsaman> except it gives the ERROR not a branch message
<bob2> well, I mean, you're not, or you wouldn't get that error
<bob2> :)
<bob2> really suspect you're either forgetting the branch or you're mixed up about the path to the repo
<bob2> maybe use the 'sftp' command line tool from openssh to have a look
<slestak> hey guys.  aware that the bzr wiki is throwing db errors?
<slestak> one url that fails for me  http://wiki.bazaar.canonical.com/BzrPlugins
<jelmer> slestak: works fine here
<slestak> hrm
<slestak> down for me and a friend 20 miles from me
<slestak> Internal Server Error
<vila> slestak: seems to be spurious, got errors and after refreshing, the pages
<jelmer> hmm, now I get an error too
<slestak> that wasnt the first page i tried, maybe the third url at that wiki
<slestak> ok, bzrplugins just worked on 4th attempt
<gfolkert> http://wiki.bazaar.canonical.com is intermittent with me. Anyone else confirm? Sometimes I get the pages, other times I get and Internal Server Error
<jelmer> gfolkert: yeah, we were just chatting about that
<gfolkert> Okies. Thanks. Hoping is was just me...
<jelmer> perhaps vila knows who to ping?
<vila> jelmer: not really :-/ I hope some oops is popping on someone's radar...
<salsaman> bob2: apologies....you were right
<salsaman> i had an error in the path
<salsaman> or rather....i made a symlink to the branch, but the symlink needs to be to the repository containing the branch
<gfolkert> So long and thanks for all the fish!
#bzr 2013-03-12
<hrw> hi
<hrw> can someone remind me where lp: is defined?
<hrw> found
<jumoit> hey, here's a quick question if there is a chance to get anonymous access via bzr?
<jpds> jumoit: Yes, you can branch over HTTP.
<LeoNerd> If your branch is visible by HTTP, then sure
<LeoNerd> Though I don't think "anonymous" is quite the right word here; obviously the server can still log IP addresses and whatnot.. but perhaps "unauthenticated" is a better term
<mgz> bzr branch tor:...
<mgz> someone want to write a plugin? :)
<jumoit> thanks, you guys. then, i'm to try what you just told me...then, reply you.
<jumoit> LeoNerd, yeah, that's exactly what i wanna to ask around here. thanks.
<jumoit> actually, i wanna get source from here https://code.launchpad.net/canonical-identity-provider by the unauthenticated way. :)
<mgz> that's no problem, just branch lp:canonical-identity-provider without a launchpad login set in your bazaar configuration
<jumoit> mgz, when trying with unauthenticated, bzr is asking me login with ssh...
<jpds> jumoit: Right, because you did bzr launchpad-login at some point.
<jpds> jumoit: You'll have to edit: .bazaar/authentication.conf
<mgz> jumoit: `bzr config --scope=bazaar --remove launchpad_username`
<mgz> and the authentication.conf bits can then be left as-is
<mgz> and you can rerun `bzr launchpad-login YOU` later to set it again
<jumoit> jpds, yeah, i can follow what you just told setting up ssh with launchpad...but, you know, there are so many people not willing to set up an account when only cloning source from launchpad...so, i have to find out a good way to help people get source without setting up an account on launchpad to get it.
<jumoit> mgz, any ideas on that?
<mgz> if they don't want to set up ssh, they need to just not set their launchpad username
<mgz> I agree setting up ssh is hard for people who don't use it on a daily basis anyway
<wolfrage> Can some one please walk me through the standard steps to create a feature branch of a project in order to patch a bug?  The project is: lp:simplegc.
<wolfrage> I also need some better understanding, so can I not patch this just on my local machine, but I have to create a branch on LaunchPad, but I keepdoing it wrong...
<jpds> wolfrage: bzr branch lp:simplegc
<wolfrage> Once the branch is their how do I get the code locally so that I can do the patch
<jpds> wolfrage: Then: bzr branch simplegc feature-name
<wolfrage> ahhh OK I am using bazaar explorer and the feature option is not a normal option, though one would think it would be in colaborate
<wolfrage> bzr branch will create a copy of the branch in the current directory right, so If I want it to reflect right then that should be done in a directory called trunk?
<wolfrage> by reflect right I just mean that my previous experience with feature branches seemed to just use side by side directory levels.
<jumoit> mgz, when inputing "bzr branch lp:canonical-identity-provider" from the terminal,  some errors came up, and telling me..Permission denied (publickey).
<wolfrage> jumoit: just went through this you need to have a proper rsa key in your .ssh directory
<mgz> jumoit: you still haven't deleted your launchpad username from the config :)
<mgz> really you should just go through the ssh setup and get that working though
<jpds> wolfrage: http://doc.bazaar.canonical.com/bzr.2.5/en/tutorials/using_bazaar_with_launchpad.html
<wolfrage> jumoit: https://help.launchpad.net/YourAccount/CreatingAnSSHKeyPair
<mgz> right you two, help each other :)
<wolfrage> jpds: Thanks
<jumoit> you guys, thanks. after taking steps described in these links, i can set up ssh with launchpad. and i can get source successfully...but, other guys that only wanna get source (like git clone)  think that there is no need to set up an account on launchpad. so, all i now need is all about how to get access to projects launched on launchpad in the unauthenticated way?
<mgz> jumoit: all they need to do is *not* run bzr launchpad-login
<mgz> you were having issues because you'd done that, then also perhaps because it'd stored the bzr+ssh url for the branch you were looking at
 * jelmer waves to mgz
<mgz> hey jelmer!
<mgz> enjoying your snow?
<mgz> that was a nasty shock coming through london after being in sunny atlanta
<jelmer> mgz: ah, so it's your fault!
<jumoit> mgz, actually, i'm also new to bzr...so, seems that there is a learning curve to get bzr work like a charm. but, now, i need only one instruction to get source on launchpad anonymously.
<jumoit> let's say, get source from https://code.launchpad.net/canonical-identity-provider by only one instruction.
<jelmer> mgz: what were you up to in sunny Atlanta?
<mgz> juju sprint
<mgz> was pretty good
<mgz> jumoit: `bzr branch lp:canonical-identity-provider`
<mgz> though as we discovered last week `bzr branch http://launchpad.net/bzr` for instance also works, due to some funky launchpad redirecting
<lifeless> mgz: o/
<lifeless> mgz: thanks for your thoughtful blog post
<mgz> hey lifeless, sorry for missing you on irc a few days earlier when you pointed me at the subunit changes :)
<lifeless> mgz: de nada :)
<jumoit> mgz, thanks. it works well in another user (www-data) on my workstation running ubuntu10.04 by "zr branch lp:canonical-identity-provider".. but, bzr told me that writing or accessing private data needs to set up an account on launchpad.
<mgz> right, it very helpfully does. getting the source worked fine, and that branch can be pulled fine from there on
<mgz> if they want to submit things back to you, they do need to either do that ssh setup or host their own branches somewhere else that you can access
<jumoit> mgz, thank you for your suggestion. then, i will tell them  what you just told me. thanks again. :)
<LarstiQ> mgz, jelmer: oh, if you want some more snow, we have plenty!
<mgz> no, it's okay, you can keep it :)
<LarstiQ> mgz: if you change your mind, I'm sure it will still be here till April
<jelmer> LarstiQ: (-:
<jelmer> It seems like Brits and their trains are fairly delicate creatures..
<wolfrage> Ok so from earlier I have made my patches, now I need to upload my feature branch to LP right, then I can request a merge right?
<jelmer> wolfrage: yep
<wolfrage> jelmer: is it: bzr register-branch
<wolfrage> jelmer: or do I just push?
<jelmer> wolfrage: you can just push
<jelmer> 'bzr register-branch' is only really useful if you are hosting your branch elsewhere
<wolfrage> jelmer: OK
<jumoit> mgz, still there? any ideas on this case. (under /home/user1, setting up an account on launchpad as well as ssh (both works well). but, for the sake of security, i don't want to share private key under /home/user1 with /home/user2. but, user2 still can get source on launchpad by the authenticated way. PS: user1/2 both based on the same workstation)
<mgz> private keys are password protected and user-only readable
<jumoit> mgz, then, i set up a file called /home/user2/.ssh/config
<mgz> ssh will even complain if you have the wrong unix perms on your private key
<mgz> the solution is user2 also creates a set of ssh keys
<jumoit> but, so many ssh keys is not a good idea on the same workstation, i think. so, what would be the best for the case.?
<mgz> it's the right solution, the .ssh directory is per-user rather than machine wide for a reason
<jumoit> let's say, user1 is my home, while user2 is something else like www-data for apache2. user2(www-data) is used to host some sites
<jumoit> user1(my home) used for development.
<mgz> okay, so if both users are really you, then you're doing something else wrong :)
<mgz> either your bot should have its own credentials, or it should use read-only access, or you should just manually do the bot steps
<jam> jelmer: /wave
<jelmer> hey jam :)
<jelmer> jam: isn't this time well past your work day?
<jam> jelmer: yeah, it is almost 9pm now, but I have my work call with my US manager (deryck), so I was around
<jumoit> mgz, all right, all right...actually, there is some private data on launchpad required to set up account on launchpad...so, when deploying some site under /home/www-data, must set up one account as well to get access to private data.
<jam> mgz, jumoit: if you don't want to share the ssh creds, can you just put both pub keys into the same LP account?
<jam> I realize having a bot account would be ok, but sometimes that is clumsy (LP requires a unique email address for every user, so bots have to get yet-another address from my home domain)
<mgz> jumoit: I don't see why the www-data needs write-access to launchpad currently
<jam> mgz: well, he may want it to use bzr+ssh, and we never did implement unauthenticated ssh access.
<jelmer> jam: ah :-)
<jumoit> mgz, when deploying sso site against https://launchpad.net/canonical-identity-provider, it really needs what i just said...
<mgz> really? I doubt that... in what manner?
<jumoit> mgz, when setting up a virtual env by fab bootstrap, it really needs bzr
<mgz> it needs read-only access, I can understand
<mgz> can't see why it'd need to push changes
<jumoit> no, it need more...
<jumoit> http://bazaar.launchpad.net/~canonical-isd-hackers/canonical-identity-provider/trunk/view/head:/requirements/config-manager.txt
<jumoit> http://bazaar.launchpad.net/~canonical-isd-hackers/canonical-identity-provider/trunk/view/head:/fabtasks/environment.py
<jam> mgz: well, they hard-coded bzr+ssh urls, so thus need bzr+ssh :)
<jam> I haven't ever seen bazaar.isd. I wonder if that is inside the canonical network.
<jumoit> jam, i have no idea on that. but, i think, mgz could tell you more
<jumoit> :)
<mgz> file a bug, and then fix the branch, there's no reason you have to live with other people's broken code when you have access to the source and they take patches :)
<jumoit> yeah, i have done that. plus, you guys in that project will promise to correct it.
<mgz> the point is, you can fix it, then propose the fix
<mgz> no reason to wait for someone else to get to it.
<jumoit> no, i have no right to push...just report bugs. that's.
<jumoit> that's all
<mgz> you don't need push rights
<mgz> you fix your branch. and comit
<mgz> then push to your launchpad namespace, and do 'propose merge'
<jumoit> yeah, good point.
<jam> jumoit: the *easy* answer, give the bot an ssh key, and then add both ssh keys to your account. The other way, rename all the "bzr+ssh://bazaar.launchpad.net/" branches to be "lp:" and bzr will figure out where to get it.
<jam> bazaar.isd is trickier.
<jam> environment.py rewrites them to be from bazaar.launchpad.net, but I'm guessing the deployment process does it differently for production.
<jumoit> jam, like you said, that will be replaced by bazaar.launchpad.net. so, i guess that you're also a python programmer, right?
<jumoit> well, you guys, thanks for your helping around here. see ya. and have a good time. :)
<jam> good luck jumoit
<jumoit> well, let's hope so, jam. :)
<jumoit> jam, you know, python is really python;-)
#bzr 2013-03-13
<jumoit> how to get source from this revision, http://bazaar.launchpad.net/~canonical-isd-qa/selenium-simple-test/trunk/@362?
<thumper> no staying power
<thumper> jumoit: just in case you come back and look at logs... bzr branch lp:~canonical-isd-qa/selenium-simple-test/trunk (as r362 is the latest)
<mahendra> hello everyone ! I need to use bzr behind a http proxy which restricting bzr to connect.
<mahendra> Is there any way so that i can use tor socks proxy with bzr as i am not successful in setting up polipo with tor to get http proxy?
<bob2> how did tor get involved
<bob2> if all you have is CONNECT, just use an https url
<mahendra> hey bob, i tried that this is my config file [~/.bazaar/bazaar.conf] [DEFAULT] http_proxy = http://10.3.100.212:8080/ https_proxy = https://10.3.100.212:8080/
<bob2> ?
<bob2> shouldn't have https// there afaik
<mahendra> in both case i'm getting this error : bzr: ERROR: Connection error: while sending POST /bazaar/: [Errno 111] Connection refused
<bob2> well, you'll need to check those urls are correct and that the server is up and that the proxy works
<mahendra> yup, that proxy is currently working i m using that in firefox but gets same error when i do : $ bzr branch lp:mailman
<mahendra> this is the first time i m using bzr before that i worked on git same problem happened if used git protocol to fetch but http gives an alternate option with http proxy.
<mgz> mahendra: try `bzr branch nosmart+http://bazaar.launchpad.net/~mailman-coders/mailman/3.0/
<mgz> instead
<mahendra> it gives error : bzr: ERROR: Connection error: while sending GET /~mailman-coders/mailman/3.0/.bzr/branch-format: [Errno 111] Connection refused
<mgz> okay, so your proxy isn't even responding to GET, or you're not using the proxy
<mahendra> i am using the proxy by declaring it in config file [~/.bazaar/bazaar.conf] [DEFAULT] http_proxy = http://10.3.100.212:8080/
<mgz> you have HTTP_PROXY exported?
<mahendra> yes
<mgz> okay, that config setting is no good
<mgz> instead do: `export HTTP_PROXY=http://10.3.100.212:8080/` then branch
<mahendra> still same error :(
<mgz> mahendra: so, you really just need to debug your proxy, bazaar isn't doing anything fancy here
<mahendra> yes thats what i asked first . can we connect bzr through socks proxy (using tor) i strongly believe that our institute's proxy sucks in restricting all these good stuffs also.
<mgz> if you can tunnel ssh through it, then yes
<mahendra> ok will give ssh tunneling atry.
<mahendra> hey mgz thanks for your suggestion. bzr worked after upgrading it 2.5 from default 2.4.1 in the old but my fav lucid version
<mgz> mahendra: ace.
<mahendra> hahaha
<mahendra> that was 2.1.4*
<slestak> i am getting an Access is denied error using tortoise with ssh+bzr and sftp transport on win8-pro-64 on a folder in my home directory
<slestak> trying to do a branch from a server on my lan
<wolfrage> slestak: network drives on windows with revision control software is a bad idea...
<slestak> not a network drive, using ssh transport
<slestak> i have a repo on an ubuntu machine
<slestak> i am trying to branch it to my windows machine
<slestak> i have permissions on my home dir on windows, so trying to figure out what bzr has issue with.
<wolfrage> slestak: try ssh first to ensure you can access it normally from the windows machine with out bzr
<wolfrage> got to go now sorry
<slestak> ssh works and bzr+ssh works from cmd.exe so it appears to be a tortoise only issue
<mgz> slestak: look in your .bzr.log for more info
<slestak> would you happen to have its defaul location?
<slestak> the .bzr.log file
<slestak> i see it
<mgz> `bzr version` tells you
<slestak> it seems like bzr's branch feature to use the last component of the from_source as the default to_source does not work on toortoise because it warns me that the destination directory is non-empty
<slestak> because of that, i specified the to_dir.  that dir was created by the tortoise process, but it does nto have permission on it.
<slestak> TransformRenameFailed: Failed to rename C:/Users/Steve/Documents/projects/addons-oddello-dev/.bzr/checkout/limbo/new-4 to C:/Users/Steve/Documents/projects/addons-oddello-dev/us_statutory_reports: [Error 5] Access is denied
<mgz> hm, not sure I know enough about windows acls to propose a sane fix
<slestak> should i just file a bug on lp and document it?
<slestak> works for me
<slestak> once it gets assigned, i can help
<mgz> if you know what to change locally, that's probably worth documenting somewhere
<mgz> and a bug against tortoisebzr wouldn't hurt
<slestak> i worked around the issue by not using tortoise, but bzr in cmd.exe
<slestak> i cant work on this atm, busy with client work
<slestak> i'll file issue, thx
<mgz> just a bug report would be great then
<slestak> am i correct that tortoise is in the main bzr repo?  its not separate anymore i think
<mgz> you want to file the bug against the tortoisebzr project
<slestak> thx, i see
<vedic> I have python programs version control. Is there something like this for bzr?  __version__ = "$Revision: 89db18c77152 $"
<bob2> no
<lolek> jelmer: ping ?
<doublep> hi. suppose i did 'bzr branch lp:project', made some changes and then 'bzr push lp:~me/project/hack1'. now that changes are "saved" in a branch remotely, how do i switch my local branch to be a clean copy of original project?
<bob2> bzr switch someurl
<doublep> i tried that, but it complains: "bzr: ERROR: Cannot switch a branch, only a checkout."
<fullermd> No, you probably want more like pull --overwrite.
<fullermd> Though I'd be a bit leery of workflows that called for --overwrite's or --force's or the like as a regular thing.
<bob2> switch really should support that :/
<doublep> fullermd: that worked or at least it looks like what i want now. thank you
<doublep> yeah, command is a bit weird though
#bzr 2013-03-14
<yusha> Where can I get a full list of bzr's configuration options?
<mgz> yusha: `bzr help configuration`, also the html docs
<yusha> Both lacked any reference to "ssl" anywhere. Anyway, I brute forced the configuration, thanks
<deepy> I have a subversion repository with a file that I need to make a local modification to, I want my VCS to pretend that I haven't touched that file. Can I use bzr for this?
<LeoNerd> I vaguely recall a "bzr freeze", though I appear not to have it here so maybe it's a plugin..?
<jelmer> LeoNerd: I don't think that was actually implemented.
<LeoNerd> Hrmmm
<jelmer> I concur.
<mgz> lofi methods, like having a config template and then an ignored actual config file, seem to work best
<LeoNerd> Yah
<LeoNerd> I dislike the general idea of freeze, because it's about as dangerous as the git index
<LeoNerd> It allows you to check in a state of the source tree that never actually existed in disk, and so couldn't possibly have been compiled, unit tested, or whatever.
<LeoNerd> It becomes far too easy to accidentally commit things that cannot possibly work
<mark06> I have bzr-email installed, and I have configured the commit message including two line breaks like this: post_commit_body = "OlÃ¡, $committer adicionou a revisÃ£o $revision ao projeto EXOF.\n\n"
<mark06> It was me actually who wrote such functionality, but I think it's bzr who should interpret or not the line breaks
<mark06> apparently, this used to work with old versions of Bazaar, but it's not working now
<mark06> what could have changed and what can I do to fix this?
<mark06> it seems that self._format has changed
<mark06> uhm, no
<mark06> I didn't remember but the new lines thing was removed when merging into trunk
<mark06> the solution is using triple quotes in config file
<mark06> thanks all anyway
#bzr 2014-03-10
<mthaddon> am I misunderstanding how diff options work, or is http://paste.ubuntu.com/7068140/ failing to respect -x? I'd expect it to not say that the revision file has differed
<mthaddon> hmm, looks like it could be https://bugs.launchpad.net/bzr/+bug/268135
<ubot5> Ubuntu bug 268135 in Bazaar "bzr commit -x doesn't change the --show-diff output (iter_changes does not support excludes)" [Medium,Confirmed]
<mthaddon> or maybe not
<jelmer> mthaddon: -x takes a pattern IIRC, not a basename
<mthaddon> jelmer: I tried http://paste.ubuntu.com/7068864/ as well, but that doesn't seem to work either
<jelmer> mthaddon: ah, looks like -x doesn't work unless you specify -r
<jelmer> and even then, only works for files *inside* of the directory arguments you pass in
<mthaddon> jelmer: so what would I need to to exclude the revision file here? I can't seem to do it even with -r
<mgz> jelmer: does the {relpath} config thing work with colocated branches do you recall?
<jelmer> mthaddon: it invokes diff manually for each file, so -r is pointless
<jelmer> mgz: it works with the bzr-colo style, not sure about the builtin ones
<mthaddon> jelmer: sounds like there's no way of getting it to do what I'm trying to do, right? I should just go with filterdiff instead? http://paste.ubuntu.com/7068197/
<jelmer> mthaddon: yes, I don't think it's possible at the moment with 'bzr diff'.
<mthaddon> ok, thx
#bzr 2014-03-12
<SquirrelCZECH_> mno
<SquirrelCZECH_> hi folks!
<SquirrelCZECH_> have anybody tried to set automatic backup with bzr ?
<SquirrelCZECH_> like cron job that will watch for changes in specific file and than pushes it
#bzr 2014-03-15
<raj__> could I put a certain file in some VCS like git/subversion/etc only "when" I am  modifying it. So first I put the unmodified version & then the modified version. The desire is to put the file in VCS only when I want, rather than doing initial full directory commits.. possible ?
#bzr 2015-03-12
<dije> Just got a couple of errors about 'no such file' and 'no such file or directory'
<dije> Referencing file/dirnames ending '.tix'
<dije> In paths containing 'repository/indices'
<dije> Am I hosed?
<dije> Also includes '[Errno 2]'
<dije> Pathnames look like Python unicode strings
<mgz> dije: probably not, is that the *only* place you have the branch? otherwise, just copy again from upstream
<dije> I'm trying to merge from a checkout into a branch on the same machine, same filesystem
<dije> Errors are for the branch, not the checkout
<dije> This is one of the spokes of a hub-and-spoke setup
<dije> So the hub should have everything that this branch has/should have
<dije> What do I copy over? Or do I nuke the local branch and make a new one?
<dije> OK, I *think* I understand that the thing to do is to delete (move aside, backup) my existing branch, do a new 'bzr branch', and hope that my checkout doesn't realize anything has changed.
#bzr 2017-03-14
<zyga> e
#bzr 2017-03-17
<LeoNerd> Where did  bzr rebase  and  bzr replay  go?
<fullermd> Aren't they part of the rewrite plugin?
<fullermd> (is that what it's called?  re-something.  All the re-whatsit commands are in re-whatelsesit  ;)
#bzr 2018-03-15
<toohighto45IOK94> THIS IS A FREENODE BREAKING NEWS ALERT!! Hitechcg AND opal ARE GOING AT IT RIGHT NOW WITH A LOT OF FIGHTING AND ARGUING WOW YOU DON'T WANT TO MISS THIS!! TYPE /JOIN ## TO SEE THE ACTION...AGAIN TYPE /JOIN ## TO SEE THE ACTION!!
<toohighto45IOK94> toohighto45IOK94 quicksilver rweir Peng Keltia Peng_ djinni` ggherdov james_w m1sc yena fmccann fullermd elmo irsol nicoulaj jelmer fifr LeoNerd thomi bpierre wgrant charles erry anthonyf mthaddon pjdc ubot5` ajmitch verterok fifr[m] jam ubuntulog superfly alexlist catern
<jam> ban toohighto45IOK94
<wolfgangbr1> Hi, not sure if this chat is the best place to ask but thought I start here. We use Bazaar with Launchpad and since this week we experience a significant slowdown in our work with Bazaar. Creating branches, merging, etc. all takes a lot longer than normal.
<mgz> it may be worth asking in #launchpad (or hilite wgrant here perhaps)
 * wgrant awakens
<wgrant> wolfgangbr1: #launchpad is the right place, and I'm meant to be asleep, but nothing's changed there in the last week. Which bit of the process appears to take longer?
<wgrant> Which specific actions?
<wolfgangbr1> sorry, I had to reboot my machine. Not sure if anybody saw my question earlier.
