#bzr 2007-12-31
<jebblue> hi Bazaar in Synaptic Package Manager says "Unless you have a pressing reason to use bazaar you should use some other
<jebblue> revision control system as upstream development has ceased." yet Ubuntu Launchpad site is promoting Bazaar?
<TFKyle> jebblue: possibly you're looking at the package for the old bazaar and not bzr, see http://bazaar-vcs.org/HistoryOfBazaar for details
<jebblue> ah ok thanks yup bzr is in there
<jebblue> is (in your opinion) bzr generally equal to cvs ?
<Peng> jebblue: Equal to CVS is the worst insult you could give. :P
<jebblue> hehe ok well I'll need to read some, thnaks
<jebblue> thanks
<jebblue> I did a co on my cvs repository and then copied that to a new directory and then ran bzr init and it created a repository right there using a hidden dir .bzr!
<travisgriggs> hi there
<jebblue> that is a shift in thinking so no more CVSROOT type thing I guess - ok back to reading (I skipped ahead)
<travisgriggs> i've been reading up on the recent bazaar hype; this all seems intriguing
<travisgriggs> i've been "observing" dvcs systems for a while and have yet to plunge in
<travisgriggs> i wonder if any of the bzr implementors are here? i have some questions....
<Peng> jebblue: Check out conversion software so you don't lose all of your history.
<jebblue> ok also I installed bzr-gtk and it is not on my menus or on the path?
<jebblue> travisgriggs - ususally best to start with a question man - I'm new to bzr too
<travisgriggs> i'd like to build a smalltalk plugin for bazaar. i'm not sure where to start or how feasible this is. Smalltalk systems are live object systems, they can flatten things to files, but the focus is the "image" not a directory of files
<Peng> jebblue: (CVS converters tend to run into a lot of issues, so it might work better to use one of the CVS to svn ones, and then convert that to bzr.)
<jebblue> ok will do
<travisgriggs> i'm curious if it's doable to write a smalltalk interface to bazaar, so that what bazaar thinks it's seeing is a file system, but isn't really
<Peng> travisgriggs: I don't think any of the developers are here right now. They are a lot, but they just got 1.0 out the door before Christmas, so some of them are taking some vacation time.
<travisgriggs> ok, thanks
<Peng> travisgriggs: You could try the mailing list.
<Peng> Uh, ok, I'm gonna go. Bye.
 * Peng wanders off.
<spiv> travisgriggs: the "transport" layer in bazaar is pretty flexible, so it might be possible.  Definitely mail the list; I know there are some devs that are deeply familiar with both smalltalk and bazaar.
<dlee> In case anyone around knows... Peng commented earlier that cvs --> svn --> bzr might be better than direct cvs --> bzr.  I've been trying Tailor to go from CVS straight to BZR, and it seems to work fine except (I) I've not tried branched CVS repos yet, and (II) *it loses all my CVS tags!* :-P  So I'm open to recommendations on a better way to do this.  I also do need to convert one svn repo to bzr, for which I would use Tailor except it b
<dlee> I am trying to talk my office into using bzr, but though I warned them I was watching and waiting for bzr 1.0 a month or two ago, a strong move toward svn got afoot in the last couple weeks, and so now I'm basically going head to head (no pun intended) over VCS systems...
<lifeless> dlee: cvsps-import is very good
<lifeless> travisgriggs: the squeak fuse thing would be enough for bzr I think, or enough with a little work
<dlee> For my svn import--and this is probably a long shot:  I actually have a CVS repo whose HEAD about matches the first revision of the svn repo for the same project.  It would be cool to put the CVS and svn history both into bzr, but I have reason to keep the bzr rev numbers the same as the svn ones.  I've noticed that bound branch local commits can create rev numbers like 1.1.1 ... is it possible somehow to build a bzr history that contains
<Peng> dlee: For svn, there's bzr-svn, which actually lets bzr interact with svn branches.
<Peng> dlee: BTW, one of your messages ended at "Tailor except it" and the other at "history that contain". (Actually, they both ended one character after that, but my IRC client seems to have an off-by-one bug that cuts off the last character.)
<bitmonk> +1 to bzr-svn.  get it working, pull from your svn url, and never look back.
 * Peng wanders off.
<bitmonk> or, well, if you have collaborators who don't want to switch yet, you can just merge from bzr into svn.  it's very handy.
<dlee> Thanks, studying plugins...
<thumper> happy new year from UTC+13
<Peng> Bah, lucky.
<Peng> Happy New Year's Eve from UTC-05.
<Peng> thumper from New Zealand? Have I seen you in Mozilla circles?
<LeoNerd> Hrm... The sftp transport doesn't like long roundtrips
<LeoNerd> I'm here on a train with satelite wireless, so the latency is huge... 'bzr push' takes forever...
<radix> LeoNerd: bzr+ssh should be better
<thumper> Peng: unlikely, I haven't been in Mozilla circles
<lifeless> LeoNerd: using a pack repo ?
<dlee> Peng, belated answer--you observed that two of my lines were truncated.  Arg...they look fine here--must be a 440-or-so char-per-line limit in some IRC server/client or another.  Anyway, fwiw, here are the two lines, split so they should travel unmolested:
<dlee> In case anyone around knows... Peng commented earlier that cvs --> svn --> bzr might be better than direct cvs --> bzr.  I've been trying Tailor to go from CVS straight to BZR, and it seems to work fine except (I) I've not tried branched CVS repos yet, and (II) *it loses all my CVS tags!* :-P  So I'm open to recommendations on a better way to do this.  I also do need to convert one svn repo to bzr, for which I would use Tailor
<dlee> except it blows up on Windows+Cygwin because there's one file rename that only changes letter casing (a big oopsie on my part there).
<dlee> For my svn import--and this is probably a long shot:  I actually have a CVS repo whose HEAD about matches the first revision of the svn repo for the same project.  It would be cool to put the CVS and svn history both into bzr, but I have reason to keep the bzr rev numbers the same as the svn ones.  I've noticed that bound branch local commits can create rev numbers like 1.1.1 ... is it possible somehow to build a bzr history
<dlee> that contains the cvs stuff plus one sort of glue commit at revs < 2, then the svn revisions from there with their original numbers?
<dlee> (end of resends ... and I'm now trying cvs-import and plan to use earlier conversations in here as a guide to setting up the svn plugin)
<lifeless> dlee: 'bzr-cvsps-import' on lanchpad, and call the plugin in ~/.bazaar/plugins 'cvsps' works for me
<dlee> lifeless: I'm playing with that--looks like it got the branches and the tags from one of my more complex CVS projects, though I do wonder why it parks the tags in a directory instead of using bzr tag so "bzr tags" can work
<dlee> Maybe bzr tags are new?  I saw a page yesterday saying bzr does not support tags.
<fullermd> They were new in 0.15.  cvsps-import was mostly done before that, so...
<dlee> ic
<dlee> You know about Bazaar?  I think I asked you once by phone a while ago though.
<dlee> Lol that was a misdirected  private msg :P
#bzr 2008-01-01
<Peng> bzr: ERROR: xmlrpclib.Fault: <Fault -1: "Unexpected Zope exception: Unauthorized: (<zope.app.publisher.xmlrpc.metaconfigure.BranchSetAPI object at 0x2aaabec5bd50>, '__call__', 'launchpad.AnyPerson')">
<Peng> Wheee!
<Peng> Apparently the launchpad plugin really wants my password.
<lifeless> thats launchpad wanting it
<johnf> If I have a smart server whats the best way to have it send emails when commits are made? I was using bzr_hookless_email but it seems to have some issues with 1.0. Want to know if its the best way to do this sort of thing before fxiixing it
<dato> johnf: what issues?
<dato> johnf: it should work, but maybe you'd need to restart it if you upgrade your branches
<johnf> I have it running out of cron
<johnf> let me paste the bactrace somewhere
<dato> yes, please
<dato> !pastebin
<ubotu> pastebin is a service to post large texts so you don't flood the channel. The Ubuntu pastebin is at http://paste.ubuntu-nl.org (make sure you give us the URL for your paste - see also the #ubuntu channel topic)
<johnf> dato: http://paste.ubuntu-nl.org/50358/
<johnf> Havn't looked into the problem myself yet. Was wondering firstly if this is the best tool to use
<dato> johnf: well, I wrote it, so I may be a bit biased. I find it convinient when it's difficult or cumbersome to get every committer to install and configure bzr-email themselves.
<johnf> hehe
<johnf> yeah I have the same problem.
<dato> johnf: hm, let me try reproducing your problem.
<dato> johnf: ok, got it, thanks for reporting!
<dato> johnf: you can pull a fix from http://chistera.yi.org/~adeodato/code/bzr/bzr-hookless-email/, the launchpad branch is a mirror and will take a bit before it gets the fix.
<johnf> dato: no problems. Was just having a look myself. Looks like you might need to lock the repository?
<dato> yeah, that's what I did. looks like bzr-email will need updating as well. (that part of bzr-hookless-email came from bzr-email)
<lifeless> johnf: patch bzr to send a 'commit has occured' at the end of the transaction to the smart server
<lifeless> johnf: its on the TODO list
<lifeless> johnf: or perhaps if you really mean 'when the branch tip advances' patch bzr-email to hook into BranchHooks.set_revision_info and do emails then
<lifeless> both will run on the server and don't need a cron job etc
<lifeless> johnf: its really waiting for someone that wants it to do it :)
<lifeless> also, jan 1st. HOLIDAY.
 * dato is just waiting for friends to arrive to have breakfast :)
<johnf> dato: thanks
<johnf> lifeless: I shall add it to my long list of things to do :)
<lifeless> johnf: we're back tomorrow; can we arrange to meet up say friday?
<johnf> lifeless: sure or earlier. I can drop past anyday with everything
<lifeless> cool - well thursday sometime would be great. Anytime, just ring a bit before so I'm not out at the shops.
<indu> hi all
<indu> happy new year
<indu> i need help in bazaar implementation
<indu> i created a repo using bzr init-repo, and then created branches under that, using bzr init
<indu> i am finding that the sub branches are independent and are no where related to the main branch which was created using bzr init-repo
<indu> am i going in right path ?
<Peng> indu: bzr init-repo doesn't create branches.
<Peng> indu: It's simply an optimization, so the data from all branches created under it will be stored in one place instead of duplicated in each branch.
<indu> Peng, could u please explain this clearly
<indu> how does duplication be saved ?
<indu> Peng,  sorry,how does the duplication is not occured  ?
<Peng> indu: If you have two branches of the same project, 99% of the history is identical, but all of it would be stored twice. Using a shared repo, it's only stored once.
<indu>  Peng here u mean branch as the one created  using bzr init ?
<Peng> indu: Sure.
<Peng> indu: If you just created the branch, there's no history, so it's not so relevant.
<Peng> I'm sorry, but I'm gonna go.
<Peng> But yes, the branches are independent.
 * Peng wanders off.
<Peng> There isn't really a way around that at the moment.
<deflated> Hello. What do you think of taking Bazaar for backups?
<Peng> deflated: I think it's very useful to use a VCS on some of your files, but to back up your email or whatever is a bad idea.
<deflated> Thank you for your response. It's meant for backuping my source codes. I plan to store them on a remote server. I only change approx. 10 files a day so that it's not that efficient to transfer *all files* via FTP to the server. What do you think of using Bazaar in this case or is there even a better way? If the application is stable I'll release it as open-source so I'll need to use a VCS but it's planned for the end of this year. For that time I ne
<deflated> So Peng, what do you think? Are there any better alternatives? Here's an interesting article of someone who uses Bazaar as for backuping his data: http://www.singularity.be/node/6357
<deflated> But he uses rsync for remote backups. The remote server connects to his computer and gets all data.
<michaelkohwj> i have a web host that i can SSH into, but it doesn't have bzr installed. can I still push and pull from it over ssh?
<lifeless> deflated: bzr for that is fine :)
<lifeless> michaelkohwj: yes if they have python 2.5 you can dump a copy of bzr in your home dir and set BZR_REMOTE_PATH
<lifeless> later all
<michaelkohwj> hm i see
<michaelkohwj> lifeless: thanks
<deflated> Ok, then I'll give it a try. Thank you very much!
<michaelkohwj> i can FTP over, but i can't seem to get it right:
<michaelkohwj> bzr push --create-prefix ftp://user:pass@url.com/~/dir
<michaelkohwj> oh, it works, but now: "but does not have a valid .bzr directory"
<michaelkohwj> ... --use-existing-dir
<michaelkohwj> hi, how should I push to a remote server over ssh, that doesn't have bzr installed?
<michaelkohwj> i can't install bzr on it either
<michaelkohwj> ok, i got it working with ftp, but the source files aren't transferred
<michaelkohwj> bzr push --create-prefix ftp://user:pass@url.com/dir --use-existing-directory -v just transfers .bzr
<michaelkohwj> what shoul i do to push to a remote dir?
<michaelkohwj> thanks!
<thumper> michaelkohwj: pushing doesn't create the working tree
<thumper> michaelkohwj: just the branch and repo if needed
 * thumper recalls someone working on pushing a working tree of files
 * thumper walks away again
<Peng> michaelkohwj: Use SFTP if you can.
<Peng> MicahElliott: (It's an FTP-like protocol tunnelled over SSH.)
<Peng> thumper: push-and-update plugin.
<indu> hi, could someone give me a link for downloading loggerhead
<indu> I am not getting any
<michaelkohwj> Peng: but if I pull from it, will the effect be the same?
<michaelkohwj> Peng: let me explain more clearly:
<michaelkohwj> Peng: X makes changes to the project and pushes it to the server
<michaelkohwj> Y then clones from the server, works on it, and then pushes it up.
<michaelkohwj> (i'm not sure that i'm using the correct terms)
<michaelkohwj> then when X pulls from the server and merges, will X get Y's changes?
<Peng> michaelkohwj: Will doing what be the same?
<michaelkohwj> Peng: um, such as pulling and pushing from and to a thumbdrive?
<michaelkohwj> (sorry, i'm new to SCM)
<Peng> michaelkohwj: It doesn't matter what you push and pull to.
<michaelkohwj> Peng: oh i see- the -diffs- are stored in the place i push to
<michaelkohwj> is that right?
<Peng> michaelkohwj: Something like that, yeah.
<dlee> Michael:  I think you're asking if A --push--> B and B <--pull-- A have the same effect.  I believe they do.  You might also be asking if changes pushed to server by one person will arrive at another person's local copy when that person then pulls from the server.  Again, yes, this should work.  Caveat:  I've been using Bazaar for about a week myself, but I've been using VC systems of various sorts for years.
<Peng> (If one person pushing and another pulling didn't work, that wouldn't be much of a VCS...)
<dlee> :)
<dlee> I thought the question might be more about how push and pull were related, but at 5 AM after a lot of local activity, I don't trust my read :)
<michaelkohwj> actually, i was just confused when pushing didn't place the files in the remote server, but instead placed .bzr/ in it only
<michaelkohwj> so .bzr contains the diffs, and thus the actual working files are unnecessary?
<Peng> michaelkohwj: Yeah, .bzr contains all of the data. It would usually be a waste of bandwidth to create a working tree (and there would be other issues, like what if there are merge conflicts?).
 * michaelkohwj has been enlightened
<michaelkohwj> thanks Peng and dlee
<dlee> Ah ok... .bzr contains everything necessary to reconstruct the local files.  It's just that it's not so easy for your "push"ing system to make the "push" receiver update the local files on that end.  You can't push your local files to remote because they may contain changes.  push and pull work with what's in .bzr, not what's in all the other files in your working tree.  Does that help?
<GaryvdM> If you push over a local transport, it will also push the working tree. But pushing over a remote transport will not push the working tree.
<GaryvdM> Working trees can easily be recreated from the repository (contained in the .bzr dir).
<dlee> Doesn't a local-transport push still push the *committed* rev, not the actual local (pushing-side) working-tree files?
<michaelkohwj> dlee: yes =)
<GaryvdM> yes
<dlee> A "no" to that would have been a shock...
<michaelkohwj> thanks for the help, i understand now =)
<dlee> I really hope I can talk my office into Bazaar now, even though they jumped at Svn very recently before I knew what they were doing :P
<michaelkohwj> dlee: perhaps bzr-svn is a short-term solution? but changing everyone to bzr is probably better, i guess..
<dlee> right on both counts imo
 * dlee wanders off perchance to sleep
<kohwj> hi, when I try to push over sftp, i get a Permission deined:
<kohwj> error (errno 13). hold on, let me google it first
<kohwj> hm not much luck. ftp works, though
<kohwj> never mind, i just solved it with rsync and bzr update
<kohwj> bzr is really user-friendly, imo
<kohwj> thank you bzr
<jelmer> re
<Peng> fwd!
<TFKyle> bcc!
<_markus__> hi
<lifeless> yo
<_markus__> I'm interested in bzr to use it. I'm currently using svn. I've gone through the user guide but some questions are not answered. I'm not sure if bazaar is the right tool here. I've a central svn server with the projects (can't change this) and would like to check a version out and work offline on it, do offline commits and later merge this changes back to the svn repository. now, svn doesn't...
<_markus__> ...support something like local commits. Bazaar seems to do, but I'm unsure how I can work with both together ...
<Peng> _markus__: You want to use both bzr and svn?
<_markus__> Peng: well .. I don't know, honestly :) I mean, I'm forced to use svn on the central side. I thought bzr can fill me the gap of local commits and then push the changes to the live system. Maybe I understand this wrong.
<Peng> _markus__: There's an excellent bzr-svn plugin that lets bzr interact with svn repos. (Minor pain to install though.)
<Peng> _markus__: Of course, ideally your office would switch to bzr. ;)
<_markus__> Peng: I've this plugin install and read about it .. but maybe I'm dumb but I've no plan in front how things work together :-/
<_markus__> (I'm using debian testing, everything is packaged up)
<_markus__> Peng: it's not only about the office, but also various open source projects, so it's not my choice, really
<Peng> _markus__: I think you can just "bzr branch" from the svn repo, and then "bzr push" your changes back to it.
<_markus__> hmm
<_markus__> so easy? let me try ..
<Peng> _markus__: Ideally, those FOSS projects would switch to bzr too . . . :)
<_markus__> Peng: hmm .. is there a nice gui client such as TortoiseSVN? TortoiseSVN is really very useful
<Peng> _markus__: There are a few GUI clients. QBzr (Qt), bzr-gtk (GTK+), and TortoiseBzr or something.
<_markus__> Peng: hmm .. TortoiseBzr doesn't seem to be nearly somewhere were TortoiseSvn is ... anyway . bzr branch is running. Unexpectedly easy. This command seems to download the complete history information, am I right?
<jelmer> _markus__: yes. It will be slow the first time but will cache some data for later use
<_markus__> Hm .. seems to hang .. :/
<_markus__> Jup, it hangs. Is there any other way without using bzr branch? I used strace, it now just sits there and hangs here "6043  poll("
<Odd_Bloke> _markus__: Does it create anything in the expected directory?
<_markus__> Odd_Bloke: no, it only created some files in ~/.bazaar/svn-cache/
<_markus__> On the console I rea "fetching svn revision info  7/37". The complete svn repos is no more than 50MB
<Odd_Bloke> jelmer: ^
<LeoNerd> You're right. bzr+ssh is a lot faster than sftp over long-latency links
<LeoNerd> Thanks to whoever suggested that earlier
<lifeless> LeoNerd: you using a pack repo or knits still ?
<LeoNerd> How do I tell?
<dlee> LeoNerd: What's the top line from bzr info?
<LeoNerd> Standalone tree (format: dirstate-tags)
<dato> that's knits
<LeoNerd> That's in my checked out branch, not the (rempte) repo on the server
<Peng> Run "bzr info http://path.to/remote/repo".
<Peng> If you're using a checkout, bzr info might've listed the server's format.
<LeoNerd> OK.. Server says Repository branch (format: dirstate-tags)
<Peng> If you don't need compatibility with bzr < 0.92, upgrading to pack-0.92 should really boost performance over dumb protocols (http, sftp).
<LeoNerd> Right.. Well, it's only me that uses this really, so.. yeah.. I guess I can do that
<jelmer> re
<Peng> glob!
<jelmer> _markus__: Sorry, not sure what could cause that. We're relying on the Subversion libraries there
<jelmer> Peng: :-)
<jelmer> _markus__: Does it always hang or does retrying work ok?
<mwhudson> lifeless: can you email me the loggerhead.conf file you are using for https://bugs.edge.launchpad.net/loggerhead/+bug/179347 ?
<ubotu> Launchpad bug 179347 in loggerhead "NotBranchError on startup" [Undecided,New]
<lifeless> mwhudson: done
<mwhudson> lifeless: how totally strange
<lifeless> mwhudson: I thought so.
 * mwhudson will look more tomorrow, too tired tonight
<lifeless> thanks
<lifeless> I grabbed your lp branch from bazaar.lp.net
<mwhudson> that's the right place to go
<igc> morning
 * fullermd waves at igc.
<igc> hi fullermd
<lifeless> mwhudson: consider relative urls for codebrowse, kthxsavebybandwidth
<lifeless> e.g. consider http://codebrowse.launchpad.net/~lifeless/squid/squid3-trunk/files/cvs-1%3Ahno-20071220081046-d59dmpbuvvyioekf?file_id=src-19960222132353-t43j7l5jst5z-28
<poolie> good morning
<spiv> Good morning.
#bzr 2008-01-02
 * igc lunch
<unenough> is there a way to change a commit message after the commit?
<poolie> unenough, uncommit then commit again
<unenough> no other way?
<poolie> unenough, sorry, not at present
<indu> hi all
<indu> good morning
<indu> i have some doubts in bazaar, can i get some help here
<indu> i want to to know how does the branches under the repo created using bzr init-repo are linked to the repo
<spiv> indu: just by being in a directory under the repo.
<indu> spiv, firstly i am not understanding one thing here
<indu> spiv, in svn we create a repo, using svnadmin create repo
<indu> and under that we create directories and make a structure
<indu> later on, each can get a branch from those direcotries
<indu> in bzr , where is the repo created ?
<fullermd> indu: It might be clearer if you were to forget about [shared] repos in bzr for a while.  They're not necessary.
<indu> spiv, ok as per your point, i was under that direcotry in that repo, and created branches using bar init
<spiv> In bzr, the repo is created where you tell "bzr init-repo" to make it.
<indu> bzr init
<indu> and then under that bzr init direcory i created sub branches again using bzr init,
<spiv> And then when reading/writing branches, bzr will check the parent directories all the way to the root until it finds a repository.
<indu> spiv, how can I view those details, whethere while reading or writing its checking the parent direcotires or not
<spiv> (but note that as fullermd says, there's no need to have a separate repo; if you don't create separate shared repo with "bzr init-repo", bzr will just make standalone branches which carry their own repo)
<indu> as, removing any branch under the repo, is not showing any affect on the repo
<spiv> On the filesystem, it's in the .bzr directories.
<spiv> You'll probably find "bzr info"/"bzr info -v" an easier way to get that information than looking inside the .bzr directories, though.
<indu> spiv, i need ur suggestion for creating the bzr structure , will exaplin u my project details
<indu> spiv, my project is builiding linus distribution which is based on debian, and thus we are trying to develop a community for contribution
<spiv> indu: Have you read http://doc.bazaar-vcs.org/latest/en/user-guide/index.html ?
<indu> thus the source of the packages will be alphabatical order, a/acpid/acpid_x_xx_X
<indu> b/boo/boo_x_xx_xx
<indu> where x_xx_xxx are package names with version number
<spiv> It sounds like you probably want a repository for each b/boo then.
<spiv> And each b/boo/boo_x_... would be a branch.
<spiv> Unlike SVN, in bzr a repository is just an optimisation.
<spiv> So if you have several branches of a single project (or in your case, package), then it's good to have a repository so that the common history in those branches only needs to be stored once, rather than once for each branch.
<spiv> So repositories save disk space and save on the amount of data to copy/transfer for many operations.  But they don't change the fundamental behaviour.
<indu> spiv, what is this common history ?
<spiv> indu: if you have boo_1.0 and boo_1.1, probably they have many revisions in common.
<spiv> For instance, most software projects have a "trunk" branch, and feature branches and release branches are made from that branch.
<spiv> So those branches share most of their history with the trunk.
<spiv> For instance, the development branch of bzr and the 1.0 release branch of bzr share most of their history.
<spiv> Does that make sense?
<spiv> In svn, when you make a branch it basically just copies a snapshot of the files in that version.  In bzr, a branch keeps the full history, not just the snapshot.
<indu> spiv, from where can i download the loggerhead source
<spiv> indu: http://www.lag.net/loggerhead/
<indu> spiv, ok
<spiv> indu: although this branch may have some improvements that haven't made it into robey's version: https://code.launchpad.net/~mwhudson/loggerhead/production
<indu> spiv, i am reading the user guide u sent, but before that
<indu> spiv, as per your directiones
<indu> i have to structure my repo like
<indu> bzr init-repo a
<indu> bzr init-repo a/aaa
<indu> bzr init a/aaa/acpid-xxxx
<indu> am i right ?
<spiv> indu: the "bzr init-repo a" is wasted
<spiv> indu: the repo at "a" would never be used.
<indu> why?
<spiv> But otherwise, that seems like a reasonable arrangement.
<spiv> Because each branch belongs to exactly one repository.
<indu> under aaa, there will be some more branches like, aaa-xxx, abc-xxx etc
<indu> where all these are seperate packages
<spiv> So when bzr looks at the branch in a/aaa/acpid-xxx, this is how it'll look for the repo:
<spiv>  - first, it'll look for a repo in a/aaa/acpid-xxx.  There's no repo there.
<spiv>  - then, it'll look in the next directory up: a/aaa.  There is a repository there.
<spiv>  - Done!  It looks no further.
<indu> ok
<indu> one  more thing
<indu> i tried created branches using "bzr init" , under "bzr inir-repo repo"
<indu> sorry. bzr init-repo repo
<indu> bzr init a
<indu> mkdir a/aaa
<indu> cd a,  bzr add aaa
<indu> then I tried
<indu> bzr init abc,
<indu> from a remote, i tried getting this newly created branch using bzr branch file:///~/repo/a/abc
<indu> this dint work, saying no valid working tree
<fullermd> I don't think ~ expands in a file:/// URL...
<fullermd> (of course, you're branching an empty branch there, so it doesn't do much)
<indu> i just wrote that, instead of mentioning the whole path
<spiv> I'm also not sure what you mean by "from a remote ... bzr branch file:///~/repo/a/abc"
<fullermd> You don't need the file:/// spec on it; just "bzr branch ~/repo/a/abc foo" would work.
<indu> not remotre, fullermd expalnation is correct in my case
<indu> bzr branch ~/repo/a/abc is correct
<indu> actually, i am using bzr-gtk
<spiv> indu: what does "bzr info ~/repo/a/abc" tell you?
<fullermd> Now, if you're still in ~/repo/a when you do that, it probably won't work, since it'll try to call the new branch 'abc', which would conflict with the real 'abc'.
<indu> spiv, i will try some more and then ping you back, thankyou for the help
<spiv> indu: you're welcome
<indu> spiv, can you give me some more examples for a good web front end for bazaar
<spiv> indu: loggerhead is the best I've seen IMO.  bazaar-webserve isn't as easy to use.  There's another one I think, but I forget what's called.
<indu> ok
<indu> how does this launchpad using bazaar ?
<spiv> indu: do you mean, how do you use launchpad?
<indu> spiv, no, i want to make a similar application like launchpad for my project also
<indu> thus, i want to inbuilt bazaar into it
<spiv> Oh, ok.
<spiv> Launchpad does *lots* of stuff :)
<indu> launchpad is not opensource , thus i cannot downlaod install  and use independently
<indu> spiv, yeah, i knew :)
<spiv> Launchpad uses loggerhead for its "codebrowse" feature.
<indu> spiv, https://code.launchpad.net/?
<indu> but the look is not like loggerhead
<spiv> indu: http://codebrowse.launchpad.net/~robey/loggerhead/devel/changes
<spiv> indu: (which is linked from https://code.launchpad.net/~robey/loggerhead/devel)
<spiv> It's a bit hard to describe exactly how to write something like launchpad, because launchpad does so much.
<spiv> But in general, because Launchpad is written in Python, it's fairly easy for it to use bzrlib.
<spiv> (in so far as writing useful software can ever be called "easy"...)
<fullermd> I have a friend who I've done some work with in the past who'd open discussion with "Look, it's real simple..."
<fullermd> He'd tell you it's easy.  You just have to write the code, test it out real quick, then deploy it.  How long can it take to do 3 things?
<fullermd> For some reason, I avoid doing work with him these days...
<indu> ok. i will try for my own
<indu> i need help in loggerhead configuration
<igc> night all
<indu> how can I make bazaar use apache web server for publishing the branches and repo
<fullermd> igc: Say, before you go...
<fullermd> igc: Did you see bug 178591?
<ubotu> Launchpad bug 178591 in bzr "running `bzr diff` in a subdirectory does not show changes in the	parent directory" [High,Confirmed] https://launchpad.net/bugs/178591
<glyph> Is this expected behavior?  http://rafb.net/p/8u9eU837.html
<mwhudson> glyph: are you pulling into a repository?
<glyph> mwhudson: The only command I didn't list there was "mkdir PyDoctor"
<mwhudson> oh oops
<mwhudson> pydoctor is still a dirstate-tags branch
<mwhudson> so if you rm -rf .bzr and init-repo --dirstate-tags, it should worl
<mwhudson> work
<fullermd> No, it's not.
<fullermd> lp:pydoctor is redirected to http://bazaar.launchpad.net/~mwhudson/pydoctor/dev/
<fullermd> Standalone branch (format: dirstate-with-subtree)
<mwhudson> oh right, bzr-svn
<mwhudson> that means the error makes more sense
<GoClick> When the page says Requires PyBaz which in turn requires Baz does that mean it requires bazaar or baz something else?
<mwhudson> nothing relevant should really require pybaz any more
<mwhudson> which page are you referring to?
<GoClick> Interesting
<GoClick> The install faq recommends Bzrtools
<GoClick> which states "Requires PyBaz, which, in turn, requires baz."
<GoClick> I know nothing about bazaar I just know we use svn now and hate it and I've been trying for 5 days to get it to compile in our environment but can't and #svn is jerky
<GoClick> so why should I try so hard to make software I hate work
<mwhudson> ah
<fullermd> bzrtools only requires pybaz if you use baz-import, which it doesn't sound like you care about.
<mwhudson> bzrtools only requires pybaz for one specific command
<spiv> indu: mwhudson knows about loggerhead configuratino
<GoClick> Oh ok
<indu> ok spiv , thanx
<GoClick> I was just trying to get everything installed so I could read about switching from svn to bzr
<mwhudson> GoClick: ah, ok
<mwhudson> GoClick: the page should be clearer, perhaps
<GoClick> It's not so bad I guess, It's 2:19am and I need to go to bed I have to work tomorrow
<GoClick> :P
<GoClick> Wait I'm working right now
<GoClick> my life is hell
<GoClick> Actually it's not that bad it's just stressed right now because someone decided we had to run RHEL4 on our new server instead of Ubuntu and I've never used RHEL so I'm like "wtf" with everything
<GoClick> night guys/gals whatever thanks
<indu> mwhudson, hi,
<indu> mwhudson, i want to know how i can use loggerhead, as well as, configuring apache web server for accessing repository
<mwhudson> indu: have i talked you you before about this?
<indu> mwhudson, no
<mwhudson> oh, ok
<mwhudson> so the latter part should be easy
<indu> i have a repo under ~/boss-repo
<indu> and i created a link for this under the /var/www (I am in Debian OS)
<indu> then I added the lines like,  http://rafb.net/p/PcN0Q142.html  in apache2.conf file
<indu> is it correct ?
<mwhudson> hang on
<mwhudson> when you say you want to configure apache to access the repo
<mwhudson> do you mean using bazaar or using a web browser and loggerhead?
<indu> i want to use web browser to browse the branches/repository created using bazaar, then later, i even want to use loggerhead to view the repository , as it good web absed front end
<mwhudson> ok
<mwhudson> well, you'll be wanting to put some port numbers in that apache config file
<indu> mwhudson, i was having 8080 as the port
<mwhudson> that sounds more likely
<indu> so the lines were like         ProxyPass http://127.0.0.1:8080/
<indu> and         ProxyPassReverse http://127.0.0.1:8080/
<mwhudson> yez
<indu> this is showing an outout in web browser as,
<indu> mwhudson, are messages receievd by the channel
<mwhudson> indu: i only saw
<mwhudson> <indu> this is showing an outout in web browser as,
<indu> mwhudson, /boss/ not found
<indu> mwhudson, 404 Not Found
<indu> The path '/boss/' was not found.
<mwhudson> well, that suggests that the apache config is wrong somehow
<mwhudson> i'm no expert in apache, unfortunately :/
<indu> mwhudson, ok, then help in loggerhead ?
<fullermd> error log might say something.
<indu> fullermd, the apache log is saying, [Wed Jan 02 15:03:35 2008] [error] [client 127.0.0.1] client denied by server configuration: proxy:http://127.0.0.1:8080/
<mwhudson> oh
<mwhudson> maybe you need an "allow from all" in there
<indu> lemme try
<indu> mwhudson, same o/p, but log file content is not the same
<indu> now the log shows. nothing on the failure
<indu> mwhudson, how to configure loggerhead
<mwhudson> take the loggerhead.conf file in the branch and change the bits that are relevant to your situation
<indu> mwhudson, deos loggerhead have any relation with apache?
<indu> mwhudson,  the port number of loggerhead, should be different of that of apache or same ?
<mwhudson> it is common to use apache in front of loggerhead
<mwhudson> so that the user's browser talks to apache, and apache talks to loggerhead
<mwhudson> so loggerhead should use the port number you put in the ProxyPass directive
<indu> mwhudson, i just typed, localhost:8080, in my browser and it showing an output as
<indu> mwhudson, Bazaar branches in loggerhead, (which is the description in loggerhead.conf file) and under that the bazaar and loggerhead logos
<mwhudson> well, that sounds good
<indu> mwhudson, oops, i have mistaken, the line  "Bazaar Branches in Loggerhead " is not in my loggerhead.conf file
<indu> mwhudson, its displayed frm somewhere else
<mwhudson> oh, then maybe you're not using the loggerhead.conf file you think you are?
<indu> exaclty :)
<indu> mwhudson, ok now i corrected
<indu> mwhudson, what should be the values for [xxx] and [[xxx]]
<mwhudson> indu: what ever you like, they are just names
<indu> mwhudson, then where does i give the repo path ?
<mwhudson> as the folder = '..' value inside the [[xxx]] section
<indu> mwhudson, can you give me an example, of any site, which used loggerhead as the fron t end, as i want to see how does it look
<indu> mwhudson, is it needed that for each branch created there should be an entry in the loggerhean.conf file
<indu> mwhudson, and this loggerhead is not dependent on apache, as even after stopping the apache web server I am able to see the loggerhead page in the browser
<lifeless> 09:28 < lifeless> mwhudson: consider relative urls for codebrowse, kthxsavebybandwidth
<lifeless> 09:29 < lifeless> e.g. consider http://codebrowse.launchpad.net/~lifeless/squid/squid3-trunk/files/cvs-1%3Ahno-20071220081046-d59dmpbuvvyioekf?file_id=src-19960222132353-t43j7l5jst5z-28
<mwhudson> lifeless: there's a bug report for that already
<lifeless> mwhudson: kk
 * mwhudson feels like he is not, in fact, over his cold
<lifeless> :(
<indu> mwhudson, starting loggerhead is starting succesfully, but when I am browsing , the following message appears on the terminal as the traceback
<indu> mwhudson,  http://rafb.net/p/PDM8p311.html
<mwhudson> indu: do you have more than one loggerhead process running?
<indu> mwhudson, i check the output of ps -A, i dint find any
<indu> mwhudson, how can i check
<mwhudson> that's what i'd have used
<indu> mwhudson, now got it.
<indu> mwhudson, tell me onw more please, do i need to mention for every new branch i create under my repo, in the loggerhead.conf file?
<mwhudson> indu: no, there's some kind of "auto folders" thing
<mwhudson> indu: but i've never used it, so i don't know how it works
<indu> mwhudson, i am trying to use the same but its not fruitful
<indu> mwhudson, i am trying
<lifeless> mwhudson: let me know what I need to do to help you with my bug report; needless to say this is rather important to get squid to migrate ;)
<mwhudson> lifeless: well, my approach would be to do print-based debugging to try to see where the '/' is coming from
<indu> mwhudson, yes wuto_publish worked for me
<indu> mwhudson,  i am seeing something surprising here,
<indu> mwhudson,  i have a repo, boss-repo, created using bzr init-repo
<indu> and under that i created i initiated a branch using bzr init a
<indu> and under a/ , bzr init axyz
<indu> I am seeing in this loggerhead auto_publish_folder, the a, and axyz under the same tree, but not like, axyz under the a/ directory
<mwhudson> well, (a) don't put branches in branches (b) auto_publish probably isn't recursive
 * fullermd weeps over log -v speed/memory.
<mwhudson> lifeless: browsing squid will loggerhead seems to work fine here :/
<mwhudson> lifeless: although, the [logging] section in your config isn't doing what you probably think it is...
<lifeless> mwhudson: I have no idea whats doing what; its undocumented voodoo as far as I can tell without reading code.
<lifeless> mwhudson: I can reproduce this (obviously). The get_history is being given a path or something of None
<mwhudson> lifeless: my voodoo + painkillers suggestion is to remove the [logging] section
<lifeless> mwhudson: it may be a version of turbogears thing. had TERRIBLE trouble installing it
<mwhudson> lifeless: i have a not-so secret plan to get rid of the turbogears dependency
<lifeless> as its not documented to need a specific version I ended up with the latest stuff
<mwhudson> well, tg should be able to interfere at this level (i would hope)
<mwhudson> should NOT
 * mwhudson really needs to get away from the computer
<lifeless> seems to be constructing a branchview with garbage parameters
<lifeless> night all
<lifeless> mwhudson: I could waste a lot of time learning loggerhead as a once off.
<lifeless> mwhudson: I'd like instead to get you to directly look at the problem if thats possible.
<mwhudson> lifeless: well, unless i can reproduce it, how can i
<mwhudson> ?
<lifeless> mwhudson: ssh to the box that its failing on ?
<mwhudson> lifeless: that could work
<lifeless> I'll ask for an account for you. mwhudson as the name ?
<mwhudson> lifeless: mwh would be preferable
<mwhudson> my key is on lp
<lifeless> url for it please
<mwhudson> https://edge.launchpad.net/~mwhudson/+sshkeys
<lifeless> mwhudson: in my homedir, ~loggerhead has the checked out copy, and I'm turning it off so you can run up your own if you get an account overnight
<mwhudson> lifeless: will i get an email if i get an account?
<lifeless> mwhudson: I've included your canonical address in the mail; I expect courtesy would have them inform you
<mwhudson> ok, thanks
<lifeless> you'll need to copy it to your home dir to play with, naturally.
<Stavros> can someone help me with bzr-svn? it won't check out my branch :/
<Stavros> "Unsupported protocol"
<indu> mwhudson, still i am facing problem with my bazaar with apache configuration
<Stavros> bzr-svn, anyone?
<jelmer> hi Stavros
<Stavros> hi
<jelmer> Stavros: What version of bzr-svn are you using and what platform are you running it on?
<Stavros> i am using the latest one on a mac
<Stavros> but i got errors with it in linux as well, where i had to delete its config file to make it browse the server correctly
<jelmer> Stavros: If it's http or https that's failing, the build of python-subversion you are using is probably not built with http/https support
<Stavros> i am trying svn+http... hmm
<Stavros> i'll get another one, then
<jelmer> Stavros: What errors did you get on linux?
<Stavros> invalid branch type, i think. it was looking in the config and seeing another URL for the same server and refused to checkout the one i wanted
<dlee> Where do I go for the svn trunk I need for bzr-svn to work?  I run svn and bzr under Windows+Cygwin in case that matters.
<jelmer> dlee: There are no prebuilt packages for cygwin afaik
<Stavros> well, i installed the python-subversion bindings from tigris and it still doesn't work :/
<jelmer> Stavros: There are prebuilt packages of Subversion 1.5?
<Stavros> apparently, http://pysvn.tigris.org/project_downloads.html
<jelmer> dlee: So your best bet would be to build Subversion from source, trunk can be obtained through subversion itself
<jelmer> Stavros: You need python-subversion, not pysvn
<Stavros> damn
<jelmer> Stavros: that's a completely different project
<Stavros> ah
<Stavros> do you know the webpage? google doesn't turn up anything official-sounding
<jelmer> Stavros: http://subversion.tigris.org
<Stavros> oh
<dlee> My Cygwin includes svn 1.4.5.  I know that's not enough, but I think it came from a package.  Hmm... guess I need to find the svn source and see what happens. I'll look in Cygwin setup first though to see if there's a devel version of svn.
<jelmer> Stavros: However, there are no binary packages for Subversion 1.5 yet afaik
<Stavros> jelmer: for the mac?
<Stavros> i'm confused :/ don't i just need the svn bindings?
<jelmer> Stavros: Yes, you need just the svn bindings
<Stavros> can't i use pre-1.5 ones?
<jelmer> no, you need 1.5 (or patch the 1.4 ones)
<Stavros> ah
<jelmer> there were some people on the Bazaar mailing list trying to build a package of 1.5, but I don't think that's done yet
<Stavros> hmm
<Stavros> how did it work on linux?
<jelmer> Most distributions ship with patched versions of Subversion 1.4
<Stavros> ah
<Stavros> hm
<Stavros> i should just install linux on this thing
<Stavros> ah never mind, i'll just do it on the server and pull
<Stavros> any idea why branching over ssl doesn't work on the mac?
<Stavros> nm, got it
<mtaylor> jelmer: good morning... I have a bzr-svn problem :)
<jelmer> hey mtaylor
<mtaylor> jelmer: I was doing an svn-import, and it ran for hours (big repos)
<mtaylor> and I got this:
<mtaylor> NoSuchId: The file id "7924@3c33494c-61f7-0310-86b9-b90697347e9d:branches%2Fdevelopment-2.0:server%2Fmerlin%2FWEB-INF%2Fsrc%2Fcom%2Fmysql%2Fetools%2Fscratch" is not present in the tree <Inventory
<mtaylor> this is using (I think) the latest bzr-svn
<jelmer> latest as in 0.4 branch?
<mtaylor> but I'm happy to upgrade if I'm using an old version by mistake
<mtaylor> I think so... lemme check
<jelmer> is this repository public?
<mtaylor> jelmer: no, unfortunately
<mtaylor> jelmer: should I bother reporting a bug with the whole traceback? or is it useless without a repos to look at?
<jelmer> mtaylor, please file a bug. the traceback may be useful
<mtaylor> jelmer: k. will do.
<jelmer> at the very least, it's an indication there's still a bug left in the pull code
<mtaylor> jelmer: the traceback seems to include a dictionary of the entire repos or something... is that important?
<mtaylor> (it's big)
<jelmer> it may be useful, if it doesn't contain any sensitive information
<mtaylor> no. I just wanted to make sure before I bothered pasting it all in
<mgedmin> can I get the bzr log for a subdirectory?
<mgedmin> bzr log dir only shows those revisions that actually changed dir, but not those that changed files inside it
<mgedmin> I fail to find any --recursive options
<mgedmin> is this use case not supported?
<dato> mgedmin: it doesn't work at the moment, and I *believe* there is an open bug about it
<mgedmin> https://bugs.launchpad.net/bzr/+bug/97715
<ubotu> Launchpad bug 97715 in bzr "bzr log DIR should show changes under dir" [Undecided,New]
<mgedmin> what's the bzr-speak for "please update this working dir to the state it was in revision X" (in svn: svn up -r X)
<mgedmin> ?
<dato> mgedmin: bzr revert -r X
<mgedmin> revert sounds scary
<mgedmin> can I then revert back to the latest version?
<mtaylor> jelmer: so once I've gotten that error... is there any way to recover my repos? or am I just screwed for the moment
<jelmer> mtaylor: recover in what sense? continue the import ?
<mtaylor> jelmer: yes... or be able to use it in any way
<jelmer> continuing the import is impossible until we fix the bug that causes bzr-svn to barf
<mtaylor> ah
<mtaylor> ok
<dato> mgedmin: yes
<mgedmin> thanks
<lifeless> moin
<dlee> Do we have an easy way to add the commits from one bzr project to another existing bzr project?  If so, does it matter whether or not the first project's commit dates intersect those of the one being added to it?
<lifeless> what do you mean 'add' ?
<LeoNerd> Hrm... apt-get update is throwing me:
<LeoNerd> Failed to fetch http://bazaar-vcs.org/releases/debs/feisty/./Packages.gz  MD5Sum mismatch
<LeoNerd> Anyone any ideas?
<lifeless> possibly someone is rsyncing right now (I'm not)
<lifeless> alternatively you got one file partly downloaded and stuck in a proxy cache or some such
<LeoNerd> I've been getting it every day for the last two weeks... Don't think it's just a transient thing
<lifeless> release.gpg hasn't been updated
<lifeless> but packages.gz has been
<lifeless> I have some code to write, but I'll do adminny things this evening
<LeoNerd> OK
<ubotu> New bug: #179927 in bzr "bzr help formats line-breaks inside urls" [Undecided,New] https://launchpad.net/bugs/179927
<paulproteus> I hope that git lets me fulfill the dream of using distributed version control without also making me hate my life.
<paulproteus> Er, I mean bzr.
<paulproteus> Git is failing at letting me live that dream.
<fullermd> To dreeeeeeeeam, the impossible dreeeeeeeeam...
<igc> morning
 * fullermd waves to igc.
<igc> hi fullermd - just looking at that bug now
<igc> it was me
 * fullermd nods.
<thumper> morning igc
<igc> morning thumper
<fullermd> Just making sure you saw it, in the flood of messages I guess you're all dealing with after deserting us for a few weeks   :)
<dato> revert not making backups of something is always a bug, right?
<LarstiQ> dato: not if there is no information lost
<dato> yeah, that's what I meant
<lifeless> vila: remember what bug # spiv had where squid was involved ?
<vila> #172701 ?
<vila> bug #172701
<ubotu> Launchpad bug 172701 in bzr "Large readv requests can fail if there is a squid proxy" [High,Fix released] https://launchpad.net/bugs/172701
<ubotu> New bug: #179953 in bzr "revert after pull of a revision that removes a file looses wt	changes to that file" [Undecided,New] https://launchpad.net/bugs/179953
<dato> LarstiQ: ^
<lifeless> vila: thanks
<lifeless> vila: got someone seeing similar symptoms with 1.0
<vila> lifeless: similar like issuing single range requests ? Because I fix another cause for that (see BB about bug #179368)
<ubotu> Launchpad bug 179368 in bzr "bug in lighttpd 1.4.18 makes bzr loop or issue too many requests" [Medium,Fix committed] https://launchpad.net/bugs/179368
<lifeless> vila: interesting
<lifeless> he's offline now, I'll drop him a mail
<dato> lifeless: hey, regarding that packaging thread, I only thought it'd be nice to say how things looked on this side of things, wasn't the intention to come and blab about how you should be doing your stuff.
<lifeless> dato: no worries
<lifeless> I've been on leave; I'll be doing mail stuff this evening
<dato> very well
<Keybuk> if I have "trunk" in my working directory, and the URL of someone else's branch with some changes in it, how do I compare the two?
<Peng> Keybuk: "bzr missing $URL".
<Keybuk> Peng: doesn't show the differences
<Keybuk> (just the revision info)
<Peng> Keybuk: Oh, you want to see diffs too?
<Keybuk> yeah
<Kinnison> bzr diff branch:someurl..-1
<Kinnison> ?
<Keybuk> Kinnison: ERROR: Path(s) are not versioned
<Kinnison> :-(
<fullermd> Er.  -rbran[....]
<Kinnison> good point
<fullermd> It helps   :)
<Keybuk> why doesn't just "bzr diff URL" work?
<Kinnison> or bzr diff --old . --new http://blahblahblah
<Kinnison> Keybuk: because that means bzr diff <file called http://blahblahblah>
<Keybuk> Kinnison: no such args
<Kinnison> does bzr help diff show them?
<Keybuk> Kinnison: but I *can* do "bzr diff ../OTHERBRANCH"
<Keybuk> so why doesn't URL work there?
<Kinnison> not a clue
<Keybuk> bug I suspect
<Kinnison> file it then I guess :-(
 * Kinnison is sorry he can't help
<fullermd> Heck, --old isn't even in my slightly-outdated bzr.dev...
<fullermd> bzr diff ../OTHERBRANCH probably isn't doing what you think it is...
<Keybuk> it gives me exactly what I think I should get
<fullermd> URL "works", it just doesn't mean much of anything.
<Peng> Oh yay. This autopack was smart enough to leave the 200 MB, 100 MB and 70 MB packs and repack the rest.
<Keybuk> why does diff against the checkout of the URL work when local but not remote?
<fullermd> bzr diff ../OTHERBRANCH does the same thing as (cd ../OTHERBRANCH ; bzr diff)
<fullermd> It doesn't compare OTHERBRANCH against $PWD.
<Keybuk> bzr diff . ../OTHERBRANCH
<Keybuk> that says in the help that it compares the two
<Keybuk>     Show the differences between the two working trees:
<Keybuk>         bzr diff bzr.mine bzr.dev
<fullermd> That does, yes.
<Keybuk> sorry, just a typo above
<Keybuk> bzr diff . URL doesn't work
<fullermd> You need to use the branch: revspec for full URL's to remote branches.
<Keybuk> why?
<Keybuk> if a path works, so should a URL
<Keybuk> otherwise that's just stupid
<Kinnison> presumably because noone has thought to add that
<fullermd> Ambiguity resolution, probably.
<Kinnison> if the branch: revspec works, then file a bug to suggest it try urlparse as a fallback?
<hmeland> Keybuk: In bzr.dev, the "bzr diff bzr.mine bzr.dev" is no longer allowed, you have to do "bzr diff --old bzr.mine --new bzr.dev"; I think this change was done to disambiguate trees/branches from files/directories within a tree/branch.
<ubotu> New bug: #179972 in bzr "bzr diff URL doesn't work, but bzr diff /path/to/branch does" [Undecided,New] https://launchpad.net/bugs/179972
<hmeland> ... and with bzr.dev, e.g. "cd mytree; bzr diff --old URL" works nicely, AFAICT.
<abentley> Keybuk: Which version of bzr are you using?
#bzr 2008-01-03
<Keybuk> 1.0.0
<mindstorms> hi all and happy new year (to those celebrating it)
<mindstorms> somebody mentioned a couple of weeks ago that he is working on creating a patched svn version
<mindstorms> and a smarter install for Mac
<mindstorms> any news on this? (I know there is a distro for 10.5, but the discussion was to make it available for Mac 10.4 too)
<abentley> Keybuk: So in 1.0, the reason why it didn't support remote urls was that it always used working trees.
<abentley> However, local URLs should work just fine.
<abentley> In bzr.dev, diff has been reworked significantly, and now uses the last-committed-tree for remote URLs and for branches without trees.
<zekel> Anyone know how to get svn style status? There seems to be a short keyword arg to status.show_tree_status that does what I want, but I'm having trouble getting started with the api. I'm not really sure if I want to be writing a script to filter the bzr output, call status from within, or make a plugin that is called by normal bzr st. Can someone point me in the right direction?
<jelmer> zekel: bzr st -S ?
<jelmer> what sort of thing you would want to use really depends on what you're trying to write
<zekel> Oh, I guess I got confused. What I really want is the paths outputted to be relative to the cwd, and I took that to be the svn thing.
<jelmer> and in what lnaguage
<zekel> I was thinking python.
<jelmer> ah, ok. I don't think there's a way to report paths relative to the cwd yet
<jelmer> but I may be wrong
<zekel> I think I asked if there was a builtin way and was told no, not yet. I find that I don't check in stuff as much if the paths are long, which is really bad.
<zekel> I could do something with sed, but I thought I'd try to do it from within python instead.
<zekel> I think what I need is to know the correct way to get a working tree object, so that I can call a status method, which I can then mess with.
<lifeless> uhm
<lifeless> just write a replacement formatter?
<zekel> That sounds like a great idea. I should look at the normal one and make my changes?
<lifeless> it may not be fully pluggable right now; a good place to start looking is bzrlib.status
<zekel> That's why I'm thinking it might just be a better idea to have a filter script to pipe it through.
<lifeless> perhaps
<lifeless> we do like making things pluggable though :)
<zekel> I can't say I'm an expert, so hacking bzrlib vs. filter script might be the difference between impossible and doable.
<zekel> At least based on trying to read it.
<lifeless> zekel: ah
<lifeless> zekel: well, let me have a quick check
<lifeless> look for 'if short:' in status.py
<lifeless> see _mod_delta._ChangeReporter
<lifeless> thats the interface you can use to write a new reporter
<Peng> What exactly are rich roots?
<lifeless> you can subclass that too
<lifeless> and hardcode in a new class in status.py for now
<lifeless> Peng: versioned '/'
<Peng> What does that gain?
<lifeless> bzr split; bzr join
<Peng> How do rich roots help that? What information about directories is there?
<lifeless> last-change and file-id
<lifeless> (and children obviously)
<Peng> Ok.
<Peng> I still don't get it.
<lifeless> it stops new files in the root of the project you joined being merged to the root of the combined tree, rather than the correct child node
<lifeless> say you have project A: [/]  and B: [/, /README]
<lifeless> if you join B to A at subproject you get:
<lifeless> A': [/, /subproject, /subproject/README]
<lifeless> if you commit to B a new file 'configure'
<lifeless> then merge B' to A' you want:
<lifeless> A'':[/, /subproject, /subproject/configure, /subproject/README]
<lifeless> this requires you to know that B''s '/' is A's '/subproject'.
<lifeless> if B's / has no file-id then you can't tell that.
<Peng> Ok.
<Peng> That could be inferred, but I guess it would require rewriting history a bit?
<Peng> Or, I dunno.
<Peng> It sounds really easy to infer that when the merge is done, but I guess it doesn't map well to being stored?
<lifeless> the only thing available to infer this is the presence of README
<lifeless> or a deep history search
<lifeless> the first fails if there is also another file, say AUTHORS, that became /AUTHORS rather than /subproject/AUTHORS
<lifeless> though it is arguable at that point that a conflict should be raised (but you should still be clear about the options)
<lifeless> and deep history searches are generally bad things to do
<lifeless> because they break when you deliberately truncate history (e.g. partial branches because you don't want the deep history for now)
<fullermd> Is there some reason other than backward compat not to go rich-root by default?
<fullermd> It seems like most of the dangerous/surprising bits are segregated in the -subtree variant now.
<lifeless> dunno; I'll think about that later. Coding now. Tchau. :)
<fullermd> Better choice   :)
<lifeless> abentley: if you are pro the experimental format approach I put forward, consider a review :).
<pfharlock> This is probably asked allot, but, I created a bzr branch and then tried to merge in something from a subversion repository and just can't seem to figure out how to get it to work.  I have successfully branched a svn repo into a non-pre-existing bzr branch, but I was hoping to create a bzr repo and selectively merge in svn branches.  I'm using the svn-bzr plugin.  Any thoughts? Is what I'm trying to do even possible?  I can give any det
<pfharlock> ails that may be of help.
<lifeless> well, an error message would be a good start :)
<pfharlock> ok
<pfharlock> one sec
 * fullermd presumes it'll be a repo format issue.
<pfharlock> yes, that seems to be the case, here is the lead up
<pfharlock> bzr init
<pfharlock> bzr merge svn+file:///home/pfharlock/arc/subversion/snippets
<pfharlock> bzr: ERROR: Repository KnitPackRepository('file:///home/pfharlock/test/.bzr/repository/') is not compatible with repository SvnRepository('file:///home/pfharlock/arc/subversion')
<lifeless> upgrade --pack-0.92-rich-root I think is what you need
<fullermd> Yeah.  You'll need....   mmm...   at least one of the rich-root formats, and maybe the -subtree one.  Not sure how far bzr-svn pushes you currently.
<Peng> --rich-root-pack
<Peng> (no 0.92?)
<pfharlock> ok, thanks for the advice, I'll try that, I'm on bzr 1.0
<Peng> bzr-svn is supposed to work with the rich-root formats.
<pfharlock> just out of curiosity, why does the rich root format help?
<lifeless> it adds metadata svn exports need to do the right thing with some of the copy-to-make-branch operations
<pfharlock> yeah, that seemed to have worked, thankyou very much, will the rich root formats eventually become the default in bzr?
<lifeless> yes
 * igc lunch
<pfharlock> one more silly question, if you create a rich root format branch or repo, can you merge from it into a standard default knitpack or is it simply not backwards compatible that way?
<abentley> pfharlock: It is not compatible for the same reason SvnRepository isn't compatible.  There is data in "rich-root" formats that pack-0.92 cannot represent.
<pfharlock> I see, thanks again for the help, it's really appreciated.
<spiv> abentley: you replied to me, rather than the list
<abentley> Oh, thanks.
<spiv> abentley: I guess my habitual "group reply" in mutt that does "To: you / Cc: the list" breaks in combination with your reply habits?
<abentley> I blame New Year's celebrations :-P
<spiv> Heh.
<abentley> I usually use "reply all", but I've recently changed my email address, so I've been a bit out of sorts.
<abentley> spiv: Does that subtract_plans docstring look helpful?
<spiv> abentley: very!
<abentley> Oh, great.
<abentley> I'm just applying your tweaks now.
<igc> night all
<mwhudson> lifeless: still here?
<lifeless> fsvo here
<lifeless> dinner is ready in 2 min
<mwhudson> i was fighting getting tg installed on squid-cache
<mwhudson> but now i'm on the phone to thumper
<lifeless> tg is installed system wide
<mwhudson> it is?
<mwhudson> maybe i'm running things with the wrong python...
<lifeless> 2.5
<mwhudson> ah yeah
<mwhudson> lifeless: you're definitely special: http://www.squid-cache.org/bzrview/squid3/trunk/changes
<mathrick> is there a plugin to support individual hunks commits, darcs style?
<lifeless> mwhudson: did you put anything in a per-user python dir or something ?
<lifeless> mwhudson: and how are you starting it ?
<mwhudson> lifeless: "python2.5 ./start-loggerhead.py -f"
<mathrick> how come the release notes (and actually releases thmeselves as well) are so irregularly linked from http://bazaar-vcs.org/news ?
<mathrick> doesn't that happen automatically?
<mathrick> urgh, for some reason "bzr branch http://michael.ellerman.id.au/bzr/plugins/diffstat/" takes about 2 minutes and heaps of bandwidth
<mathrick> for all of 11 revisions
<mathrick> even a simple bzr ls takes 20s
<Peng> The remote repository contains a lot more.
<Peng> (Probably a copy of bzr's branch.)
<lifeless> mwhudson: I was using 'python start-loggerhead.py'
<lifeless> Peng: bet that teh remote repository is knits ;)
<Peng> lifeless: It is.
<lifeless> mathrick: thats an old format repository
<mathrick> ah
<lifeless> night all
<Peng> I wouldn't call it old, just not new.
<Peng> G'night.
<mwhudson> lifeless: ah ha
<mwhudson> why the fuck does that make a difference
<mathrick> Peng: it's slow enough to be old :)
<mwhudson> lifeless: as predicted, though i'm not sure why, deleting the [logging] section of the config seems to help
<mathrick> garh, how can I debug WHY a plugin can't be loaded?
<mathrick> ie. get whatever error makes it so
<Kinnison> Can someone point me at the docs for what a Text conflict is, vs. a Contents conflict?
<mathrick> Kinnison: http://doc.bazaar-vcs.org/bzr.1.0/en/user-guide/index.html#conflicts-types
<Kinnison> thanks
<Kinnison> Contents conflict in vl.h
 * Kinnison thinks bzr misclassified that file
<Kinnison> mmm or perhaps not
<Kinnison> urgh
<Kinnison> I think upstream deleted that file
<Kinnison> pants
<Kinnison> thanks
<Kinnison> I hate qemu
<mwhudson> mathrick: look in ~/.bzr.log
<mathrick> mwhudson: aha, thanks
<indu> how can i work out with trunk and branch methodology
<mathrick> indu: eh?
<mathrick> what do you mean?
<indu> is there a specific way that a version control system should follow for publishing the source, to the community
<indu> mathrick, i just started maintaining a version control system for my project, prev i had used svn
<indu> now i am trying to shift to bzr which has much more better features
<mathrick> indu: aha, there's no One True Way
<indu> but I am confused how to organise it
<mathrick> there are many ways, depending on what your project needs
<indu> mathrick, my project has different releases, named as sethu, tarang, and anant
<mathrick> indu: how big is it? How many core developers do you have? Is it open source? Proprietary? Proprietary with external contributors?
<indu> its an opensource
<indu> mathrick, and in future i will have some more release,
<indu> thus, if I consider each as seperate repo, and then upload my souce as branches ( each repo has more than one branch)
<mathrick> indu: what are those releases? Are they versions, or separate codebases? Do you need to maintain each independently, or does one release make others obsolete?
<indu> mathrick, they are not versions, they are different releases
<mathrick> but what is a release?
<mathrick> are they separate programmes?
<indu> mathrick, i am working on a linux distribution,
<indu> based on debian
<mathrick> okay?
<indu> and to maintain its source i am trying this
<indu> you can have a look at http://packages.bosslinux.in/boss/pool/
<indu> where there are three releases, and under each there is a main folder, and the source under that folder only need to be made version controlled
<mathrick> aha, so they are effectively versions, except that they bundle a lot of things together each
<mathrick> indu: is the source you want versioned related between releases (I assume yes)?
<indu> no its not versined between releases,
<indu> the source is independent for all the releases
<mathrick> okay
<mathrick> indu: so as far as you're concerned, sethu and tarang have no relationship at all?
<indu> mathrick, yes
<indu> mathrick, they are just under the project of our linux distro, but internally they are not related
<mathrick> indu: then it makes sense to set up a separate repo for each of them
<mathrick> indu: what is the structure of your team? Do you have any external contributors? How many internal ones do you have?
<indu> internal are 15, and external may extend to 100
<indu> or more than that
<mathrick> okay, so you might want to set up a PQM for the internal ones, and pull from independent repos for external ones, if they are less active than internals. Otherwise you could grant access for the active external ones as well
<mathrick> PQM lets you set up things such as buildbots and automated testsuites easily
<indu> what is PQM ? first time i am hearing this terminalogy
<indu> mathrick, mathrick, one more thing, i also need a good gui for the users to easily view the structure so that they can download the source, if i use loggerhead, then each repo appears extended by default and thus my page in browser looks very big with sethu (80 branches under it) lll'ly tarang and anant
<mathrick> indu: https://launchpad.net/pqm http://bazaar-vcs.org/Workflows
<mathrick> indu: a lot is explained in http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html and http://bazaar-vcs.org/BzrPlugins
<mathrick> including GUIs
<mathrick> unrelated, could someone review this patch: http://pastebin.com/m22468f01
<mathrick> is this the right thing to remove diff_cmd_helper?
<indu> mathrick, ok i will have a look at those docs,
<mathrick> it irks me somewhat I had to recreate spec_tree() from it
<indu> mathrick, one more small doubt
<indu> mathrick, i am unable to configure bazaar with apache
<indu> do u have idea on it?
<mathrick> indu: I don't know what you mean by configuring bazaar with apache, so no
<mathrick> and I have no idea about anything that involves the two together, so I'm unlikely to help
<indu> mathrick, ok. thanks for the help provided
<mathrick> no problem
<mathrick> any comments on the patch?
<Peng> mathrick: What's that a patch too? Also, use bundles (bzr send -o foo.patch) when submitting patches so your commits won't be lost.
<mathrick> Peng: it's for diffstat plugin
<Peng> mathrick: Oh.
<mathrick> and I know about bundles, I just wanted someone to look at the code
<Peng> Ok.
<Peng> I don't know anything, so I have no comment on the code.
<mathrick> ok
<mathrick> ah, right, I've fixed a buglet since I pasted it
<indu> mathrick, i want to use http protocol, for publishing the content
<indu> mathrick, that can be done by configuring apache web server for bazaar, is it right? or any other way is available
<mathrick> indu: then you just publish the directories, bzr repos are simple directories on disk
<mathrick> there's no configuring of apache for bazaar
<mathrick> indu: unless you mean a sophisticated repo viewer, a'la loggerhead
<indu> mathrick, yes, my problem is solved now, many thanx
<indu> could some one tell me, what this message mean http://rafb.net/p/yfdEH296.html
<soren> indu: You can't push over http.
<indu> I soren branch on http worked
<soren> Yes?
<soren> That's a read only operation.
<soren> push means that you want to send you changes somewhere. You can't do that over http.
<indu> soren, ok fine
<indu> soren, then i changed my command to bzr push /usr/local/boss-bazaar/Anant
<indu> and the o/p was created one branch, but where does it create? since its not available under /usr/local
<indu> under /usr/local/boss-bazaar/Anant
<soren> o/p ?
<indu> o/p = output
<soren> "the output was created one branch"? I don't understand, I'm afraid.
<indu> in svn, to create a new project repo, we using svn import command to add files to the repository
<indu> but its not possible in bzzr
<soren> Ok, now I'm seriously confused.
<soren> What is your question?
<soren> If you want to start to use bzr, you issue "bzr init", add your files, bzr add them, and bzr commit them.
<Peng> (Even better, you convert from your svn repo so you don't lose your history...)
<dlee> Indu:  When you bzr push, bzr get, etc., yes, you get one "branch" (the term "branch" has slightly different meanings in svn and bzr though, and I'm temporarily blurring the distinction).  The "output" will go where you told it to; for example, "bzr push /usr/local/out" would create a directory called /usr/local/out and under it /usr/local/out/.bzr, in which the data for the branch would go.  I'm not sure how much I'm helping here, but I 
<mathrick> pack-0.92 is the latest-and-fastest format?
<dlee> Latest non-experimental format yes.  I'll let someone else tackle the "fastest" part.  There's a newer format, but I understand it's still experimental.
<Peng> mathrick: Yes. It's a lot slower for operations that read the entire history (like log) though (which is being worked on). Also, older formats cache all of the information "bzr annotate" uses, but packs don't, so that's slower too. (There's going to be an annotation cache in the future.)
<mathrick> okay, I was playing with a simple benchmark, and it seems that bzr rm on new files is pathologically slow
<mathrick> I'm doing it on ~30K newly added files
<Peng> mathrick: (On the flipside, operations that only read part of the history are much faster. So is dumb server network access. It also makes read-write dumb servers easier because files are not modified, only added and deleted.)
<Peng> mathrick: Nice.
<mathrick> and it has runtime at least 3m
<Peng> Crapcrapcrap.
 * Peng notes that running 'touch' 30,000 times isn't very fast either.
<Peng> Crapcrapcrap. Ran it in the wrong directory.
 * Peng kills it after 17,000 files.
<mathrick> Peng: dunno, git can add all of them in 2s :)
<dato> % seq -f %g.txt 30000 | =time -p xargs touch
<dato> real 2.08
<dato> Peng: ^
<dato> Peng: the trick is not starting a new touch process per file ;)
<mathrick> what's =?
<mathrick> is that csh or some other abomination?
<dato> zsh
<dato> =time -> /usr/bin/time; I use in order not to use the shell builtin time, which I don't like
<mathrick> oh
<mathrick> someone should tell /usr/bin/time about spaces
<Peng> dato: I know.
<dato> mathrick: I like it with -p better
<mathrick> bzr rm still running...
 * Peng blows up his file manager moving all of the files with python.
<mathrick> dato: ah, that's basically what bash's builtin time does :)
<dato> ah, oh :)
<Peng> I've been meaning to check out zsh instead of bash.
<Peng> Sigh.
<mathrick> guess what, it's still running
<Peng> I think I really did freeze my file manager.
<mwhudson> command-not-found --> bash wins
<mathrick> God, I hope it has runtime <= 30 mins
<Peng> Oh nice.
<mathrick> I might add it pegs the CPU while it's running, too
<Peng> ps says it's using 0.1% of the CPU. top says it's using 99.9%.
<mathrick> so there's definitely something wrong going on
<Peng> mathrick: Don't kill it! It's running Folding@home!
<mathrick> Peng: more like Removing@tmp
<Peng> That still helps solve cancer, right?
<mathrick> I don't think it does
<Peng> Hopefully Konqueror will be faster than bzr.
<mathrick> heh
<Peng> Craap.
<mathrick> Peng: y'know, if it does something exponential, it probably won't finish within my lifetime
<mathrick> even just O(n^2) is pretty bad on n = 30K
<Peng> Yay, Konqueror is done!
<mathrick> okay, 20 mins, I'll kill it now
<mathrick> okay, I've tracked the problem
<mathrick> it's collecting the info about files
<mathrick> since all are new and can't be safely removed, "bzr rm" will error out
<mathrick> and some kind of info it's gathering there is taking forever
<mathrick> if I add --keep, it's fast
<mathrick> no --keep == exponential
<statik> is it possible to create my own location aliases similar to the lp: prefix for branches? so that instead of always getting a new branch by typing 'bzr branch bzr+ssh://foo.host.com/code/branchname' I could just type 'bzr branch me:branchname ?
<dlee> Statik: The Bookmarks plugin might be what you want:  bzr branch bm:branchname should become possible with that.
<statik> dlee: cool, thanks!
<CardinalFang> Is this the right place to talk about bzr-gtk?
<CardinalFang> I use the per-file commit comments, so there can be a lot of data.  I wish that there were a "cancel, but retain comments" option in "bzr gcommit".  Also, if I just "bzr uncommit", it would be nice if the previous comments were default in the UI for the next commit.
<schierbeck> CardinalFang: yeah, this is the place
<schierbeck> I'm not quite sure I follow -- you want to cancel the commit, but still retain the per-file commit messages for the next commit?
<schierbeck> I guess it's possible, although we'd need to store the messages somewhere.
<CardinalFang> schierbeck, Yes, that's what I meant.  And when we uncommit, store those messages in the same place also.
<Peng> When you uncommit, the revision is not removed from the repository. You could store the revision ID somewhere and use it to get the message.
<CardinalFang> Ah, good to know.
<schierbeck> Peng: yeah, we could do that... but to be honest, this stuff should go into bzr itself, or maybe a plugin
<schierbeck> It's a somewhat different work model
<schierbeck> Writing per-file messages on the fly, and then committing after a while
<schierbeck> But yeah, a temporary solution would be to store the revision id, and clean it up after a completed commit
<schierbeck> I'll have a look at it now
<CardinalFang> schierbeck, I think we should capture the global commit message also.  All the state of gcommit saved and reloaded.
<schierbeck> CardinalFang: yeah, but I think the easiest way to get started is to restore the commit messages after an uncommit
<schierbeck> later on I'll figure out how best to do it with cancelled commits -- perhaps write them to the repository anyway, and save the revid
<schierbeck> Holy crap
<schierbeck> I've never looked inside commit.py before
<schierbeck> We actually implement just about everything ourselves
<schierbeck> That stuff really needs to be moved to bzrlib
<schierbeck> CardinalFang: this'll need more work than I anticipated... could I get you to file a bug report? That way it'll be easier to keep track of the issues
<CardinalFang> schierbeck, Sure.
<schierbeck> Thanks
<CardinalFang> No, thank you.
<schierbeck> :)
<ubotu> New bug: #180107 in bzr "`bzr ls` should gain --modified and --added?" [Undecided,New] https://launchpad.net/bugs/180107
<mathrick> my bash completion for bzr broke :(
<ubotu> New bug: #180109 in bzr "gcommit should load default comments (from "bzr uncommit" and UI button "cancel but retain")" [Undecided,New] https://launchpad.net/bugs/180109
<CardinalFang> schierbeck, ^
<schierbeck> CardinalFang: got it! :)
<statik> dlee: I've got a patch for the bookmark plugin to list the stored bookmarks. Should I send it to you, or luks?
<dato> statik: hm, different to what `bzr bookmarks` does? :)
<statik> dato: now, how did I miss that :(
<statik> hmm, this might be polished still
<statik> I think the bookmark name should be listed first
<dato> it is, at least here?
<statik> I get the path, then the short name
<statik> it looks like the code is intending it to print the other way
<statik> so, I still have a patch, it's just shorter :)
 * statik should learn to read more carefully
<Peng> That bookmarks plugin is cool.
<dato> statik: maybe you should double check with an unmodified plugin, I still see the plugin name first?
<Peng> That was something I liked from hg.
<dato> (but I only have 1 bookmark, so it may be that)
<statik> dato: this isn't about the plugin name. its about what is output when I run bzr bookmarks
<statik> this fixes it
<statik> -        for name, url in sorted(bookmarks):
<statik> +        for url, name in sorted(bookmarks):
<dato> statik:
<dato> % bzr bookmarks
<dato> forja                svn+https://forja.rediris.es/svn/csl2-minirok/trunk
<dato> (err, s/plugin name/name/ in my line above, sorry)
<statik> dato: I see. it prints the opposite way in revno 3 from http://bazaar.launchpad.net/~luks/%2Bjunk/bzr-bookmarks/
<statik> dato: what revno do you have?
<dato> I had 2, and pulled to 3
<statik> dato: then the only explanation is that I stored the data wrong when I first added a bookmark.
<statik> and this whole thing has been me being confused
<dato> makes sense
<dato> from ~/.bazaar/bazaar.conf:
<dato> [BOOKMARKS]
<dato> forja = svn+https://forja.rediris.es/svn/csl2-minirok/trunk
<statik> yep, I have my bookmarks inside out
<ubotu> New bug: #180116 in bzr "bzr rm pathologically slow with new files and no --keep" [Undecided,New] https://launchpad.net/bugs/180116
<dato> jelmer: ping
<jelmer> dato: pong
<dato> jelmer: trouble in bzr-svn paradise ;)
<dato> I have minirok.dev, which I push to svn+https://....../trunk
<mathrick> funny, I just discovered bookmarks plugin today
<dato> and I did svn mkdir https://..../branches; svn cp https://..../trunk https://...../branches/foo
<dato> and b get minirok.dev minirok.foo
<dato> but pushing from minirok.foo to svn+https://..../branches/foo won't work, is that expected?
<jelmer> dato: What error do you get?
<dato> bzr: ERROR: These branches have diverged.  Try using "merge" and then "push".
<jelmer> what does "bzr missing" say?
<dato> AssertionError: Empty parent added, but child wasn't added !?
<mwhudson> oo-oo
<jelmer> uhm, ok
<jelmer> that's definitely a bug
<jelmer> what version bzr-svn is this?
<dato> % cd .bazaar/plugins/svn && b revno
<dato> 826
<dato> shall I pull?
<jelmer> Hmm, I don't think anything has changed since that could've fixed it.
<jelmer> Any chance you can file a bug? Links to minirok.dev, minirok.foo and the svn repository would be very useful
<dato> ok. in the meantime, I guess it's ok if I continue to commit in minirok.foo?
<jelmer> yep
<dlee> I doubt we have this yet, but ... Do we have anything for handling line ending conversions?  I just cvs-imported a 760+ revision CVS project that had been managed under Windows, but bzr co's now check out with LF, not CR+LF.  I did the co under Window+Cygwin, then another one under just Windows using the stand-alone Windows binary bzr.
 * dlee wishes everything including Windows could just use LF and be done with it :P
<mathrick> I still don't understand why workingtree 3 uses so much bandwidth
<CardinalFang> It's dangerous to alter the data.  Is that file with ordinals 13 and then 10 a text file or a PNG image?  Oops, wrong choice.
<dlee> CardinalFang: Yeah I know...otherwise I'd just ask for a co option to deal with it.  Svn used properties because of that problem, and CVS used something like a checkin-time "property."  I think line endings are on the ToDo list but not addressed yet; I'm mostly just verifying, while I try to figure out how to keep selling the Bazaar concept to my entirely Windows-based company that has been using CVS for about five years...
<CardinalFang> dlee, Ah.  We're in the same boat then.
<mathrick> dlee: CVS had a horribly broken solution for that, though
<mathrick> like for most things
<dlee> hehehe
<mathrick> given that more people seem to be awake now, anyone care to take a look at this patch: http://pastebin.com/m682e5b7e ?
<mathrick> is this the correct way to remove diff_cmd_helper() use?
<mathrick> I don't like the fact that I had to steal the whole spec_tree() from inside diff_cmd_helper()
<dlee> It worked well enough for us, *if* people remembered the required -kb on cvs adds of non-text files.  But that's a big *if* there.  I liked the svn property idea better, but I used "native," which operated about like CVS anyway.  (I did that to avoid having to put ^M at the end of every line when actually editing in an LF environment.)
<dato> jelmer: bug #180128
<ubotu> Launchpad bug 180128 in bzr-svn "Cannot push to a branch `svn cp'ied`" [Undecided,New] https://launchpad.net/bugs/180128
<jelmer> thanks!
<CardinalFang> I'm accustomed to creating a new branch that I expect to pull into several branches that never themselves merge.  How does one create a branch that is the greatest common ancestor of two branches?
 * mathrick doesn't really understand what CardinalFang said
<CardinalFang> (Well, "never" is wrong.  One is a ostensibly a superset, but it may not have changes that have been added into the subset.)
<CardinalFang> (Yet.)
<dlee> CardinalFang: Verify this with more seasoned bzr users here, but I'd say bzr init-repo /path/proj, then cd /path/proj and bzr co projBranchThatWillAncestorNewOnes.  To make a descendant, from /path/proj, bzr co ancestorBranchJustMade newBranchName.
<CardinalFang> mathrick, Suppose I have a v1.0 branch and a v2.0 branch.  I can't pull v1.0 to v2.0 because there are some things that others have added but are not yet added.  I know I can add to v1.0 and cherry-pick "merge -c" just one new revision, but is there a way to create a branch that has only changesets that are in v1.0 and in v2.0, so I can add a changeset to it and pull into both with no trouble?
<CardinalFang> ^not yet added^not yet merged to v2.0
<mathrick> CardinalFang: aha, first guess would be that bzr branch v1.0 common; bzr branch common v2.0 should work for you
<CardinalFang> So, if a branch is a set of changesets, I want to create a branch that is the intersection of two other branches.
<mathrick> if you want a commit applicable for both, push it into common, otherwise, into v1.0 or v2.0 as needed
<dlee> Ah...I didn't know you had two already-existing branches; I thought you were doing this top-down (ancestor exists, then you spin off 1.0 and 2.0 from there).
<mathrick> ah
<mathrick> CardinalFang: what branches do you have *right now*?
<mathrick> and how are they related?
<CardinalFang> mathrick, One was created from another.  v1 and v2.  Most work is in v1, and people don't always merge to v2 soon enough.  So, I can't pull from v1 to v2 without having to merge a bunch of stuff that I don't know anything about.
<CardinalFang> So, i can't add to v1 and pull.  Got it?
<mathrick> aha, yes
<CardinalFang> If I can create a branch that can always be pulled into v1 and v2, then I can fix my bug there and pull into both at once.
<CardinalFang> Then, I don't have to care that other people were sloppy about getting their v1 changesets merged into v2.
<mathrick> is v1.0 a strict superset of v2.0?
<CardinalFang> No.  It's a subet, in a perfect world, but in reality, there's a delay between when someone adds to v1 and when they pull to v2.
<mathrick> aha
<mathrick> I don't know if there's a tool to do what you want to do automatically
<CardinalFang> I'm beginning to think that the answer is cherry-picking.
<CardinalFang> Add rev12345 to v1 and then in v2, "bzr merge -c rev12345 ../v1"
<mathrick> if one branch is reasonably close to the shared subset, you could branch the common off it, and then hack at it with rebase and selective uncommits until it looks like you want it to... I think
<mathrick> CardinalFang: you have to be aware that cherry picks in bzr are *not* tracked right now
<CardinalFang> Eeek!
<dlee> You seem to want a justV1 place to commit, and a justV2 place, and a V1&V2 place.  I don't think you'd need an ancestor branch; v1 and v2 are already related.  This is a long shot into stuff I don't know so well, but would Rebase be of any use here?
<mathrick> indeed
<mathrick> dlee: I think rebase would be a tool towards building such a V1&V2 thing, but you need something to back out changes that should not be there
<mathrick> I'm not sure how exactly you'd go about that, uncommit can't pull from the middle, and revert works on the text level, not revisions level
<CardinalFang> mathrick, How about "merge -r big..small" to remove changesets?  Is that safe?
<mathrick> CardinalFang: what are big and small exactly?
<dlee> I remember there was a CVS add-on (forget the name) for automating the commits to multiple branches for this type of problem.
<mathrick> ahh
<mathrick> CardinalFang: dunno, but now I think of it, bzr rebase --onto might do that whilst still preserving the history and identity of revisions
<mathrick> unsure, the whole --onto thing is a bit magical
<CardinalFang> Hrm.  Time for some testing.
<mathrick> but it will be manual, unfortunately
<mathrick> CardinalFang: if you have enough crap to deal with, you might consider writing a plugin I guess
<dlee> It occurs to me that this could probably also be handled by having multiple "parents" of one branch--i.e., commit in such a branch must clear more than one source branch before committing locally; but that also sounds like a mess to set up :)
<mathrick> dlee: there was something called "multiparent" there in bzr.dev at one point, but it was completely undocumented and I have no idea what it really did
<dlee> hehe
<CardinalFang> Dang.  The tool I'm accustomed to has a command that gives the greatest common ancestor between the current and a specified location on stdout.  Then one can "clone -r`find-the-greatest-common-ancestor ../v1`" .  Very useful, that.
<mathrick> ahh, for that there's definitely support in bzrlib
<mathrick> dunno about the UI
<dlee> Mathrick: ...but I bet the bzrlib support only works on tracked stuff; cherrypicking would break that, no?  I think you'd have to do text compares otherwise, to figure out what v1 changesets equal what v2 changesets.
<mathrick> dlee: no, changesets have identity
<CardinalFang> I'm not using cherry picking.  I thought it was a solution to that problem, but now I don't.
<dlee> Nice!  I'm still figuring out the cherrypicking history issues; I guess they're not quite as bad as I thought.
<mathrick> CardinalFang: I dunno how easy it is to produce a tree that's the intersection of A and B from bzrlib. But given it's the base of all merges, it should be doable
<mathrick> dlee: ah, no, cherrypicking does break stuff
<mathrick> but CardinalFang wasn't cherrypicking between V1 and V2
 * CardinalFang nods.
<mathrick> uh-huh, bzr rebase is quite dangerous
<mathrick> it just went to happily destroy my test tree
<mathrick> jelmer: poke?
<dlee> New issue:  I asked yesterday how to append one bzr repo to another.  Motivation: trying to combine a CVS history for proj1 with an SVN history for later workk on the same proj1.  Also, I want to rebuild a (so far unused) Bazaar repo that I initially built with Tailor but want to build with cvsps-import (to get tags), but there are subsequent bzr-only commits in it, so I'd have to cvs-import and then copy a stack of bzr commits on top of 
<mathrick> dlee: there was a graft plugin, but it's very much outdated
<mathrick> I dunno if there's any successor to it
<mathrick> I dunno if you can even get the source anymore
<mathrick> dlee: http://spacepants.org/src/bzrgraft/
<dlee> thanks
<mathrick> I wonder if I can make bzr shell make execute scripts
<mathrick> wtf
<mathrick> http://bazaar.launchpad.net/~bzr/bzr-dbus/trunk gives 404
<jelmer> mathrick, pong
<jelmer> mathrick, even "bzr rebase-abort" doesn't restore it?
<mathrick> jelmer: lemme see
<mathrick> jelmer: it does some very scary things in any case
<jelmer> mathrick: why?
<mathrick> jelmer: and no, rebase-abort doesn't help
<mathrick> sec, I'll give you a test case
<jelmer> mathrick, what version of rebase are you using?
<mathrick> lemme see
<mathrick> jelmer: unsure, it's a lightweight checkout, I dunno how to check the latest revision in my working tree in this case
<dlee> revno still works in lightweights
<mathrick> dlee: but it reports the latest *upstream* revision
<mathrick> at least it used to
<mathrick> maybe that got fixed since 0.90 when I last tried
<dlee> Oh hehehe, I've never lightweighted a branch someone else was committing to, so I'd never know
<mathrick> I use it for plugins, since I have no real interest in having my own branch, really, I just need an up-to-date copy
<dlee> I do wish I had a way to get the revno of my local branch after a revert though...
<mathrick> dlee: you can't, since revert works on text
<mathrick> I ran into the same thing myself
<dlee> Darn!
<dlee> I wonder if any VCS' support a sort of grep that returns all revisions / revision ranges containing matches to a regexp.  Sounds really hard to do fast though, but I've often wanted that and never seen it offered.
<dlee> I imagine it like grep, where instead of "filename:" at the beginning of each line, you'd have "revrange:"
<dlee> actually revset, where a set could be one or more ranges, and a range could be a singleton
<mathrick> bah, whole launchpad is broken
<mathrick> you can't download things
<mathrick> dlee: yes, there's a grep plugin for bzr I think
<dlee> Uh oh, what'd I miss? * runs off to plugin page
<mathrick> except that you won't get it, since launchpad is broken :(
<jelmer> mathrick: Any chance you can report a bug about the rebase issue you just ran into with a testcase ?
 * jelmer has been using rebase happily on a daily basis and knows of several other people who have
<mathrick> jelmer: yes, I'm just trying to determine what rev I have
<mathrick> I also ran into bzr reconfigure butchering my lightweight checkout today, I need to investigate that
<mathrick> jelmer: aha, so apparently I had r69, which is the latest
<mathrick> now for a testcase
<mathrick> jelmer: http://pastebin.com/f77fd13fb
<mathrick> want me to write a bug report, or do you want to do it yourself?
<jelmer> please file it
<mathrick> okay
<mathrick> done
<mathrick> jelmer: is what I'm trying to do (ie. pretend that r3 happened immediately after r1, and there was no r2) sensible and supposed to work?
<jelmer> the way I read it you're just trying to remove r3
<mathrick> jelmer: oh, then I'm misunderstanding something
<jelmer> rebasing revision 2 on top of 1
<mathrick> jelmer: right, that's because -r -2 always confuses me by its changing semantics
<jelmer> I don't think there are any changing semantics there..
<jelmer> the last revision (3) is -1
<jelmer> the previous-to-last (2) is -2
<mathrick> jelmer: well, yeah, but different commands interpret it slightly differently
<jelmer> mathrick: Can you give an example? afaik we're consistent everywhere there
<mathrick> jelmer: yes, in a repo with 3 revs, bzr diff -c -3 shows changes for revision
<mathrick> *revision 1
<mathrick> however, diffstat -r -2 and -r -3 shows stats starting from the same revision
<mathrick> which is revision 1
<jelmer> That makes perfect sense
<mathrick> howso?
<jelmer> well, not sure about diffstats behaviour
<jelmer> but that's not a core bzr command
<jelmer> but in a repository with 3 revisions -3 means revision 1
<mathrick> yes
<mathrick> but -2 should mean r2
<jelmer> it does, for bzr diff
<mathrick> I wonder where the inconsistency comes from in diffstat
<jelmer> I think the fact that diffstat supports "-r2" is a bug in itself
<mathrick> jelmer: anyway, why would rebasing r2 onto r1 kill r3?
<mathrick> jelmer: oh?
<mathrick> it should do the same thing as diff
<jelmer> mathrick: It should accept -c2 or -r1..2
<jelmer> mathrick: sorry
<jelmer> I forgot -r2 has meaning as well
<jelmer> diffstat -r2 should report the changes between -r2 and the current working tree
<mathrick> yes
<mathrick> it does, except that it interprets -2 in an odd way
<jelmer> that's a bug in a single plugin, you can hardly blame the rest of bzr for that..
<mathrick> it pretty much ignores the last rev
<mathrick> jelmer: well, I know, it's consistent, just somewhat shifting conceptually depending on where you stand, not unlike the way how 1 is "different" in "asd"[:1] and "asd[1:]
<mathrick> jelmer: in any case, why would rebasing r2 affect r3?
<mathrick> jelmer: and I tried bzr rebase -r 3 --onto=1 .
<mathrick> and it's a no-op
<mathrick> I'd expected it to put r3 immediately after r1 in the history
<jelmer> mathrick: because you're only rebasing a single revision
<jelmer> I guess you may mean "-r2.." or something
<mathrick> oh?
<mathrick> jelmer: so, "rebase -r X --onto=Y" means "throw away everything that follows Y in history, and make it say X instead"?
<mathrick> and if I say -r2 for X, it replaces the whole history with that single revision?
<mathrick> jelmer: and why does it say "No revisions to rebase." when I do that>
<mathrick> ?
<jelmer> that's the bug
<jelmer> it shouldn't abort early and print that error
<mathrick> jelmer: ah, besides, that error message is missing a \n
<jelmer> other than that, it looks fine
<mathrick> jelmer: but then bzr rebase -r 3 --onto=1 . is buggy
<jelmer> no, that makes sense
<mathrick> then I'm not getting it
<jelmer> -r3 means it will rebase the revisions up to r3
<jelmer> *up to and including
<jelmer> -r1..3 means it will rebase revisions in that specific range
<mathrick> urk
<jelmer> ?
<jelmer> also, using rebase on "." usually doesn't make any sense
<mathrick> jelmer: see, that's why I said changing semantics :). Sometimes it means "up to and including X", sometimes it means "starting from X", and sometimes it means "exactly X"
<mathrick> jelmer: I want to effectively remove r2 from the branch's history
<jelmer> mathrick, I don't think that's confusing. It's the same way how merge works
<jelmer> Perhaps you want something like "bzr rebase -r2..3 --onto 1 ." ?
<jelmer> it may be necessary to run "bzr up" after that because of the bug you just reported
<mathrick> jelmer: it doesn't appear to do anything
<jelmer> and -r3..3?
<mathrick> jelmer: it commits r2 and r3, but they end up in the same place they started in, so it's not a real change
<mathrick> jelmer: that works, and results in a text conflict
<jelmer> that's right
<jelmer> since the delta for r3 won't apply cleanly on r1
<mathrick> yeah, I guessed that, since r3 modifies r2, which ceases to exist, it will give errors
<mathrick> jelmer: will the revision identity be preserved afterwards?
<jelmer> mathrick, the revision identity for r3 you mean?
<mathrick> yes
<jelmer> No the revid for that will change
<jelmer> since it's parent revids have changed
<jelmer> not changing that would be a severe bug
<mathrick> jelmer: hmm, so it's not really suitable for tree surgery which would remove individual revs preserving the rest?
<jelmer> mathrick: that's not really the use case for rebase.. you may want to have a look at 'bzr replay' (part of the rebase plugin)
<jelmer> that basically just does diff+patch+commit with original metadata
<mathrick> jelmer: aha, and the revisions will be seen as identical for purposes of calculating merges?
<jelmer> no
<jelmer> there's no way to do that
<jelmer> rebase and replay will store metadata indicating what revisions they were originally based on
<jelmer> however, they are not identical copies of those revisions and shouldn't be treated as such by merge. merge may be able to use that metadata in some way, but doesn't at the moment.
<mathrick> jelmer: hmm, so there's no way of doing what CardinalFang wanted (ie. create a tree that only has changes common to A and B)?
<mathrick> jelmer: "merge using that metadata in some way" would be tracking cherrypicks, right?
<jelmer> basically, yes
<mathrick> jelmer: so, if A and B share all revisions up to some revision R1, and afterwards there are revs that are sometimes in both, but sometimes only in one of them, the best you can do is split out the common tree up to R1, and there's no way to have a tree that would have the later commits that are present in both?
<mathrick> though that seems wrong to me, my understanding would be that constructing such a tree is necessary for properly carrying out merges
<jelmer> mathrick: how do you define "commits present in both"?
<jelmer> commits with the same diff that have been applied to both trees?
<mathrick> jelmer: sec, I'm drawing up a graph for that, and then we can ask CardinalFang if that's what he actually meant
<jelmer> You could make those commits in a separate tree C and merge that into A and B
<jelmer> where C could start out with R1
<lifeless> moin
<jelmer> 'morning lifeless
<CardinalFang> jelmer, The use case:  You have two sister trees, neither of which is a subset of the other.  You find a bug common to both and you want to fix it as easily as possible, without otherwise altering the sister trees.
<jelmer> CardinalFang: that is the basic use case for cherry picks
<mathrick> jelmer: but cherrypicks break merges
<CardinalFang> Agreed, cherry picking would solve it.  But that introduces other problems, yes?
<fullermd> Well, or for daggy'ing it.
<jelmer> mathrick: How do they break merges?
<mathrick> jelmer: cherrypicks are not tracked, so they will introduce textual conflicts, no?
<jelmer> merge treats cherrypick commits as ordinary commits at the moment
<jelmer> mathrick: Merge will recognize the fact some revisions are cherrypicks, but from what I understand, CardinalFang is not merging between those trees anyway
<mathrick> but I think he wants to at some point
<CardinalFang> The SCM I use now, which is made by a notoriously litigious organization who shall not be named, provides a "repogca" command, which returns the "greatest common ancestor" of two trees, which one uses to branch off a tree that can be pulled into either.
<mathrick> jelmer: will it recognise the fact they are present in the tree already?
<jelmer> mathrick: No, that's what tracking cherrypick information is about.
<mathrick> right, so merge does not really recognise cherrypicks
<jelmer> CardinalFang: that would be possible with bazaar as well
<CardinalFang> Yes, the two trees are constantly merged.  But with more than a hundred people committing /all the time/, we can't sit on our hands if one person falls behind.
<mathrick> CardinalFang: okay, so what kind of change can make V1 unmergeable into V2?
<CardinalFang> Lack of knowledge.  If there's a conflict in some dark corner of the code that only Joe and his acolytes know about, then I don't feel comfortable making decisions about what stays and what gets pruned away.
<mathrick> CardinalFang: aha, and your current VCS can cope with that? Ie. track cherrypicks?
<CardinalFang> No. Not at all.
<CardinalFang> But it can give me a tree that has only common changesets in it.
<mathrick> CardinalFang: uhh, but that's not very useful unless you can arrange for pulls that aren't contiguous wrt. to the source history (ie. cherrypicking)
<mathrick> CardinalFang: let's sum up
<fullermd> What he means is that there's a convenient command to set up a daggy fix.
 * CardinalFang googles "daggy"
<mathrick> CardinalFang: google mercurial together with it
<fullermd> There isn't one in bzr currently; you'd have to manually poke around 'missing' or something to find the GCA.
<fullermd> monotone, actually.  Nice page on their wiki.
<mathrick> ahh
<mathrick> CardinalFang: V1 is at R1, V2 is at R1'. At this point, V1 is cleanly mergeable into V2, right?
<mathrick> CardinalFang: now there are two commits into V1, R2 and R3, and a commit R2' into V2. R2 conflicts with V2, but R3 doesn't. You want to pull R3 only, and leave R2 to be solved later, right?
<jelmer> lifeless: any chance you can sponsor an upload of bzr-pqm to Debian?
<mathrick> by "conflicts with V2" I mean "can't be merged into V2 without conflicts"
<CardinalFang> mathrick, I'd rather not merge anything at all.  I have an urgent bug to fix that is present in all trees.
<CardinalFang> If I don't fix it in 20 minutes, the Sun explodes.
<fullermd> Wait, let me get my camera.
<CardinalFang> fullermd, You have at least another 8 minutes, from this distance.
<mathrick> CardinalFang: okay, and how do you do that with your current tool (and what is that tool, if I may ask)?
<fullermd> So what you want to do, is create a new branch from the LCA, and do the fix there, so it'll merge just fine into both sides.
<CardinalFang> mathrick, With my current tool, I think it creates a tree that is only R1.  I can create a new changeset R4 and pull that into V1 and V2
<mathrick> CardinalFang: aha
<CardinalFang> fullermd, Yes.  (Though I think it's "greatest" instead of "least", in the domain I'm thinking about.)
<fullermd> I think it's usually expanded "latest" aroudn here.
<CardinalFang> Ah.
<fullermd> There's no command to give you it directly.  The quickest way is probably 'missing', then pick the rev before the earliest in both lists.
<CardinalFang> fullermd, Hmm.  Perhaps I could write a plugin to do that.
<fullermd> Probably.  I don't think it would be terribly difficult.
<fullermd> [3-way] merge already does it after all; you could just steal the code from there.
<fullermd> May even be a function that does it you could just call and display.
<mathrick> CardinalFang: if you had a parent, and at R0 V1, V2 and C were branched off it, then A had R1, C1 (merged from C), R2, and V2 had R1', C1, R2', would repogca create a tree that ends with R0, or would it have R0, C1?
<CardinalFang> mathrick, Good question.  I'll try it.
<CardinalFang> fullermd, FWIW, graph.py says "least."  :)
<CardinalFang> Sorry, "lowest".
<fullermd> We should declare once and for all that it stands for "lambada".
<fullermd> It may not mean anything useful, but it should lead to some really fun questions.
<mathrick> *lambda
<mathrick> :>
<fullermd> No, I meant lambada   :p
<CardinalFang> llama
<fullermd> lambda is too close to actually meaningful.
<mathrick> CardinalFang: anyway, if you write a plugin, it should be doable to get a tree that ends with R0, C1, since that's the tree merge has to construct when you say cd B; bzr merge A
<lifeless> jelmer: good chance; this arvo probably
<Arjen> Hi, is the benchmark script available somewhere?
<mathrick> lifeless: can I trick you into looking at my short patch that removes diff_cmd_helper() use?
<mathrick> I need someone with a clue if that's the way it's supposed to be done
<lifeless> not now; coding. I'll come up for air when Lynne gets up probably.
<lifeless> so in a couple of hours
<mathrick> lifeless: okay then, I guess I'll just submit it upstream and wait for review there, I'll be sleeping in a couple of hours
<mathrick> mathrick@hatsumi:/tmp/rebase$ bzr reconfigure --branch
<mathrick> bzr: ERROR: Repository KnitRepository('file:///tmp/rebase/.bzr/repository/') is not compatible with repository KnitRepository('http://people.samba.org/bzr/jelmer/bzr-rebase/.bzr/repository/')
<mathrick> huh?
<jelmer> rebase is using dirstate-with-subtree
<jelmer> looks that's confusing reconfigure
<mathrick> it's a lightweight checkout which I converted from knitpack to knit (since it was erroring out about KnitPackRepository being incompatible)
<mathrick> jelmer: oh
<mathrick> the fact that reconfigure does not do a checkout is horribly confusing
<mathrick> it looks as if it just ate your tree
<lifeless> mathrick: I filed a bug last week on this; you might compare and see if its the same
<ubotu> New bug: #180196 in bzr "bzr reconfigure gets confused by dirstate-with-subtree" [Undecided,New] https://launchpad.net/bugs/180196
<mathrick> lifeless: I can't find it, care to give a bug#?
<ryanakca> why is it that when I go "bzr up" on a local (well, ssh'd to server) branch, I get the following error message?
<ryanakca> Using saved location: http://bazaar.launchpad.net/~...../
<GoClick> Does bzr store all it's information is a million .bzr folders like svn?
<ryanakca> bzr: ERROR: Cannot lock LockDir(http://bazaar.launchpad.net/~...../.bzr/repository/lock): Transport operation not possible: http does not support mkdir()
<mathrick> GoClick: ?
<Odd_Bloke> GoClick: No.
<mathrick> GoClick: you mean an .svn dir in ever subdir?
 * ryanakca isn't uploading... so it shouldn't matter if http can or can't make a directory...
<mathrick> no
<GoClick> mathrick:  yeah
<Odd_Bloke> GoClick: There is a single .bzr directory for your branch.
<GoClick> good
 * mathrick wonders if there's anything about SVN that's strictly better than bzr
<Odd_Bloke> mathrick: It's faster for a lot of things. :p
<fullermd> Partial checkouts.
<jelmer> mathrick: eol-conversion support, better performance for large binaries, cherrypick tracking, ...
<mathrick> Odd_Bloke: by not doing things, that's like being really fast at writing to /dev/null
<mathrick> jelmer: it tracks cherrypicks how? Last time I checked, SVN had no merge support
<GoClick> We put a lot of binaries in our version control as is, will that be a problem?
<fullermd> That means cherrypicks can't screw up merges   ;)
<foom> mathrick: but if you want to write to /dev/null, it sure would be nice if it went fast, instead of slow.
<jelmer> mathrick: 1.5 has
<jelmer> mathrick: svn has always had merge support, just hasn't had merge /tracking/ support until 1.5
<mathrick> foom: sure, but it's not a reason to say "my foo is better than yours, since it's really fast at writing to /dev/null, whereas yours takes a lot of time to write to screen"
<mathrick> jelmer: aha, so you can finally merge branches in a sane way and it doesn't kick you in the nuts harder for doing it often?
<jelmer> yup
<jelmer> that's 1.5 only though, which was supposed to be released 2 years ago or something..
<foom> actually i think only 2 months ago or something
<foom> but when i last skimmed the mailing list it didn't look too promising
<foom> i'd sure like to be able to switch to bzr sometime soon. :)
<mathrick> foom: not being punished for merging would be pretty promising in my book:)
<jelmer> foom: They've always been pushing the deadline further forward
<foom> mathrick: i mean, the chance of a release coming soon wasn't looking good
<jelmer> foom: When I originally started on bzr-svn 1.5 was also "almost done"
<jelmer> That's more than 2 years ago now
<mathrick> foom: do like I do, use bzr-svn to manage your code, this way instead of putting up with stupid buggy SVN crap you will help bzr-svn maintainers discover new ways to improve their quality ;)
 * mathrick runs
<fullermd> OTOH, you keep finding new bugs in the python bindings, so...   :p
<foom> mathrick: that's the plan, but bzr is too slow right now
<mathrick> jelmer: so it's still not released?
<mathrick> foom: only in the initial checkout, or do you mean something else too?
<mathrick> the checkout thing is mucho painful because you can't horizon the history
<jelmer> mathrick: svn 1.5 ? Nope, and doesn't look like it's going to be released soon either, at least not within the next couple of months.
<foom> mathrick: log is excessively slow at the moment
<mathrick> jelmer: oh, I see, I thought you were talking about actual shipped SVN now
<lifeless> foom: local or remote. Please file a bug if it's remote, tagged hpss
<foom> lifeless: local
<mathrick> foom: dunno, it's being pretty fast for me, and I have repos with 3K revs with 2K-revs merges along the way
<fullermd> log -v is downright vicious.
<mathrick> lifeless: what does hpss mean?
<foom> lifeless: i saw a bug already filed about log getting slow in pack format repos
<lifeless> mathrick: smart server
<mathrick> oh right, I didn't try it with pack yet
<mathrick> lifeless: and hp?
<mathrick> high perf?
<lifeless> foom: there is a slow down
<lifeless> mathrick: yes
<lifeless> foom: but it should still be plenty fast; are you just doing 'bzr log' or -v or other optoins?
<foom> lifeless: time bzr log -r30000 [waiting]
<foom> real    0m35.296s
<foom> user    0m28.513s
<foom> sys     0m0.234s
<foom> i'm sure if i was using a 3krev repo it'd be fine.
<jelmer> 14k revs is 5 seconds here
<lifeless> foom: using packs?
 * mathrick wonders what git would score on that
<foom> lifeless:     repository: Packs containing knits with rich root support
<mathrick> it's awesomely fast to be sure
<fullermd> -v will slaughter you even with 3k revs.
<jelmer> yeah, -v is slow as hell
<mathrick> OTOH, with bzr I'm able to figure how to un-add a file, with git, I'm not...
<foom>      43276 revisions
<foom>     599396 KiB
<fullermd> With a ~1800 rev tree, 'log' runs in 1.7 seconds.  -v has passed the 3 minute mark so far, and broken 120 meg of RAM usage (impressive, since .bzr/ is only ~16 meg)
<fullermd> Oh, there it finished.  225.5 user seconds, half a second of system time.  3:48 wall.
<lifeless> foom: how many packs do you have ?
<lifeless> fullermd: -v will get better before too much longer, but its a disk change
<foom> just count the files in .bzr/repository/packs?
<foom> 24.
<lifeless> foom: yeah, or cat .bzr/repository/pack-names
<fullermd> lifeless: And one I look heartily forward to, especially if it lets me 'log' more than one file at a time too.
<foom> it says 22
<lifeless> foom: you've had some interrupted uploads then
<lifeless> do a ls -lS of the packs directory
<lifeless> is there a good size distribution ?
<lifeless> also you may find log gets faster if you do 'bzr pack'
<ubotu> New bug: #180207 in bzr-eclipse "Creating project from bazaar branch" [Undecided,New] https://launchpad.net/bugs/180207
<ubotu> New bug: #180208 in bzr "commit failed because of lack of disk space but with unclear message" [Undecided,New] https://launchpad.net/bugs/180208
<foom> lifeless: yeah, bzr-svn crashed my machine while importing because it ran it out of ram.
<foom> and the kernel OOM killer decided to kill everything *else*
<lifeless> OOM FTW
<jelmer> foom: That bug has been fixed since
<jelmer> foom: http://subversion.tigris.org/issues/show_bug.cgi?id=3052
<foom> jelmer: yeah, i saw
<mathrick> hmm, you can't uncommit a single revision in the middle, right?
<thumper> mathrick: right
<thumper> mathrick: it is my understanding that you uncommit the latest commit
<mathrick> http://bazaar-vcs.org/BzrVsHg#head-b92d4fdb6541abcf14ea53686e4bccc9f7b6ffa5 seems to suggest that bzr can indeed do that
<mathrick> or so I read it at least
<foom> lifeless: anyhow, yes, there's a good distribution of sizes, the biggest is 245595344 and smallest is 1875 and there's lots in between.
<foom> lifeless: after bzr pack, it is down to 4.421s
<fullermd> I think that page is misleading; bzr uncommit is only very vaguely related to hg rollback.
<fullermd> uncommit removes a rev (or more precisely, changes the head).  rollback, AIUI, creates a new rev with opposite changes.  It's more like bzr merge -rx..x-1
<foom> lifeless: still slow, but only 4x slower than svn instead of 30x.
<mathrick> foom: that would be a bad distribution if they differ in sizes greatly
<mathrick> I believe
<lifeless> morning poolie
<lifeless> mathrick: they are meant to differ geometrically
<mathrick> ah
<poolie> hi lifeless
<lifeless> foom: ok; feel free to find out whats slow then ;) I don't feel like downloading a 1/2 GB repo to find out :]
<igc> morning
<lifeless> hi igc
<igc> hi lifeless
<foom> lifeless: is the 7x slowdown to be expected for 22 pack files vs 1, then?
<lifeless> foom: pack orders the revision xml texts topologically
<lifeless> foom: so you do ascending IO within the pack, which linux likes a lot.
<foom> lifeless: sure but it's CPU time being spent.
<lifeless> foom: possibly index layer stuff then, which is on the todo
<ecasbas> hi, I am having a problem creating a local repository, the setup is like: http://wiki.squid-cache.org/Squid3VCS#head-a70c042fb73ac3863a0fd32ff452b59279ff7030
<ecasbas> at the momment of: bzr branch $TRUNKURL ~/squid-repo/trunk
<ecasbas> I get: bzr: ERROR: Unknown branch format: 'Bazaar pack repository format 1 (needs bzr 0.92)\n'
<ecasbas> Bazaar 0.90 / Ubuntu 7.10
<jelmer> ecasbas: you need a newer version of Bazaar
<jelmer> at least 0.92 or higher
<ecasbas> ok, thanks then I'll download the 1.0
<ecasbas> thanks jelmer
<ecasbas> thanks very much, the 1.0 worked perfectly!
<lifeless> perfect example of our clear format strings not being enough lol.
<poolie> I suspect many "they change formats too often" complaints are really "the changes are too bumpy"
<foom> that error seemed pretty clear to me, unlike the ones that say KnitRepository isn't compatible with KnitRepository or w/e. :)
<fullermd> Well, the changes aren't all that bumpy (at least, they're reasonably close to the irreducible limit of bumpiness)
<lifeless> poolie: I agree with your statement if you change 'too bumpy' to 'we talk about it' :)
<fullermd> I know I've seen several bumps in mtn, and it just wouldn't do anything 'till I told it to upgrade.
<fullermd> Going across bzr bumps works OK (well, repo changes are usually **SLOOOOW** to work across, but they work, and you can keep working locally without the upgrade)
<jelmer> imho bzr upgrade is too slow, that's in fact the reason I haven't upgraded a lot of my branches yet
<fullermd> A big bump is that inter-repo-format work is so slow that practically, upgrading that means you need to flag day _every_ branch of the project.
<lifeless> jelmer: to packs ?
<lifeless> jelmer: its the time to clone, no more.
<jelmer> it's actually reconcile that was the most problematic
#bzr 2008-01-04
<lifeless> reconcile in pack form
<lifeless> the instructions are over cautious
<jelmer> lifeless: Notes when upgrading in 1.0rc1 says to reconcile before upgrade.
<lifeless> 11:00 < lifeless> the instructions are over cautious
<jelmer> ah
<jelmer> sorry
<lifeless> but use 1.0
<lifeless> not an rc :)
<fullermd> At least for a few hours yet, don't use a rc   ;)
<mathrick> is bzr-git supposed to be able to check out git branches (as in, remote ones)?
<mathrick> or does it only work with a pre-existing working tree or something?
<mathrick> meh, neither seems to work at all
<lifeless> bzr-git is not ready for that yet
<mathrick> yeah, I can see that
<mathrick> does pack-0.92 support nested trees?
<jelmer> mathrick: no
<mathrick> aha, so dirstate-with-tags is the best bet now?
<jelmer> dirstate-with-tags doesn't support nested trees either
<mathrick> rich-root-pack yelled at me it doesn't support nested trees either
<mathrick> jelmer: well, I have a bzr-svn repo in that format
<jelmer> that must be dirstate-with-subtree
<mathrick> with a merged-into tree...
<jelmer> not dirstate-with-tags
<tonyyarusso> Hi folks, I'm afraid I don't entirely understand how bzr works (or any versioning thing for that matter), but want to check it out.  Do I need anything more than a web host that supports Python scripts?
<mathrick> jelmer: oh, I probably meant that, yeah
<mathrick> jelmer: in any case, I saw your mail where you say you're replacing all references with rich-root-pack, but it explicitly said it doesn't support nested trees here
<mathrick> tonyyarusso: you don't need any web host (or python scripts there for that matter)
<mathrick> web only comes into play if you want to share your repos publically
<jelmer> mathrick: bzr-svn doesn't need nested trees
<mathrick> jelmer: aha, I remebered from somewhere that it did
<mathrick> I wonder why
<jelmer> mathrick: however, you can't downgrade a branch to a format with less features, even though you don't use those features at the moment.
<mathrick> jelmer: oh, but I do use nested trees (I believe, unless merge-into doesn't actually use them)
<tonyyarusso> mathrick: I was hoping to have things accessible from multiple locations (I'm looking for a way to get at my files from various computers - and I have DreamHost space)
<mathrick> tonyyarusso: then all you really need for bzr is ssh access for writing and http access for reading
<tonyyarusso> mathrick: So is there nothing server-side about it at all other than the storage space?
<mathrick> pretty much yeah
<tonyyarusso> cool
<jelmer> mathrick: merge-into doesn't use nested trees afaik
<mathrick> you can use smart server if you can run it on the remote side, but it's entirely optional (and wouldn't probably improve your life significantly, as you're likely to have rather limited needs at first)
<mathrick> jelmer: I see
<tonyyarusso> Next question: is there a way to integrate bzr with nautilus, so the actual bzr processes would be transparent when accessed from a gnome desktop?  (although olive isn't too hard to use either, just another step though)
<jelmer> tonyyarusso: There is nautilus-bzr, but it's less maintained than olive
<mathrick> tonyyarusso: I don't think I understand the "transparent bzr process" thing, but there was something like that, yes
<tonyyarusso> jelmer: ah
 * tonyyarusso shall go experiment
<mathrick> tonyyarusso: I never really believed in file-manager + VCS integration
<foom> mathrick: it's really good for the less-technical users who also have to use the VC system.
 * tonyyarusso is technical enough, just lazy ;)
<mathrick> foom: perhaps, but I can't help but feel the impending abstraction leak
<lifeless> mathrick: there is pack-0.92-subtree
<mathrick> ah, upgrade --help doesn't list the -subtree variants at all
<foom> mathrick: they're hidden so that you won't use them. ;p
<mathrick> why not?
<mathrick> I clearly need them
<mathrick> oh, because of the cannot downgrade thing?
<lifeless> yes
<mathrick> hmm, upgrading to both pack-0.92 and pack0.92-subtree, I get:
<mathrick> bzr: ERROR: Directory not empty: "/home/mathrick/Dev/rails/bzr-pokerolymp2/.bzr/repository": [Errno 39] Directory not empty
<fullermd> I wish we had a progress bar for that inventory building or whatever it is check does while it says it's checking versionedfile 0/xxx...
<mathrick> I've noticed quite a few places where I think bzr used to have progressbars but lost them in 0.9x+
<jelmer> mathrick: in 0.9x specifically or in the new formats?
<mathrick> jelmer: I'm not sure, I just know it happened around 0.9x
<mathrick> okay, I need to sleep
<mathrick> night
<lifeless> mathrick: file a bug on the upgrade error please
<lifeless> abentley: ping
 * igc lunch
<abentley> lifeless: pong
<abentley> poolie: have I missed the window yet?
<spiv> abentley: I don't think so, I think he was intending to make the tarball about an hour from now.
<igc> abentley: well to check in an hour or so if we're ready to go
<igc> if you get stuff into the pqm queue, poolie will most likely wait for it to merge (I'm guessing)
<abentley> Okay, I'm landing the InterDifferingSerializer, because that was a slam dunk.
<abentley> Thanks everyone for the reviewz
<spiv> abentley: thanks for the codez! :)
<lifeless> thumper: I will be a little late, trying to get phone fixed..
<abentley> fullermd, CardinalFang: You can find the least common ancestor with "bzr find-merge-base".  I don't know what the greatest would be.  Presumably revno 0.  You can also find this revision with bzr log BRANCHA -rancestor:BRANCHB --show-ids.
<fullermd> Ooh, I forgot about ancestor:.  Didn't know about find-merge-base.
<lifeless> abentley: I'm trying to remember the rules for inventories and revisions
<abentley> lifeless: Oh?
<lifeless> abentley: like, which inventories have a revision, and what the rules are for it, is it always the creating commit etc
<lifeless> for my new [de]serialiser
<abentley> All inventories have revision-ids that match the revision that created them.
<abentley> There were some format 5 inventories that didn't have them.
<abentley> Basically there were two format 5's, one with no revision-id, and one with a revision id.
<abentley> But format 6 and 7 always have them, and so should new format 5 inventories.
<abentley> fullermd: find-merge-base is hidden, because I figured its only use was for debugging.
<abentley> I'm thinking it might be nice to have a "revision-id" command, though.
<abentley> that just prints the revision id for the revision you specify with a revision spec.
<lifeless> revision-info does that
<fullermd> Well, that would be revision-info | awk  :)
<abentley> lifeless: Perhaps it shouldn't be hidden.
<lifeless> I think hidden is too big a hammer
<lifeless> we kind of want degrees of usefulness ;)
<abentley> mathrick: If you want a branch with a set of working files, that's called a tree.  Use bzr reconfigure --tree if you want that.
<abentley> lifeless: Splitting up commands by topic or tag or something would be fine with me.
<abentley> lifeless: was there anything else you wanted to ask me?
<lifeless> abentley: nope
<mathrick> abentley: but a tree is a set of branches that don't have a hierarchical relationship, no?
<mathrick> mathrick@hatsumi:~/.bazaar/plugins/bisect$ bzr nick http://bzr.licquia.org/bzr-bisect/trunk/
<mathrick> bzr: ERROR: Cannot lock LockDir(http://bzr.licquia.org/bzr-bisect/.bzr/repository/lock): Transport operation not possible: http does not support mkdir()
<mathrick> isn't that a bug? Reading the nick should be well doable
<wam> mathrick: the repository is locked. If there is currently an action, this is ok. If there isn't this could be a stale lock and should be removed.
<mathrick> wam: uhm, it's over HTTP, the error says something different
<mathrick> it's not complaining about stale locks, and I can branch it just fine, it's trying to lock the dir (which fails over HTTP, obviously) for reading the nick
<wam> mathrick: sorry - didn't read carefully enough
<fullermd> I imagine it's more that nobody ever thought of it.
<mathrick> fullermd: thought of what?
<fullermd> Making nick try readonly when it's not writing.
<mathrick> oooh, I get it now
<mathrick> bzr nick http://bzr.licquia.org/bzr-bisect/trunk/ sets the nickname to "http://bzr.licquia.org/bzr-bisect/trunk/"
<mathrick> and I was in a checkout directory
<mathrick> so there's no way to get a nickname of a remote branch
<ubotu> New bug: #180297 in bzr "no way to read the nick of a remote branch" [Undecided,New] https://launchpad.net/bugs/180297
<mathrick> is there an easy way to rewrite the authorship of committed revisions?
<mathrick> ie. I didn't have whoami set properly, now I do
<mathrick> and I'd like to have the previous commits to show the proper info
<Peng> mathrick: I don't think so.
<mwhudson> no, revisions are immutable
<mathrick> meh
<mathrick> I wouldn't mind getting a new repo, it's not shared with anything
<Peng> mathrick: Ok, but I still don't know of a tool to do it.
<zekel> I want to make a branch from a subdirectory in my repo so that it is it's own repo, which I can commit to separately, from which I can merge changes back into the main repo. Help me with the bzr vocab so I can know which method to look up?
<mwhudson> mathrick: it's probably _fairly_ simple bzrlib programming then
<mwhudson> maybe you could trick the rebase plugin into doing it
<zekel> Coming from svn, I could check out any dir in the working tree and not have to carry around a whole repos worth of files. I'm getting confused about checking out versus branching versus I don't know what.
<mwhudson> zekel: bazaar doesn't version trees in the same way svn does
<zekel> That doesn't mean I can't split a subdir and work on it separately, does it?
<Peng> zekel: If you really want to turn it into a separate branch which can still be merged back, this is what subtrees do. The feature has been there for a while now but it still experimental or something.
<Peng> zekel: But that's a lot more than just checking out a subdirectory.
<zekel> That's not the same as bzr split?
<Peng> zekel: Huh. split only requires formats supporting rich roots (metadata about the root directory of the branch), but join requires subtrees.
<zekel> Peng: I'm not sure I get the implication.
<zekel> Also, would the split directory, since it's no longer a part of the main tree typically be moved out to be it's own tree, or should it stay there and somehow be treated differently?
<Peng> zekel: I dunno.
<Peng> zekel: You should only do this if you think the directory should logically be a separate branch, not just to save disk space.
<zekel> Peng: It's not really to save disk space, it's more for path concerns. For example, if you have repo/work/bzr.com I might want to just get bzr.com and move that to my web server directory without it being really long.
<zekel> I tend to nest stuff, but that was with the expectation I wouldn't always have to use the full paths.
 * Peng shrugs.
<zekel> Maybe I should just have a separate repo for each project.
<zekel> Thanks for the advice. EST calls.
<ecognito> Is it possible to do some sort of preview of what files will be effected by a pull operation?
<mwhudson> not yet; there's been talk of it
<ecognito> Thanks.
<Peng> Something with bzr missing?
<CardinalFang> Moin.
<mathrick> mwhudson: doesn't missing do the trick?
<mwhudson> mathrick: doesn't tell you which files will be affected does it?
<mwhudson> or maybe missing -v does that
<CardinalFang> Hi all.  I'm most of the way through my greatest("/latest")-common-ancestor plugin.  I have the intersection of changeset ids of two trees, but it's a set, and so no order.  How can I tell what is latest?  The "-CA" part works, but I need a cmp() to find the "G-".
<mathrick> CardinalFang: did you take a look at how merge does that?
<CardinalFang> mathrick, Eh, I thought so.  I'll look again.
<CardinalFang> I hope I'm not reinventing the wheel.
<mathrick> CardinalFang: don't worry, I had the same feeling when replacing diff_cmd_helper recently :)
 * CardinalFang risks tearing a rip in space by putting his plugin in revision control.
<mathrick> heh
<mathrick> CardinalFang: if that worked, bzr would've destroyed the universe long ago :)
<mwhudson> CardinalFang: uh, what are you trying to do?
<mwhudson> it sounds much like you could use 'bzr revno -r ancestor:../other'
<dato> mwhudson: revno doesn't seem to accept -r
<PainBank> can someone help me out?
<mwhudson> ah, maybe i meant revision-info then
<dato> ooh
<PainBank> I uploaded a small program to test out the ability to use bzr to share code from ftp site... and was wonding if someone can try to download the code?
<PainBank> and let me know if it works or not.
<PainBank> c# program, simple random number generator upon a button click... or at least let me know if you see the code or not.
<PainBank> here is the address:
<PainBank> http://www.detroitcreativetalent.com/SSD/RandomGen/
<PainBank> with the .bzr folder in it.
<dato> PainBank: http://www.detroitcreativetalent.com/SSD/RandomGen/.bzr/branch-format gives a 500 error
<CardinalFang> mwhudson, Ooo.  After a simple test, that looks like what I want.  I wish it were easier to use.   cd X; bzr branch ../Y -r `bzr revision-info -r ancestor:../Y |awk '{ print $2 }'` ../XY-gca    I can add something to make it smaller, I think.
<mwhudson> CardinalFang: sure
<mwhudson> CardinalFang: basically you want the code behind the "ancestor:../some-branch" revisionspec
<CardinalFang> Agreed.  Looking now.
<mwhudson> CardinalFang: which you definitely don't want to re-implement, it's pretty hard core
<CardinalFang> I bet.
<PainBank> @dato Thanks.  Looks like it is a server side problem... or I didn't set something up there correctly.  Will try later.
 * CardinalFang curses Python.
 * Peng gasps.
<CardinalFang> Leakage of the iter name in a list comprehension strikes again.
<Peng> Oh.
<Peng> I think generator expressions are different. :D
<CardinalFang> Yah.  WTF, "str object not callable?"  ...20 minutes...  Oh, my superclass defines a function that I clobber from within a list comp.
<CardinalFang> I did consider "list(yay generator expression)"
<Peng> In Py3k, listcomps will (mostly?) be syntactic sugar for exactly that.
<CardinalFang> I'm actually looking forward to Py3k now, instead of the grim future of retreating into the wilderness after spraypainting on my house a screed containing something about "map" and "cold, dead fingers."
 * CardinalFang reluctantly lets apply() and reduce() go.
<dlee> Random minore observation re: an earlier discussion about wanting bzr progress bars:  I am a blind programmer, and text progress bars tend to cuase LOTS of extra speech besides just letting me know what's happening.  I sometimes mildly wish there was an option to turn those off without turning off other status announcements.
<CardinalFang> That shouldn't be too hard.
<beuno> dlee, have you used Launchpad before?
<dlee> no
<beuno> if not, I can file a bug for you
<beuno> to request that option  :D
<dlee> I'm sure I can, but I haven't gotten to it.
<beuno> dlee, https://bugs.launchpad.net/bzr/+filebug
<beuno> you will need an account first though
<beuno> if it gets too complicated, just give me some specifics and I'll file it for you
<beuno> if you do get a Launchpad account, you can subscribe to the bug and follow it's progress, so I do recommend that
<dlee> I'm actually on the road from Illinois to Virginia atm, ircing via a Virginia FreeBSDD box running IRC; pardon a likely lot of spotty aircard access :)
<CardinalFang> dlee, What shell do you use?  Perhaps a quick fix:  alias bzr="TERM=dumb bzr"
<CardinalFang> dlee, Ah!  Even better:  in your shell, export BZR_PROGRESS_BAR=""
<beuno> dlee, ah, I see, I'll file it for you. You would just like an option for the progress bar to be removed?
<dlee> CardinalFang: Intriguing idea.  I use tcsh mostly under FreeBSD and under Cygwin, and I and some officemates will run bzr from DOS boxes directly in Windows as well.
<dlee> CF:  If there's already an envvar for this, I doubt we need an option for it too :)
<beuno> is there an ennvar for this?
<CardinalFang> bzrlib.progress looks for that environment variable.
<dlee> cool
<beuno> there ya' go, even better. It seems it's just a documentation problem
<CardinalFang> all, Is there a reason why "branch" doesn't set the default location for future pulls and pushes?
<dato> CardinalFang: it does for future *pulls*
<dlee> Now for a perhaps bigger issue:  The following just occurred when I tried to cvs-import my second project.  The first line is my command (with paths generalized as will be obvious), then follows the output:
<dlee> []
<dlee> bzr cvsps-import /<CVSRootPath> company/proj proj
<dlee> Creating cvsps dump file: proj/staging/company_proj.dump
<dlee> Read 306 patchsets (string cache hits: 0, total: 525)
<dlee> Failed while processing: Patchset(17, HEAD, dlee, 2004/01/16 17:09:27)
<dlee> Processed 17 patches (17 new, 0 existing) on 1 branches (1 tags) in 8.4s (2.03 patch/s)
<dlee> bzr: ERROR: rrno 2] No such file or directory: '/home/Doug/proj/bzr/company/proj/tags/projcom_rel040116 **FUNKY**'
<dlee> This is under Cygwin, so my first suspect is file name casing issues :P  This crash leaves a .cvsps dir behind that must be deleted manually, or the next attempt will quickly die with a "not found in cache" error (that I can repro if necessary).
<beuno> I can't find Feisty's .deb for 1.0 in: http://bazaar-vcs.org/releases/debs/feisty/    am I looking in the wrong place?
<dlee> The tag directory complained of, though, really does not exist at this point in the process.
<CardinalFang> Is it possible to set the parent branch without pulling or pushing?
<Peng> CardinalFang: Edit .bzr/branch/parent or .bzr/branch/branch.conf, depending on your branch format.
<CardinalFang> :\
<Peng> CardinalFang: If it's .bzr/branch/parent, you probably need to be wary of putting a \n at the end of the file.
 * CardinalFang horks.
<dlee> Where should I file a bug on this?
<dlee> Cancel; found it (was looking for cvsps, not just cvs); getting LP account...
<dlee> Bug 180408
<ubotu> Launchpad bug 180408 in bzr-cvsps-import "["funky" crash on some Cygwin imports" [Undecided,New] https://launchpad.net/bugs/180408
<ubotu> New bug: #180408 in bzr-cvsps-import "["funky" crash on some Cygwin imports" [Undecided,New] https://launchpad.net/bugs/180408
<dlee> lol I thought I waited long enough
<radix> :)
<Peng> Bah, I make the most trivial commit ever, and pushing it creates a 2.4 MB pack because the remote repo is old.
<fullermd> See, if you'd just made a 200 meg commit instead, you wouldn't notice these problems   :p
<Odd_Bloke> That's why I keep an Ubuntu ISO in all of my repos. :p
<beuno> we should have a plugin for downloading the ISO when doing "bzr init"
<Odd_Bloke> Perhaps we should just ship it with bzr itself, to save on bandwidth.
<beuno> the bundlebuggy merge request will be fun to watch
<fullermd> Yeah, you WONDERED why there was so much effort spent on repo formats that handled large commits well...   now you know!
<Peng> "[MERGE][trivial] Distribute Ubuntu 7.10 with Bazaar"
<Peng> fullermd: I have made a couple 6 MB commits. The 120 MB autopacks over SFTP are nice...
<Odd_Bloke> Heh, imagine the Bundle Buggy merge request when the next version is released. :p
<Peng> Hey, hold on, I do have that ISO.
<Peng> Only 2 gigs of RAM though.
<Peng> Someone on a supercomputer should try it with the DVD ISO. :)
<fullermd> % bzr upgrade --7.10
<beuno> I think using the Ubuntu ISO is a bit biased, we should probably have a mix of all the major distros
<elmo> Peng: you'd need to distribute the source to comply with the GPL too, don't forget
<elmo> ;-)
<fullermd> If we could just rewrite ubuntu in python, it could ship as a plugin...
 * Peng wanders off.
<mathrick> elmo: good thing bzr is a VCS then
<jel> guys... I need to setup a pre-commit hook to update a file in my app with the version number.  The docs seem to suggest putting this in the user's config directory, but I only want this one project to do it?
<jel> Basically I want to dump a python version-info file in the pre-commit of one project.
<CardinalFang> pre-commit hooks must not update the tree delta or future tree.  I just read that.  In big letters and everything.
<CardinalFang> http://doc.bazaar-vcs.org/bzr.dev/en/user-reference/bzr_man.html#hooks
<CardinalFang> jel, maybe you could make a new command that updates and then calls "commit".
<jel> CardinalFang: I guess the most obvious method will be to just create a directory of helper scripts, one of which is commit.  I was hoping for something more integrated -- I still miss the simplicity of rcs's $Id$ :D
<CardinalFang> $Log$ was nice too.
<fullermd> Ugh, $Log$ was teh efil.
<fullermd> I have $Header$'s all over my files, though.
<jel> Yeah, I liked log as well.  No problem, at the end of a file.
<db-keen> Why doesn't the apt repository for bazaar include the latest versions of some programs?
<db-keen> like bzr-svn and bzr-rebase
<CardinalFang> Which APT repo is that, db-keen?
<db-keen> CardinalFang: http://bazaar-vcs.org/releases/debs/gutsy/
<db-keen> it includes Bazaar 1.0, but the version of bzr-svn it includes doesn't work with bzr 1.0
<db-keen> only the latest version does, which is available as a .deb package
<db-keen> http://samba.org/~jelmer/debian/
<abentley> CardinalFang: Also, I tried to tell you yesterday that there's already find-merge-base.  But you left like a minute before I could tell you.
<db-keen> bzr-gtk (olive) is another significant package which is behind
<gryc> is there any way to get a list of all contributors in a bzr branch?
<beuno> gryc, bzr log and grepping through the output comes to mind
<gryc> ah, good idea
<beuno> or even using annotate to know how many lines each person contributed
<gryc> I thought about using annotate, but I'd need some esoteric `find` that ignores .bzr and such
<beuno> gryc, someone made something like that for bzr a while ago, let me check the archive to see if he made the script available
<gryc> okay, thanks
<beuno> gryc, seems like he didn't provide it, no
<beuno> http://article.gmane.org/gmane.comp.version-control.bazaar-ng.general/31364/match=albisetti
<gryc> hrm, well thanks anyway
<beuno> welcome'
<luks> gryc: https://launchpad.net/bzr-stats
<CardinalFang> Hmm.  So, what's the oh-crap-I-didn't-want-to-pull-that-much command.  Remove the last N changesets?
<luks> CardinalFang: uncommit
<CardinalFang> and then "bzr revert"?
<luks> yes
<CardinalFang> I thought I remembered reading about a range to "merge", backwards.  Am I nuts (about that).
<CardinalFang> ?
<beuno> CardinalFang, bzr revert -r X
<beuno> reverts to that specific revision
<luks> CardinalFang: merge backwards with revert a some changes (which means adds a new revision)
<luks> er, s/with/will/
<CardinalFang> Eww.
<CardinalFang> Thanks.
<gryc> luks: thanks for that link to bzr-stats :D
<CardinalFang> Final question for today:  Suppose I work on a part of code for several days.  I commit at several intervals because I want the benefits of SCM.  Suppose I want to make that into one logical changeset before pushing, because my changes are really one unit of stuff, and my intermediate steps are frankly embarrassing.  Is that possible?  My current tool has that, but I haven't seen that for Bazaar yet.
<luks> those intermediate steps are part of the history
<CardinalFang> bzr collapse -r ancestor:parent  ->  like revert and then commit, i suppose.  Hmm.
<luks> hm, bzr collapse?
<CardinalFang> Something I'm making up right now.
<fullermd> Closest would just be doing a diff of all of them together and patch a fresh tree.
<luks> you can simply make a new branch, bzr merge -r X..Y and commit
<foom> what i'd like, which no tool has today, is the ability to *keep* that history for myself, but to collapse it for the consumption of others, and yet have merges know that they're the same thing.
<fullermd> You'd probably want to do a revert --forget-merges in the middle there.
<CardinalFang> Yeah.  And the commit messages are lost with "bzr revert" also.  :(
<luks> bzr revert reverts only the working tree, no revisions
<fullermd> revert --forget-merges doesn't touch the working tree, it just drops the pending merge revs.
<CardinalFang> I'm not really trying to hide anything.  I just want it one logical unit.  "changeset 47" is my work for that week.
<fullermd> You could also just uncommit back and then recommit the real changes.
<fullermd> All pretty much equivalent under the hood, just different expressions.
<luks> CardinalFang: why not just merge it?
<fullermd> Well, that's why we have the special treatment of left-side history   :)
<CardinalFang> Oops I said "revert" a few times when I meant "uncommit".
<luks> then all the revisions would be grouped under one logical unit
<foom> yes, bzr automatically "hides" the intermediate commits into the merge commit
 * CardinalFang is eager for "gcommit" to load the previously saved commit messages.
#bzr 2008-01-05
<spiv> foom: hmm, it'd be possible to do that, I think.
<spiv> foom: roughly, by merging your changes onto a copy of the branch you want to submit to and making a revision of that (i.e. so you'd have a revision with your changes in it, and two parents: the tip of the target branch, and the tip of your private branch).
<spiv> foom: and then by sending just that one new revision to be merged, so that the reference to your revision would be a ghost.
<spiv> s/to your revision/to your revision on the private branch/
<spiv> There's no easy UI for that at the moment, but it's certainly technically possible.
<fullermd> The problem with that is that you have to take a lot of care to avoid ever letting those revs slip out.
<bagueros> hi
<bagueros> i am merging with another branch
<bagueros> and for some reason, it is taking a bunch of files
<bagueros> -D them from my branch
<bagueros> and then +N from the inbound merge branch
<bagueros> why would this happen?
<dlee> Belated entry into the discussion of how to have hidden subcommits "collapsed" into one big one:  I thought the following scenario caused subcommits:  bzr bind remoteBranch, bzr commit --local ... (x how many subcommits you want), bzr update, bzr commit ... (to send them all at once as one).  I think the subcommit revnos end up dotted and the big final one is a normal integer revno.  Maybe not "hidden," but at least logically distinct (an
<forsaken> when i do my initial import it says it ignored a bunch of files, are these dot files?
<lifeless> bagueros: the other branch deleted and added those files?
<lifeless> forsaken: probably - bzr ignored will tell you
<forsaken> ah, neat
<forsaken> bzr is kickass
<Stavros> can i use qbzr on a mac?
<Stavros> or is there a bzr gui for macs?
<luks> qbzr is not really a bzr gui (yet)
<luks> it provides gui for some operations, but you will use it from the command line
<Stavros> well, it's more than the command line..
<Stavros> i know, i don't mind
<luks> the hard part is compiling of pyqt4, I'm not aware of pre-compiled binaries for mac
<Stavros> hmm
<Stavros> and macports only has pyqt3
<Stavros> damn macs
<Stavros> any other guis?
<luks> not sure if installing gtk is easier :)
<Stavros> hmm
<Stavros> osx comes with X11 installed, not sure which gui toolkit it has though
<luks> it's probably just the X server
<luks> but I think doesn't use X11 on mac now, does it?
<luks> er, gtk doesn't use
<Stavros> i think it does, e.g. the gimp does use it
<Stavros> isn't it gtk?
<luks> ah
<luks> yes
<Stavros> yeah
<Stavros> bah
<Stavros> i thought macs had as good support as linux, but it's apparently worse than windows
<luks> hm, http://phanatic.hu/archives/2007/11/building-qt-4-and-pyqt-on-mac-os-x-leopard/
<luks> it has some leopard binaries
<Stavros> oh, great
<Stavros> let me try them out
<Stavros> hmm, would a linux binary run on the mac (bsd?)
<luks> I don't think so
<Stavros> ah
 * TFKyle sort of doubts it, as MacOSX uses MachO not ELF (though it might be able to load ELF's, dunno)
<Stavros> hmm, i'll try it and see, then
<Stavros> for some reason it won't compile on the mac
<TFKyle> pastebin the errors you're getting? (though most likely I won't be able to help)
<Stavros> ah, it's not bzr-related, it's for an assignment
<Stavros> it's missing some library...
<TFKyle> ah
<Stavros> hmm, now it needs sipdistutils
<Stavros> qbzr, i mean
<ushimitsudoki> Just got done making changes, but "bzr commit" gives "no changes to commit"?
<Stavros> do a bzr status?
<ushimitsudoki> stavros: the status gives "unknown"
<dOb> why do some files and directories show up as unkown in 'bzr status' even after I do 'bzr add'?
<Stavros> dOb: you have to ignore them
<Stavros> ushimitsudoki: have you added the files you made changes to?
<ushimitsudoki> Stavros: just now :) I did "bzr add *"
<Stavros> 2
<Stavros> err, sorry
<Stavros> ushimitsudoki: you need to add them and then commit
<ushimitsudoki> Stavros: I see...to be clear, anytime I create a new file, I need to add it manually?
<Stavros> ushimitsudoki: i think so, yes
<ushimitsudoki> Stavros: alright then, I will keep that in mind! Thanks much for the assist to the newbie!
<Stavros> no problem :)
<dOb> Stavros: you mean ignore them as in it's a bug or as in I don't want them in my repo? Because I _do_ want them in my repo :)
<Stavros> dOb: no, "bzr help ignore" :P
<dOb> hmm... is the .bzr supposed to exist only in the top level dir?
<Stavros> yes
<dOb> ok I had a .bzr in the subdir that was showing some files as unknowns in 'bzr status', I renamed it and now everything is working as expected :)
<Stavros> ah, good :)
<Stavros> where can i find sipdistutils for qbzr?
<jaalto> Is there a way to check which format the repository currenly uses?
<dato> jaalto: bzr info
<jaalto> Thanks
<LarstiQ> -away
<LarstiQ> meh, I keep making mistakes on this layout
<jelmer> hey larstiq (-:
<LarstiQ> hey jelmer Ã=
 * LarstiQ sighs
<LarstiQ> :) even
<jelmer> LarstiQ: happy 2008 (-:
<LarstiQ> jelmer: thanks, you too :)
<LarstiQ> and to dato
<jelmer> dato: Do you know why the bzr Debian package depends on graphviz?
<LarstiQ> jelmer: bzr or bzrtools/
<jelmer> bzr
<jelmer> http://packages.debian.org/source/sid/bzr
<jelmer> well, it's a build-depends
<dato> jelmer: the changelog says: performance.png or however it's called
<dato> hi LarstiQ, happy new year to you too
<jelmer> dato: ah, thanks
<LarstiQ> dato: thanks, just went out to buy a dishwasher, that will be a happy change at least ;)
<dato> :)
<jelmer> LarstiQ: you lucky bastard :-P
<LarstiQ> jelmer: I'm afraid luck doesn't have much to do with it :-P
<ubotu> New bug: #180588 in bzr "bzr viz ERROR (bzr 1.0.0)" [Undecided,New] https://launchpad.net/bugs/180588
<mtaylor> hey all... is there a way for a command to store information somewhere that commit will pick up?
<mtaylor> like, if I was writing something similar to uncommit that wanted to preserve the commit message and prepopulate the commit message when the changes are recommitted?
<jelmer> not that I'm aware of
<jelmer> there's the -F option to commit, which allows you to specify the commit message in a file
<jelmer> but I guess you're looking for something that doesn't require additional arguments and would use other metadata as well?
<mwhudson> sounds like a job for a plugin
<mtaylor> jelmer: yes
<mtaylor> jelmer: I can't populate the commit message with a pre-commit hook, can I?
<jelmer> mtaylor: I don't think you can. You can "wrap" the commit command though and modify its behaviour that way
<mtaylor> jelmer: can I "wrap" it with a plugin in such a way that bzr commit calls my wrapping command? Or would need to make a special_commit command or somehting?
<jelmer> mtaylor: yes, you can
<jelmer> my bzr-nm plugin does that for commit as well
<mtaylor> jelmer: great! I'll go look at that
<jelmer> it's a bit of a hack, but works quite well
<mtaylor> hey - I'm not opposed to a hack
<radix> out of curiosity, what if you want to use both bzr-nm and mtaylor's plugin?
<radix> will you get both behaviors with 'bzr commit'?
<mtaylor> radix: good question!
<radix> (assuming use of whatever wrapping mechanism you're talking about)
<jelmer> radix: Yes, although I'm not sure what happens if you have two plugins where one depends on the behaviour of the other
<jelmer> that could get messy
<ryanakca> is this an ubuntu or bzr bug? http://pastebin.ca/842927
<ryanakca> or is it a luser (aka me) error, even?
<jelmer> user error or bzr bug
<jelmer> try bzr ls | grep ".*~"
<jelmer> without those quotes *~ gets expanded to a list of all files ending in ~ in the current directory
<jelmer> so grep probably gets more than one argument and thus ignores stdin
<ryanakca> jelmer: it's a user error... my bad, carry on :)
<jelmer> and that causes bzr to complain about a broken pipe
 * ryanakca nods
<jelmer> ryanakca: this probably shouldn't be a backtrace imnsho
<jelmer> just "bzr: Broken pipe" would be more appropriate
<jelmer> hence why I said it could  be considered a bzr bug :-)
<ryanakca> :)
<mtaylor> jelmer: you don't own bzr-email, do you?
<mtaylor> jelmer: and related to that - where can I find bzr-nm... google isn't seeming to find it
<jelmer> mtaylor: lifeless owns it I think, I'm just the Debian maintainer
<jelmer> mtaylor: bzr-nm should be listed on the plugin registry
<mtaylor> jelmer: k. thanks!
<benny99> hi
<benny99> is there something like a "bzr-miniserver" that doesn't require any web or ftp server?
<benny99> the bzr smart server sounds like something completely different
<jelmer> benny99: yeah, there's the smart server, or sftp
<benny99> jelmer: ok, thanks
<benny99> :)
<dlee> Ok this will probably embarrass me, but... What's the proper way to see what's different between revisions in two branches--for example, diff of r48 in one branch against the tip of the other?
<dlee> "bzr diff .:48 ../dgl" (issued in the first branch's dir) complains that the revisions are on two different branches.  But I know that. :-)
<stefanv> hey guys, can anyone tell me what the current situation is with line-endings on different platforms in bzr?
<dlee> Others can surely answer better than I can, but I believe at this point, the line endings on a file remain as they are when you check the file in, no matter from which OS/platform.  In other words, I am not aware of any conversion of line endings in Bazaar at all.
<stefanv> OK, thanks.  I saw that the roadmap includes a blueprint to change this, so I was just wondering whether that had been implemented yet.
<mtaylor> anybody have any debs of bzr-gtk for gutsy anywhere?
<mtaylor> bzr-gtk: Depends: bzr (< 0.91~) but 1.0-2~bazaar1~gutsy1 is to be installed
<jelmer> mtaylor: I don't think there are any outside of the regular gutsy repo
<mtaylor> jelmer: aw. darnit
 * dlee is surprised there's no answer to his diff-of-branches question; I figured I was missing something obvious.
 * mtaylor makes the requsite complaint about the need for a bzr apt repos with up-to-date stuff...
<mtaylor> jelmer: while I'm bugging you... do you know if commit messages for uncommitted revs are stored somewhere?
#bzr 2008-01-06
<jelmer> mtaylor: You mean if you abort a commit halfway through?
<mtaylor> mtaylor: no, I mean if you run bzr uncommit
<mtaylor> carap
<mtaylor> jelmer: although I suppose aborting commit halfway through might be interesting too
<thatch> dlee: are the branches related?
<jelmer> mtaylor: maybe in bzr_log.*~ in the cwd
<dlee> thatch: Yes, one formed the other at some point.
<dlee> Actually, this particular situation came from a cvsps-import:  I think the "dgl" branch was a CVS vendor import, and "head" was used from then on.  But dgl contains 48 revisions in bzr, and I want to see if anything diverged, because I actually don't *know* that "dgl" was an import branch.
<dlee> But I asked a generic question because I've wanted this sort of comparison in less peculiar circumstances. :)
<LeMec> hi! can somebody remember me where is this chat logged? I have discussed in the past here about Mac support
<LeMec> and I would like to check if there was something more said on the topic
<LeMec> well, I've seached around and it looks like except the lucky win users and those using the Leopard distro there is no nice installer
<mtaylor> LeMec: there's an IRC link on the inside.mysql.com homepage
<mtaylor> LeMec: I believe it links to the place where the logs are
<mtaylor> LeMec: nevermind... wrong IRC window
<mtaylor> :)
<thatch> LeMec: bzr.arbash-meinel.com/irc_log/bzr/ last I knew for logs
<LeMec> thatch: it works thanks! wouldn't it be nice to have this link in the topic? so newbies are seeing it immediately?
<thatch> LeMec: I think it's because they're unofficial?
<LeMec> does it really count? I think unofficial is still better than nothing, isn't it?
<Verterok> thatch, LeMac: I think http://irclogs.ubuntu.com/ is what you are looking for ;)
<Qhestion> is there a command to merge a local branch into a foreign branch (!)
<Qhestion> foreign=remote
<Odd_Bloke> Qhestion: You could create a local copy of the remote branch, perorform the merge and then push it to the remote location.
<Odd_Bloke> *perform
<Qhestion> too complicated.
<Qhestion> well, i would just use a checkout but...
<Odd_Bloke> Qhestion: It's three commands, that's not especially complicated...
<Qhestion> why three? why not one?!
<Qhestion> i am working from 3 computers on the same thing. problem is, the path to the central repository changes.
<Qhestion> so i would have to unbind/bind for nearly every commit.
<Qhestion> (once a day. not a problem, but definitely not elegant)
<Odd_Bloke> Because merging into a remote repository where you can't fix conflicts is a Bad Idea.
<Odd_Bloke> s/repository/branch/
<Qhestion> hmm sounds logical.
<ale666> hi guys, i have just installed bzr. where is the revision downloaded?
<ale666> and i have downloaded a branck of a project but i dont know where it is
<thumper> ale666: what did you type?
<thumper> ale666: sorry, 1am here and time to sleep
<ale666> good night :) i figured it out. bzr is so nice!
<JordanC> Ahoy
<JordanC> Are there windows-based bzr clients?
<JordanC> (That have been released)
<Peng> Windows-based?
<JordanC> Yup
<mtaylor> well, there's bzr
<mtaylor> which works on windows. :)
<JordanC> GUI based? :P
<mtaylor> I think someone is working on a tortoisebzr but I really don't know
<mtaylor> there's also a visual studio plugin... but again, I'm not sure of the status
<Peng> There are multiple GUI plugins. QBzr, TortoiseBzr, bzr-gtk.
<JordanC> QBzr is wierd
<JordanC> But it works :D
 * Peng shrugs.
<Peng> I don't use any of them.
<Peng> Partly because I'm happy with the command line, partly because I don't want to figure out how to install PyQt and whatnot. :P
<luks> Peng, apt-get install python-qt4 :)
<luks> JordanC, the current qbzr is not intented to be a "bzr gui", just a tool to help with tasks where the command line is not enough. is that the weird part, or is it something else?
<mtaylor> when I send a merge directive, it lists target_branch: and source_branch: in the human readable comments
<mtaylor> if I open the revision bundle, are those stored within? Or do I need to parse them from the comments?
 * mtaylor guesses the second, but I thought I'd check
<beuno> mtaylor, bundles are generated with the commit's metadata, including the comment
<jelmer> mtaylor: The merge directive parser should be able to return them to you
 * dato would *guess* that the source branch is not in the bundle
<mtaylor> jelmer: know where I'd look for the parser? is that in merge_directive.py ? :)
<jelmer> the source branch can be in the bundle because you should be able to send a merge directive without a patch
<mtaylor> mmm right
<jelmer> yes
<mtaylor> so I
<jelmer> You can call MergeDirective.from_lines()
<mtaylor> ha! I was just about to ask if that was the one. great! thanks
<mtaylor> ROCK
<mtaylor> that's fan-frickin-tastic
<jelmer> :-)
<lifeless> thumper: reminding you to mail me :)
<thumper> lifeless: ta
<jelmer> 'morning lifeless
<jelmer> lifeless: what sort of format changes do you plan to work on?
<lifeless> jelmer: journalled inventories for now
<lifeless> theres a ton of stuff in the queue; but I'll probably take a break from bzr at some point ;)
<lifeless> file_ids are a big bugbear right in my target sights
<jelmer> hmm, that's a word I had to look up :-)
<jelmer> it would be awesome if file ids could be made more flexible or replaced by sometihng better
<lifeless> path tokens
<lifeless> is my current plan
<lifeless> basically memoising the revision-path graph of a path object, allowing for splits and joins (allowing one requires the other for reversability)
<jelmer> ah, nice. I didn't know path tokens were that concrete already
<jelmer> I really need to finish that shallow branches code as I have been promising for the last half a year
<Peng> Would this help with copies?
<jelmer> Peng: yes
<lifeless> Peng: by 'help' do you mean 'allow' ? :)
<Peng> lifeless: Heh, yes.
<Peng> That sounds good.
<Peng> What are path tokens?
<lifeless> Peng: yes, and also the reverse - combining two files that were separate into one.
<lifeless> or directories for that matter.
<Peng> That sounds nice.
<lifeless> path tokens are the code name I gave the concept
<Peng> How's it work?
<lifeless> I mailed the list a whlie back
<lifeless> we ended up talking about whether copies were desirable
<thumper> lifeless: what is Branch format 6?
<thumper> is that the tags one?
<Peng> Yes.
<thumper> Peng: ta
<thumper> if I have a repository on one machine that is corrupt by missing a knit index file
<thumper> how can I get a client to push enough to fix it?
<lifeless> you can't
<lifeless> we only check references as we push, so to push everything you need to remove all the revisions
<thumper> I was going to move the .bzr directory
<thumper> a repush would fix yes?
<dlee> thumper: repush?
<thumper> dlee: what I ment was push again
<dlee> lol ok...thought this might be another hidden command :)
<dlee> ... there being a remerge and all
<Peng> 'bzr help criss-cross' needs to be updated for LCA merge, doesn't it?
<j1mc> hi all - i was wondering if bzr revision control would even work on openoffice docs.  does anyone know?
<Peng> Well sure, it can store any sort of file.
<Peng> No diffing or merging though.
<lifeless> there is a plugin to diff oo files
<Peng> Nice.
<j1mc> lifeless and Peng ... thanks.  :)
#bzr 2008-12-29
<vila> hi all
 * fullermd waves at vila.
<davidstrauss> hi
<davidstrauss> (in delayed response to earlier greetings)
<Peng_> Good morning. (Hey, I came in under an hour!)
<bvk> hi, is it possible to create a branch without copying full repository?
<vila> bvk: creating a branch copy only the needed revisions from the repository, using a shared repository may help as opposed to standalone branches though
<bvk> vila: i tried shared repositories; bzr branch inside a shared repo takes same disk space as any other branch :(
<vila> bvk: I can assure you that branches inside share repos use less space than standalone branches :-)
<vila> bvk: if only because branches inside shared repos doesn't have repository folders inside their .bzr folder
<vila> bvk: issuing 'bzr info' inside your branch folders will tell you *where* the branch repo is (whether it's shared or not)
<bvk> vila: let me check again :(
<fullermd> Whoah.  I didn't know bzr info could do that...
<bvk> vila: i am not sure you got my last two messages or not :( pasting here again
<bvk> vila: http://pastebin.com/ff5489a6
<bvk> vila: what am i doing wrong there?
<vila> bvk: you're measuring your working trees not your branches, try 'du -sk .bzr' in your ' x', 'a', 'trunk' and 'a1' folders
<vila> shared repo are meant to share branches not working trees, may be you're after --hardlink in 'bzr help branch' instead ?
<vila> fullermd: you're kidding ?
<bvk> vila: okay, i got it now, thanks :D
<fullermd> vila: Hm?
<vila> fullermd: I thought you knew all options of all bzr commands by heart and you said: "Whoah.  I didn't know bzr info could do that..."... hence my surprise (or it was a joke that I totally missed :-)
<fullermd> Oh.  I meant I didn't know it could knock you off IRC   ;)
<vila> lol, indeed I missed it :)
 * fullermd pours another cup of coffee for vila.
<fullermd> Silly mondays   :)
<loffe> What is the "best" way to convert a svn project into bzr? bzr svn-import gives me a segfault :(
<asabil> loffe: did you try fast-import ?
<loffe> asabil, Couldn't get it to work...
<loffe> asabil, svn.core.SubversionException: ("Can't open file 'https:/loffe@svn2.assembla.com/svn/tidsredovisning/format': No such file or directory", 2)
<smoothice> loffe: https:/
<smoothice> loffe: You need two slashes?
<loffe> smoothice, yes, I have two slashes in my command
<smoothice> loffe: ok
<loffe> ~/.bazaar/plugins/fastimport/exporters/svn-fast-export.py https://loffe@svn2.assembla.com/svn/tidsredovisning | bzr fast-import -
<asabil> loffe: http://bazaar-vcs.org/BzrMigration#head-45d1d93c64578685cc2c942204f8a31840a5fa67
<asabil> did you take a look at this ?
<loffe> asabil, yes, of couse
<Peng_> loffe: Try using "svn+https" instead of "https" as the protocol.
<smoothice> Peng_: I think thatâs only necessary when you're using SSH (svn+ssh)
<Peng_> smoothice: When using http(s), it helps work around some issues.
<smoothice> Peng_: Ah, ok
<loffe> Nope, it didn't work
<loffe> same error
<Peng_> D'oh. Sorry, I don't know, then.
<Peng_> loffe: bzr-svn 0.4 or 0.5? You could try the other.
<Peng_> Sorry, I don't know much about bzr-svn. Poke jelmer...who /quit 15 minutes ago. Erm.
<asabil> loffe: from the svn-fast-export script doc, it seems like you need a local copy of the repository
<loffe> asabil, ok, I just got a dump file
<loffe> going to fiddle a bit with it. I maybe have to setup a whole local repo..
<asabil> oki
<loffe> asabil, I think I made it :D
<asabil> great :)
<asabil> did you have to setup a local repo ?
<Peng_> loffe: You should still bother jelmer about your bzr-svn issues, next time you see him.
<asabil> or just using the dump file ?
<loffe> asabil, local repo
<asabil> oki
<loffe> never used svnadmin before. Assembla was great and simple, until their policy changed :(
<Peng_> Policy?
<fullermd> Wait.  jelmer not on IRC?  Isn't that one of those tipoffs that you're actually dreaming?
<Peng_> Hmm, maybe I fell asleep while I was watching TV?
<loffe> Peng, now they don't allow a free private space
<Peng_> But why would the fullermd in my dream tell me it's a dream?
<Peng_> And shouldn't I be doing something more interesting?
<Peng_> loffe: Oh. Huh.
<asabil> loffe: moving to launchpad now ?
<loffe> asabil, nope, it's not a open source project
<fullermd> Peng_: Maybe you're only dreaming that I'm in your dream telling you it's a drea@*%@!#   Error: stack depth exceeded.
<asabil> oh oki
<loffe> asabil, unless lp provides private space?
<asabil> I am not aware of that
<Peng_> fullermd: If you crash my dream, will I wake up or die or something?
<fullermd> Peng_: Maybe being awake is just the debugger prompt of your dreams.
<fullermd> That would explain why in dreams you get from point A to point B so much faster; when you're awake, you're always single-stepping.
<Peng_> That's..um..if I think about that, I think I'll get really creeped out.
<fullermd> My work here is done   :)
<beuno> hello hello!
<Peng_> Good morning.
<beuno> anyone know why bzr would get angry at me when trying to upgrade to 1.9?
<beuno> bzr: ERROR: Invalid url supplied to transport: "%E1ngulo-corte_globo_thumb.jpg": Unable to encode the URL as utf-8: 'utf8' codec can't decode bytes in position 0-2: invalid data
<beuno> hiya Peng_
<Peng_> That's a neat error, but I definitely can't help. Sorry.
<Peng_> Upgrading tries to open transports on files?
 * beuno looks at vila hiding in the corner
<Peng_> Maybe it's bzr-svn's doing?
<beuno> Peng_, no svn involved at all
<Peng_> Yeah, but do you have bzr-svn enabled?
<beuno> the error, I believe, doesn't come from the transport really, it's just because I'm using the --recurse plugin
<beuno> no, no svn in like 50 miles from here  :)
<Peng_> Heh.
<beuno> hrm
<beuno> I'm getting problems upgrading all over the place...
 * beuno files a bug
<vila> beuno: what is the --recurse plugin ?
<beuno> vila, it upgrades all the branches in a dir recursively
<beuno> but, upgrading manually gives me the same error
<beuno> :(
<beuno> about 20% of my branches are having problems upgrading
<vila> beuno: great, you just ruled out the plugin :)
<beuno> vila, http://paste.ubuntu.com/95218/
<beuno> I'm running 1.10 on the server
<beuno> in case you're curious enough to help  ;)
<vila> beuno: I'm about to call it a day :-/
<beuno> although, that's the traceback *with* the plugin...
<beuno> vila, no worries, I'll file a bug
<beuno> enjoy you're vacations  :)
<vila> beuno: but rough intuition: your traceback in the plugin smells like double-escaping
<beuno> ah
<beuno> it is!
<vila> of course that doesn't match your report as you get the same error without the plugin
<beuno> vila, it turns out the plugin sticks it's nose in even if you don't use it
<vila> and your 20% was suspicious too, did you mean %20 instead ? :-)
<beuno> hahah
<beuno> ok, removing the plugin fixes the upgrades
<beuno> I
<beuno> I'll fix the plugin and send a patch to jelmer
<beuno> thanks vila
 * vila can call it a day happily then :-)
<LarstiQ> beuno: thanks for the hug ;)
<beuno> LarstiQ, :)
<beuno> jelmer!   just the man I was looking for...
<Peng_> jelmer: Internet troubles?
<LarstiQ> I don't see jelmer around here
<beuno> LarstiQ, is he at the CCC as well?
<LarstiQ> though he is supposed to go along for dinner
<LarstiQ> beuno: yup
<Peng_> CCC?
<LarstiQ> Peng_: http://events.ccc.de/
<LarstiQ> ah, he is sitting 15 meters away
 * LarstiQ detaches for dinner
<Kobaz> okay
<Kobaz> so umm
<Kobaz> i'm getting this wiggity problem
<Kobaz> $ bzr push
<Kobaz> RemoteRepository(https://user@bzr.local/bzr/myProject/webServices/.bzr/) is not compatible with
<Kobaz> KnitPackRepository('file:///usr/home/user/projects/webServices/.bzr/repository/') (no details)
<Kobaz> oh. i forgot to use bzr+https
<Kobaz> hmm
<Kobaz> never mind
<smoothice> Is it possible to do Bazaar transactions over HTTP like you can SVN?
<beuno> smoothice, with webdav, yes
<smoothice> beuno: I thought only SVN can do WebDAV
<smoothice> bueno: Any guides on doing that?
<Peng_> smoothice: There's a webdav plugin somewhere or other (check http://bazaar-vcs.org/BzrPlugins ). I don't think it works 100%.
<smoothice> Peng_: ok
<loffe> How can I keep an updated working-tree on a remote server?
<loffe> I know I can push to a remote host creating a branch, but I get no files on the server, only the .bzr dir
<Peng_> loffe: push-and-update plugin
<Peng_> loffe: Though you have to create a working tree ("bzr co") before it'll act.
<loffe> Peng, I don't have bzr on the remote server
<loffe> it's a webhost...
<Peng_> loffe: bzr-upload?
<Peng_> Your web host is boring! :P
<loffe> Peng, :P
<smoothice> If I have a client running bazaar 1.10 but a Server running 1.9 and the 1.10 client runs bazaar commands over bzr+ssh will there be conflicts?
<smoothice> In other words, are 1.10 repositories backwards compatible?
<smoothice> anyone?
<Peng_> smoothice: 1.10 doesn't introduce any new formats.
<Peng_> smoothice: If something isn't backwards-compatible, it's a bug.
<smoothice> Peng_: Ok... I was just wondering since I have a Mac OS X 10.4 server with a 10.5 client
<Peng_> (Well, the oldest hpss protocol was dropped recently, wasn't it?)
<smoothice> Peng_: I updated my 10.4 server to Python 2.6.1 and when I try to install Bazaar 1.9 it says "please upgrade to python 2.5"
<Peng_> smoothice: Heh. Erm.
<smoothice> Peng_: :/
<Peng_> smoothice: Python 2.6 should be supported, but it doesn't seem to have been added to the 'bzr' script. You could try editing it in.
<smoothice> Peng_: how would I do that?
<Peng_> smoothice: (Just change KNOWN_PYTHONS)
<smoothice> Peng_: Where is that?
<Peng_> smoothice: ...in the "bzr" script
<smoothice> Peng_: "bzr" script? huh?
<Peng_> smoothice: The executable you run to run Bazaar.
<smoothice> Peng_: The installer won't even let me install Bazaar.
<Peng_> Err, I'm sorry about the problems, but I don't really know what to do here.
<smoothice> Peng_: ok
<Peng_> If you install from source, it would be easy to work around.
<smoothice> Peng_: Where can I download the 1.9 source? I only see the trunk...
<verterok> smoothice: what installer are you using? the dmg?
<smoothice> verterok: Yeah
<verterok> smoothice: the installer check if Python25 is installed, and assumes you have and older version :/
<smoothice> verterok: yeah
 * verterok 's fault
<verterok> :)
<smoothice> verterok: Oh.. it was YOU!
<smoothice> verterok: ok
 * verterok hides
<verterok> smoothice: I'll fix that in the upcomming 1.10 installer (apologize the delay)
<smoothice> verterok: for Mac OS X 10.4?
<verterok> smoothice: yeap
<smoothice> verterok: Is it possible you could send me a patch for 1.9 source so I can get 1.9 installed asap? Or does that not make logical sense?
<verterok> smoothice: the problem isn't bzr is the installer checking for python25
<smoothice> verterok: Can you recreate the 1.9 package?
<verterok> smoothice: I was about to said that ;). if you can wait a while I 'll rebuild the 1.9 installer and change the 2.5 check
<smoothice> verterok: sure
<verterok> smoothice: ok, booting my ibook to build it, I'll let you know when it's done
<smoothice> verterok: ok thanks... I'll stay here. I might be afk for a while but I'll get either a private message or a message directed toward me eventually...
<Kobaz> ignored perl/lib/perl5/i486-linux-gnu-thread-multi/auto/DBI/DBI.so matching "*.so"
<Kobaz> why is bzr ignoreing my .so files
<Kobaz> i never added *.so to bzr ignore
<Peng_> Kobaz: bzr comes with a default ignore list.
<Peng_> Kobaz: Errm, check ~/.bazaar/ignore. I'm not sure if you can edit it.
<smoothice> Peng_: Yep.. .so is in that list
<Kobaz> k
<Kobaz> ah
<Kobaz> i see it
<smoothice> verterok: How's it coming? good?
<verterok> smoothice: all good, uploading ATM
<smoothice> verterok: Ok... are you going to replace the .dmg on the Bazaar web site or simply provide me with it? or something
<verterok> smoothice: I can't replace it, so it'll be new version of the installer. I'ld like to test it first :) so I'm uploading it to a non-launchpad place so you can get it
<verterok> smoothice: ~ 8 min to finish the upload
<smoothice> verterok: ok
<verterok> smoothice: btw, to grab the sources of bzr: https://launchpad.net/bzr/+download
<smoothice> verterok: ok
<verterok> smoothice: http://verterok.com.ar/DMG-1.9-1/
<smoothice> Thanks
<smoothice> verterok: Got it thanks
<verterok> smoothice: let me know if the fix works, if not I'll need to add a special case to test for 2.6 installation
<smoothice> verterok: There was an error while evaluating JavaScript for the package.
<verterok> smoothice: ok, let me check
<smoothice> verterok: ok
<verterok> smoothice: python 2.6 is installed in: /Library/Frameworks/Python.framework/Versions/2.6/ ?
<smoothice> verterok: yes
<beuno> verterok!  hi!
<verterok> beuno: hi!
<verterok> smoothice: ok, I missed that bit :p
<smoothice> verterok: I have to go eat lunch... just send the link the same way you did before and I'll get it
<smoothice> verterok: I'll stay on IRC, just afk
<verterok> smoothice: ok
<smoothice> verterok: ok back
<smoothice> verterok: done yet? did you find the javascript issue?
<verterok> smoothice: ok, I think I found the problem.
<smoothice> verterok: ok
<verterok> smoothice: the problem is I'm building the installer against python 2.5 :/
<smoothice> verterok: oh haha
<verterok> smoothice: so Crypto, etc. are linked against 2.5
<verterok> smoothice: I need to install 2.6 in order to build the installer
<smoothice> verterok: ok... that isn't bad it? Like you do you _need_ 2.5?
<verterok> if you need this ASAP, maybe it's easier for you to run from source
<smoothice> verterok: As soon as possible would be preferable... and I can do anything to help if you need...
<verterok> smoothice: isn't bad, but I need to check the whole build process, and install the dependencies in the new python 2.6 installation (mpkg_dmg, etc.)
<smoothice> verterok: How do I run from source?
<verterok> smoothice: install the dependencies: paramiko and pycrypto
<smoothice> verterok: how do I do that?
<verterok> smoothice: I'm looking for the url's
<smoothice> verterok: ok
<smoothice> verterok: Would it just be easier to downgrade to 2.5.2? Is that even possible?
<verterok> smoothice: http://bazaar-vcs.org/InstallationFaq
<verterok> smoothice: I'm quite sure you can have 2.5.x installed side-by-side with 2.6.x
<smoothice> verterok: I guess it's worth a try...
<verterok> smoothice: in the meantime, I'll start my 2.6 setup
<Jc2k> jelmer: ping
<smoothice> verterok: Should I get 2.5.2 or 2.5.4? or .3
<verterok> smoothice: the latest 2.5.x should be ok (me thinks)
<verterok> smoothice: I have 2.5.2
<smoothice> verterok: Ok I'll try the latest... 2.5.4
<smoothice> verterok: Ok I got 2.5.4 working and the installer works
<verterok> smoothice: cool
<beuno> so...
<beuno> does bzrlib tell me in any way when an upgrade succeeds?
<nDuff> beuno, I would expect it to return without throwing an exception; that's the way most things indicate that they've succeeded in python, all the way down to os.chdir()
<nDuff> beuno, this isn't C, where everything has a return value that needs to be explicitly checked. :)
<beuno> I kinda expect that too, but since I'm tweaking a plugin to recursively upgrade and delete the backup dir if it succeeds, I'm trying to ensure the maximum degree of success possible  :)
<abentley> beuno: I recommend not deleting the backup dir.  There is no way to be absolutely certain that a backup succeeded, and the consequences of failure may be grave.
<abentley> beuno: Also, I think that recursive upgrading should be core functionality.
<beuno> abentley, I need to upgrade 100+ branches
<beuno> and I don't have the space to have the backup dir on it
<beuno> so I don't really have a choice  :(
<abentley> beuno: That is a shame.  Perhaps you should make a backup somewhere else first, then.
<beuno> there's a plugin from jelmer to do recursive upgrade, maybe I'll take a crack at shaping it into a patch for the core
<beuno> abentley, I have a backup already  :)
<beuno> so I'm ready to upgrade all the branches at the office to 1.9!
<abentley> beuno: Great.  What I mean about "absolutely certain" is that, despite our testing, there's a small chance that the upgrade code is buggy.
<nDuff> beuno, you might consider moving to a rich-root format at the same time -- might make things less painful for you whenever bzr upstream finally switches to rich-root-by-default by getting all the pain (for you, at least) over at the same time.
<beuno> abentley, right, I've heard rumours. I do have a backup, but in general, I haven't had a backup break since 0.11. Maybe I can add an extra check that tries 'bzr info' or something among those lines
<abentley> beuno: I haven't heard rumours, it's just worth being paranoid when the stakes are that big.
<beuno> abentley, I know  :)
<beuno> w00t!
<beuno> script works
<beuno> now I have to get it to stop choking on encoding problems, and I can run it through all the branches
<beuno> abentley, do you know anything about bzrlib.bzrdirs?
<abentley> beuno: Sure.
<beuno> I'm getting: InvalidURL: Invalid url supplied to transport: "Sin%20t%A1tulo-1.psd": Unable to encode the URL as utf-8: 'utf8' codec can't decode byte 0xa1 in position 5: unexpected code byte
<beuno> when doing:
<beuno> bzrdirs = list(bzrdir.BzrDir.find_bzrdirs(t))
<beuno> so I'm either using it wrong, or encoding isn't managed too well in bzrdirs
<abentley> beuno: What's t.base?
<beuno> bzrdir.find_branches seems to blow up
<beuno> abentley, this is the code: http://paste.ubuntu.com/95383/
<beuno> t.base is: file:///home/beuno/biometrix/
<abentley> beuno: Sounds like a problem with encoding handling, then.
<beuno> so it explodes when doing:  pending.append(current_transport.clone(subdir))
<beuno> and subdirs comes from...
<beuno> subdirs = list_current(current_transport)
<beuno> hm, this keeps going up
<beuno> aaanyway, I may end up sending a patch or two during this week to the list  :)
<beuno> thanks abentley
<abentley> beuno: np
<sohail> hey, is there some way to have bzr mv multiple ifles on Windows
<sohail> bzr mv directory/assload_of_files* other_directory/
<sohail> doesn't work b/c of stupid cmd.exe
<Jc2k> jelmer: ping
<jelmer> Jc2k: pong
<Jc2k> jelmer: so i nearly got the server working again.
<jelmer> Jc2k, but please be quick, at a conference and about to run out of battery :-)
<Jc2k> gaaah!
<Jc2k> find_missing_objects
<Jc2k> repo.find_missing_objects
<jelmer> what about it?
<Jc2k> i passed in the graph walker from server.py
<Jc2k> thats seems to be a silly move
<Jc2k> it ends up building a pack of commits i want and have, but not the ones in between
<jelmer> not sure I follow
<jelmer> is this with r107 ?
<jelmer> I think I've also fixed that
<Jc2k> ah
<Jc2k> that wasnt there earlier :]
<jelmer> (local / remote fetch from git to bzr works as of a couple of hours ago)
<jelmer> yeah, I didn't have any bandwidth :-(
<Jc2k> server should work again the next time you have power
<jelmer> cool
<Jc2k> i was going to ask about how i should fix what you have already fixed, so i'll merge, test and push
<Jc2k> and look at your bzr-git stuff for bzr git-serve
<jelmer> time to find some juice, brb
<Jc2k> ttys
<jelmer> Jc2k, re
 * Jc2k pushed something
<beuno> jelmer, hi!  I've been playing with your upgrade-recurse plugin
<beuno> added a dirty way of deleting the backup.bzr dir after upgrade
<beuno> and I have more plans for it, after I find the encoding bug in bzrlib.bzrdir
<beuno> pushing to: lp:~beuno/bzr/upgrade-recurse  if you're interested
<beuno> now, off for a quick shower and dinner
<eferraiuolo> I was looking for some help when using BZR with SVN
<eferraiuolo> For every operation I'm asked for my password on the SVN server
<eferraiuolo> I am connecting to it via HTTPS so I figure it's using Web-Dav
<eferraiuolo> How can I make things where I don't have to authenticate every single operation?
<eferraiuolo> ...It's Google Code's SVN that I'm connecting to...
<jelmer> beuno, hi
<jelmer> Jc2k, hi
<jelmer> beuno, cool, I'll pull it
<jelmer> Jc2k, will check that out too :-)
<jelmer> eferraiuolo, hi
<jelmer> eferraiuolo, this is a bug in bzr in handling the passwords
<jelmer> if I understand correctly it should be fixed in the next version
<jelmer> you should be able to work around it for now, by using the credentials stored in the subversion configuration directory
<xivulon_> hi all, is there a 2 way sync bzr<->cvs? I can see the bzr-cvsps-import, what would be a good way to "export"?
<jelmer> you can force svn to cache the password by running "svn ls <url>"
<Jc2k> jelmer: its not quite working as plannned
<Jc2k> jelmer: but seeing as bzr-git has interesting stuff, ive no plans to go to bed just yet :]
<jelmer> :-)
<jelmer> Jc2k, I'm now pushing to http://people.samba.org/bzr/jelmer/bzr-git/trunk btw
<Jc2k> kk
<jpds> How do I close LP bugs with bzr commit? --fixes #### ?
<jelmer> jpds, "bzr commit --fixes lp:#####"
<jelmer> Jc2k, ENONEWCOMMITS
 * Jc2k blink
<jelmer> in your git-serve branch
<Jc2k> jelmer: if you have all of lp:~johncarr/dulwich/git-serve, then you have working push and nearly working clone
<jelmer> ah, now it's there
<Jc2k> weird, there was nothing to push
<jpds> jelmer: Many thanks!
<jelmer> maybe just a PEBKAC on my side
<LarstiQ> xivulon_: there is a very experimental launchpad.net/~bzrcvsserve iirc
<Jc2k> jelmer: i dont think repo.head() works any more..
<LarstiQ> xivulon_: but I don't think 2way sync is really doable with that
<Jc2k> jelmer: patching it now to see if im right..
<Jc2k> oooh.
<xivulon_> LarstiQ, thx will give it a look
<jelmer> Jc2k, what is generate_pack_contents() used for ?
<jelmer> Jc2k, it seems to duplicate the code of find_missing_objects()
#bzr 2008-12-30
<jelmer> I don't think a good two-way CVS plugin is easily doable
 * LarstiQ is inclined to agree with jelmer
<jelmer> the easiest solution is probably to just build on something like cvs2svn, but you would have to make sure that you don't change the output or make the file ids / revision ids/ depend on the changes in the content
<Jc2k> jelmer: dead code, i've removed it locally
<jelmer> Jc2k, ah, ok
<markh> garyvdm: woohoo to the qbzr threadless-throbber branch landing :)
<Jc2k> jelmer: can you have a look at r126 - change to find_missing_objects so it uses get_refs instead of heads. thats enough to fix git-serve for git clone
<Jc2k> (just pushed again)
<garyvdm> markh: I'm happy to. Just worried about regressions.
<Jc2k> jelmer: (something doesnt feel right about it)
<markh> I'll create new binaries locally so I test it with my "real" bzr
<markh> I must find that resources problem first...
<jelmer> Jc2k, looks alright
<jelmer> merged
<Jc2k> wicked
<Jc2k> jelmer: any thoughts on dealing with the incoming push? i was thinking about having a FakeGitRepo class that operated on in memory heads and a single pack, and then dealing with it similar to the stuff in svn-import
<Jc2k> jelmer: i guess the only difference between FakeGitRepo and LocalGitRepository is at the dulwich level anyway...
<Jc2k> (its a .git less repo with one pack and the heads are just a dict..)
<Jc2k> jelmer: so i could add a Repo class in dulwich that just took a pack and some heads and otherwise didnt touch the disk, then tweak LocalGitRepository in bzr-git so it can just be pasted a dulwich repo object directly, then in the server code create a LocalGitRepository with an in memory fake virtual rpeo think and copy revisions with InterGitRepository
<Jc2k> and i think use pull to update teh tips?
<Jc2k> pasted/passed
 * Jc2k heads to bed before my spelling accuracy falls any lower
<jelmer> Jc2k, still there?
<Jc2k> jelmer: just about
<jelmer> Jc2k, hmm
<jelmer> Jc2k, did you see Repository.add_pack()
<Jc2k> jelmer: are you suggesting i actually create a valid git repo for each incoming push?
<jelmer> Jc2k, not sure I follow
<jelmer> whjat would you need the fake repository for?
<Jc2k> how does add_pack help with handling an incoming push to bazaar?
<jelmer> ah, you were talking about an incoming push to bazaar
<jelmer> that makes more sense
 * Jc2k might just create a git repo for each push to get something working, and then refactor
<dort> anyone know the syntax to pass a username through bzr-svn
<jelmer> dort, in the url
<dort> when checking out from an http:// repo (svn)
<dort> http://user@
<dort> gives me a segfault after prompting for the password twice
<jelmer> dort, what version?
<dort> i just installed in my debian sid (didn't check yet)
<dort> Bazaar (bzr) 1.5
<jelmer> in that case you would want the version from experimental
<jelmer> what bzr-svn ?
<dort> ii  bzr-svn        0.4.10-2
<dort> is there a better choice in experimental?
<jelmer> dort, yeah, you want the version from experimental
<dort> ok, thx much
<jelmer> if that still segfaults, please file a bug
<dort> hmm
<dort> O watta goo Siam
<dort> as i install the new packages (or try to) I realize i've filled up my hard disk
 * dort sulks away to fix this
<dort> sorry, maybe that's what caused the segfault in the first place :-[
<jelmer> sleepytime
<dort> working now, thx much jelmer
<dort> sweet dreams
<vila> hi all
<jelmer> hey Vila
<vila> jelmer: hi !
<Jc2k> jelmer: ping
<jelmer> Jc2k, pong
<Jc2k> morning :)
<Jc2k> i simplified apply_pack a bit (to use object_store.add_pack)
<Jc2k> alas its now all kinds of slow
<Jc2k> (well, it might even be stuck in a looop...)
<jelmer> Jc2k, hi :-)
<jelmer> Jc2k, ah, cool
<jelmer> Jc2k, back
 * Jc2k waves
<Jc2k> jelmer: iterentries seems to be going on forever :\
<jelmer> Jc2k, yeah, the generating of the index is slow as hell at the moment
<jelmer> Jc2k, I think it's because of the repeated mmaps
<Jc2k> jelmer: this is a definite loop
<Jc2k> jelmer: traced it back to read_zlib
<Jc2k> jelmer: for some reason add = data[base:base+1024] isn't fetching any data, so fed doesnt increase, so it tries the same chunk again, which is still "", and unused_data is still "".. so it goes on forever
<jelmer> ahh
<Jc2k> jelmer: its read 2639 of an object of size 4117, any its about 20 or so objects away from the end of the pack
<Jc2k> so im not sure whats going on
<jelmer> interesting
<jelmer> what happens if you manually try to feed that data string?
<Jc2k> *tests*
<Jc2k> jelmer: if i feed the pack manuall to PackData.iterobjects, it seems to be fine
<Jc2k> (and the same pack was working before i moved to add_pack && comit..
<Jc2k> )
<Jc2k> flushing thing.
<Jc2k> jelmer: gah! for some reason i thought commit closed the fd.
<Jc2k> pushed.
<jelmer> checking
<jelmer> Jc2k, still there?
<Jc2k> jelmer: i wasnt, but i just got back :]
<Jc2k> jelmer: whats up?
<jelmer> Jc2k, just merged + pushed your branch
<jelmer> fetches from local git repositories and from remote git repositories work now
<Jc2k> sweet
<Jc2k> jelmer: ping
<jelmer> Jc2k, pong
<Jc2k> jelmer: hey. it seems like im able to push revisions :]
<jelmer> Jc2k, w00t!
<Jc2k> though its an evil hack
<jelmer> I'm trying to clone samba using bzr at the moment :-)
<Jc2k> and its made me think using InterGitRepository is needless
<Jc2k> i really should just use import_git_objects directly
<Jc2k> which im going to try, but first i need to spawn branches
<Jc2k> trying to rob some bzr-svn for this..
<jelmer> Jc2k, yeah, I don't think InterGitRepository is necessary either for the server side of things
<Jc2k> it just duplicates the work-out-what-to-copy step and then calls import_git_objects
<Jc2k> geh
<Jc2k> jelmer: is there a super easy way to just spawn a branch and set it to a given revision id?
<jelmer> Jc2k, a bzr branch you mean?
<Jc2k> yeah
<jelmer> Jc2k, Yeah, once you have a BzrDir, just call "bzrdir.create_branch()"
<jelmer> and then branch.generate_revision_history(revid)
<Jc2k> does bzrdir.create_branch need the directory to be present?
<jelmer> yeah
<jelmer> it also needs the .bzr directory to be present
<Jc2k> theres a large chunk of bzr-svn code for this (get_dir, transport_makedirs, and some other utils)
<jelmer> Though you ca nprobably use BzrDir.create() or something to create the .bzr directory
<jelmer> ah, ok
<jelmer> Jc2k: It may be nice to move those utility functions into bzrlib
<jelmer> just so we don't need any copies
<Jc2k> thats what i was thinking, but maybe BzrDir.create is better?
<jelmer> Jc2k, What I usually do is first move it to bzr-foreign, and then later submit it for inclusion in bzr.dev
<Jc2k> jelmer: so import_git_objects. atm i guess the order of the object yielding function doesnt matter. will it>
<jelmer> Jc2k, no, it doesn't matter
<jelmer> It won't matter in the future either I thijnk
<jelmer> (with apologies for my bad spelling tonight, blame the beer)
<jelmer> Jc2k: The order in which remote hosts order it would be related to the delta order
<Jc2k> jelmer: brilliant. in that case im going to see if i can tweak dulwich to support iterobjects directly off the wire
<Jc2k> jelmer: at the very least, i dont need the index
<smoothice> If I have a branch that I want to basically remove all the contents out of it and replace it with new contents.. how would I do that?
<jelmer> smoothice, bzr pull --overwrite ?
<jelmer> Jc2k, yeah, you don't need the index indeed
<smoothice> jelmer: ok thanks
 * jelmer is having a hard time trying to map a git index file to a bzr working tree
<jelmer> it seems the two concepts don't map very well
<jelmer> perhaps support for (git-like) indexes has to be added to bazaar first
<Jc2k> jelmer: is a primary aim for bzr-git to let people use bzr on a local git clone?
<jelmer> Jc2k, depends on what you mean by primary aim :-) but if at all possible, it would be nice to support it
<Jc2k> :-)
<jelmer> at least personally, I would very much like to be able to use bzr on native local git repositories
<Jc2k> jelmer: so i find myself needing a PackData.iterobjects that returns me ShaFiles
<jelmer> Jc2k, Use Pack.iterobjects()
<jelmer> Jc2k, you may want to generate an index first
<Jc2k> jelmer: but if i tweak iterentries i dont need the index files...
<jelmer> Jc2k, you do, because you need to resolve deltas
<Jc2k> oh, crap.
<jelmer> maybe you're just lucky at the moment that you don't hit any ref delta's, but once you do, you really want that index
<jelmer> perhaps we can allow the index to be in-memory at some point
<jelmer> but I don't think that will help significantly in terms of performance
<Jc2k> ok, pushed what i have so far. now using import_git_objects directly, and accessing pack directly (with index) instead of going via Repo.
<jelmer> ah, cool
 * jelmer is looking at implementing the index
<Jc2k> its a bit messy, le sigh.
<jelmer> ah well
<james_w> can someone with pycurl installed try "bzr info https://code.launchpad.net/bzr" please?
<markh> james_w: works for me
<james_w> markh: thanks
<james_w> markh: I assume you are not on Ubuntu :-)
<markh> :)
#bzr 2008-12-31
<Alex____> new to bazaar, feeling out its capabilities
<Alex____> got a question, though
<Alex____> I'm building a versioning system for scientific figures
<Alex____> and I'd like to extend bzr to handle arbitrary metadata
<Alex____> would this be possible via a plugin?
<vila> hi all
<garyvdm> Hi - How do you specify the no-trees option for a repository after it has been created?
<Jc2k> jelmer: just pushed a git-receive-pack replacement that operates on bazaar instead (so push over git+ssh:// should work too)
<Jc2k> jelmer: unfortunately it looks like it has to conflict with the one provided by git-core, so might be a packagers nightmare
 * Jc2k should check how it behaves under 1.6 (probably calls git receive-pack <git dir> instead of git-receive-pack <git dir>)
<jelmer> Jc2k, well, it can use alternatives
<Jc2k> jelmer: true. so elegant :]
<Jc2k> jelmer: are you still working on the index?
<jelmer> no, that's already working
<Jc2k> ah, awesome.
<jelmer> I finished it last night, but haven't tested it extensively yet
<Jc2k> im about to start working on pull/clone in bzr-git
<jelmer> Jc2k: pull from bzr into git you mean?
<Jc2k> yeah, for git-serve
<jelmer> Jc2k, where are you going to store the metadata
<CaMason> Anyone know why I'd get a blue screen of ultimate death on Windows Vista when checking out a branch over SFTP?
<jelmer> Jc2k, ?
<Jc2k> jelmer: hmm, i guess thats not my first priority :]
<jelmer> Jc2k: I think it should be :-)
<jelmer> Jc2k, you can't do proper pull/clone if you don't have full roundtripping
<Jc2k> jelmer: i was going to have a sha1/bzr id db on the server side
<Jc2k> but i havent thought too much about it
<Jc2k> if i think too much nothing gets done.. :p
<jelmer> Jc2k, if you do a sha1/bzr id db map
<jelmer> you also have to keep a map for the file ids, text revisions and revision properties
<jelmer> otherwise we end up breaking the referential integrity
<Jc2k> jelmer: i dont know bzr internals, but the last time i thought about this i was concerned a tree sha might relate to multiple inventories
<Jc2k> and it was among the reasons i concentrated on the git side :p
<meoblast001> hi
<meoblast001> how would a user without ssh pull source using bazaar.. i always forget
<meoblast001> is it http?
<beuno> meoblast001, yup
<meoblast001> ok.. so pulling http://bazaar.launchpad.net/~mysticgalaxies/mox/devel/changes would work?
<meoblast001> oops
<meoblast001> without that changes par
<Peng_> Yes.
<Peng_> lp:~mysticgalaxies/mox/devel will use plain HTTP if you haven't run launchpad-login.
<meoblast001> k
<meoblast001> thanx
<Peng_> For that specific branch, you can also use lp:mox as a shortcut.
<afdasfadgt> is it possible to merge 2 diffrent projects into one?
<AmanicA> hi, I'm trying to implement `bzr missing -r 1..-1`, but it turns out we might need 2 sets of revision specs, one for the local branch and one for the remote branch
<AmanicA> so either I must make 2 parameters (is there another command like that?)
<AmanicA> or I can maybe use `bzr missing -r 1..-1..2..-2` where the last 2 are upper bounds
<asabil> AmanicA: I think having bzr pull --dry-run and bzr push --dry-run would be more intuitive imho
<AmanicA> good idea, I havn't thougt of that
<burak575> is it possible to merge 2 diffrent projects into one?
<AmanicA> I hope I didn't waste my whole 31Dec for nothing
<AmanicA> asabil: I love you for solving my problem & hate you for telling me I wasted my whole 31Dec for nothing (and gettind a headache while trying)
<AmanicA> :)
<AmanicA> thanx though!
<asabil> sorry :)
<asabil> burak575: what do you mean exactly ?
<burak575> i was have a project
<burak575> and a project related to it
<burak575> but i initialized two of them with bzr init so they are not common ancestors
<burak575> how can i merge them into one project?
<burak575> like bzr merge project projectDLL
<burak575> none of them is sharing any common files but i wanna merge them if possible
<asabil> you can check bzr help join
<asabil> I haven't used it myself, but I think it is the right tool for your problem
<burak575> thanks i am gona try it :)
<asabil> burak575: it seems like it requires a specific branch format
<asabil> you might want to check the "merge-into" plugin
<burak575> yeah it said so
<burak575> projectDLL doesn't support rich root data. You can use bzr upgrade on the repository.
<burak575> it was replied like this i am gona check merge-into plugin :)
<asabil> :)
<LarstiQ> burak575: you can also `bzr merge -r 0..-1`
<burak575> hmm
<AmanicA> asabil: I didn't realise `bzr pull --dry-run` is not implemented yet :(  I see merge has a preview though, but that shows a diff
<AmanicA> I'm looking for something like log, so I think your suggestion will work nice
<asabil> AmanicA: I was suggesting you implement it :)
<AmanicA> I realised that now :)
<LarstiQ> hehe :)
<LarstiQ> AmanicA: you can still make good of your 31st! :)
<AmanicA> no its done forever as of 29 minutes ago :(
<AmanicA> r/done/gone/
<burak575> yeah same
<burak575> what is your gmt zone?
<AmanicA> gmt+2
<burak575> same .D
<LarstiQ> AmanicA: aww, sorry to hear that.
<LarstiQ> AmanicA: lets capitalise on the 1st then! ;)
<AmanicA> :)
<burak575> i was made first 2009 commit on bzr 15 mins ago lol
 * LarstiQ will have to wait 30 more minutes
<LarstiQ> or move my clock forward, hmm :)
<AmanicA> I'm still to depressed to code. and I have a headache now :(
<AmanicA> I think I should go sleep it off
<AmanicA> I was stupid, I wrote the `missing -r..` backend first complete with unit tests... and then realised the ui wont work nice...
<davidstrauss> LarstiQ: Or just find tomorrow's commit using revspec date:tomorrow
 * davidstrauss cannot figure out why "tomorrow" is a documented date value for revspec
<LarstiQ> davidstrauss: ending slices I'd say
<LarstiQ> davidstrauss: always inclusive, no off by ones
<LarstiQ> at least, that is my assumption
<davidstrauss> LarstiQ: but can't you do that explicitly with a non-date revspec?
<LarstiQ> davidstrauss: probably true :)
<LarstiQ> if your clock is behind revisions it is a bit harder though.
<LarstiQ> davidstrauss: how does date:tomorrow interact with timezones?
<LarstiQ> 23:45:04 < theeth> I bet I can sneak in a last 2008 commit after your first 2009 commit :)
<LarstiQ> from #blendercoders just now
<davidstrauss> LarstiQ: It probably doesn't. I'm guessing everything is UTC.
<davidstrauss> LarstiQ: Or do you mean when you specify a time?
<LarstiQ> davidstrauss: tomorrow semantics could conceivably include revisions where the local date was 1 day ahead of what you are currently at.
<davidstrauss> LarstiQ: That seems horribly flawed
<davidstrauss> Relativity aside, it's not a different time there
<davidstrauss> The daylight just spans different hours
<LarstiQ> davidstrauss: I don't know what the semantics are, but I don't see a natural way out of the local vs global distinction
<davidstrauss> LarstiQ: time zones aren't part of data and time data
<davidstrauss> LarstiQ: They're presentation adjustments
<LarstiQ> davidstrauss: exactly, and that matters for ui
<davidstrauss> LarstiQ: Right now, in Jerusalem, it's 2009. That doesn't mean an edit happening there right now happens in my tomorrow.
<davidstrauss> LarstiQ: An edit never happens in my tomorrow.
<ronny> LarstiQ, jelmer: happy new year
<LarstiQ> ronny: thanks, you too :)
<LarstiQ> davidstrauss: I understand what you mean.
<ronny> oh, well, the others, too ;P
<LarstiQ> hehe :)
<LarstiQ> jelmer is currently at the Brandenburger Tor if things went well
 * LarstiQ is in the c-base
<ronny> im at home
<davidstrauss> LarstiQ: The only difference is disagreement on how we represent "now"
<davidstrauss> LarstiQ: But it's a rather superficial difference
<ronny> LarstiQ: hopefully next year i can stay a few days longer
 * LarstiQ nods at ronny
<LarstiQ> and at davidstrauss :)
<davidstrauss> I think it's flawed to store timezones with dates
<ronny> since i got no mate any more im too sleepy/lazy to get out
<ronny> davidstrauss: its usefull to have them on timestamps, gives a better statistics on the daytimes of commits
<LarstiQ> davidstrauss: it makes it easier to answer queries where you are looking for commits you made around a certain time, but have since moved timezones
<ronny> i got raubritter-beer
<ronny> its dark ^^
 * LarstiQ toasts ronny's raubritter with his mate
<ronny> prost
<LarstiQ> proost
 * LarstiQ continues reading MD2 preimage attack paper
#bzr 2009-01-01
<AmanicA> asabil: cool, I have a proof of consept of `bzr pull --dry-run` working! just need to write some tests now. (won't do over-eager TDD again...)
<jelmer> happy new year everybody
<AmanicA> thanx, you too
<jelmer> ronny, thanks, you too!
<jelmer> happy new year AmanicA (is it 2k9 over there yet?)
<AmanicA> yes, for about 2:30 already
<ronny> wb jelmer
<maco> the little \ | / - spinner thing...is it normal for it to stop spinning during a push?
<maco> oh it started moving again. i thought maybe it was hung.
<djsiegel> Hi, I have a question.
<djsiegel> So, one of our developers pushed r313 (https://code.edge.launchpad.net/~do-plugins/do-plugins/trunk) and gobbled up 9 days of revision history -- what is he doing wrong, and how to I revert those merges?
<djsiegel> Can bzr revert pop those revisions?
<djsiegel> Ok, branched at a pre-merge revision, did a backwards merge from trunk into the earlier revision, and published that.
<djsiegel> haha
<fullermd> Man, it sure is quiet here when everybody's hungover   :p
 * nDuff went to sleep early last night thinking today was a workday; now he's at the office and nobody's here.
<Jc2k> :p
<fullermd> Whoah, that means you can actually get _work_ done.
<dwt> Hey there, I'm trying to push a bzr project I was hacking on in the last two days to a svn repository I have
<dwt> but I don't seem to be able to
<dwt> and also googling only brought up http://samba.org/~jelmer/bzr-svn/FAQ.html
<dwt> which seems to suggest to use svn-push instead of push
<dwt> but that also doesn't work
<dwt> could you guys give me a hint?
<dwt> for reference, I have the svn side set up so that the folder exists where I want to push my bzr project into
<dwt> https://ipx11390.ipxserver.de/svn/mhaecker/open-source/LiquidDemocracy/trunk
<dwt> only, now how do I tell bzr to push to that location?
<dwt> ah, the repository is viewable by http://xn--hcker-gra.net/trac/browser/open-source/LiquidDemocracy/trunk
<dwt> for more information
<dwt> I tried
<dwt> bzr merge
<dwt> Merging from remembered submit location svn+https://ipx11390.ipxserver.de/svn/mhaecker/open-source/LiquidDemocracy/trunk
<dwt> The svn+ syntax is deprecated, use https://ipx11390.ipxserver.de/svn/mhaecker/open-source/LiquidDemocracy/trunk instead.
<dwt> bzr: ERROR: Branches have no common ancestor, and no merge base revision was specified.
<dwt> Well, I worked around this, by throwing the history away
<dwt> and just checking it in to svn directly
<dwt> still - is there a way to rescue the history here?
<dwt> (apart from doing it by hand with patch and diff...)
<dwt> ah well
<dwt> other things to doo
<dwt> see you
<fdv> I'm getting an expat error when trying bzr up (bzr-svn) from a bound branch, 'RuntimeError: cannot load dispatch table from pyexpat' (http://rafb.net/p/ITgRjK79.html). Anybody have any idea what goes wrong?
<fdv> googling drew a blank
<Jc2k> fdv: it looks like your celementree is compiled against pyexpat, but its not installed any more?
<fdv> uhm..
<fdv> well, it's my own python, just compiled it
<fdv> so I guess I might have mucked up things
<fdv> but pyexpat is there, and bzr was compiled against that
<fdv> celementree, is that a bzr thing?
<Jc2k> nope
<fdv> ah, guess I lack that, then
<fdv> I seem to lack paramiko as well, used to have that
<Jc2k> what does this give you?
<Jc2k> python -c "from pyexpat import expat_CAPI"
<fdv> that's fine
<fdv> I'll see if I can find celementree and install that
<fdv> or is it part of python?
<fdv> builtin
<Jc2k> fdv: im reading this: http://svn.effbot.org/public/tags/celementtree-1.0.5-20051216/cElementTree.c
<Jc2k> that error can only happen when its compiled with the USE_PYEXPAT_CAPI flag
<Jc2k> the error occurs when expat_capi is NULL, which happens if pyexpat isnt there or possibly if its too old
<fdv> hm, I'm getting an erie feeling
<fdv> could be that I need to tell python where to find the libs runtime
<Jc2k> pretty sure its not a bzr specific problem, though
<fdv> quite probably
<fdv> installing python in non-standard places isn't that simple
<fdv> (or it might be me :))
<Jc2k> GNOME does it in jhbuild
<Flimm> Is it possible to change a commit message of a revision that's not the latest one?
<AmanicA> Flimm: the short answer is no
<nDuff> Flimm, it's *possible*, but only with side effects
<Flimm> OK, it's not a big deal, I just wanted to change lp:xxx to bug xxxx so that launchpad would turn them into links
<fdv> Jc2k: I think I might have found the cause, pyexpat.so uses /lib/libexpat.so, but I'm pretty sure it's not built against that
#bzr 2009-01-02
<fdv> Jc2k: thanks a lot for your help, you put me on the right track. turns out "use of a system shared libexpat.so/expat.dll is not advised" in python. No wonder I couldn't get the tests to pass. :p
<Jc2k> :p
<Jc2k> np fdv
<Glenjamin> hey, does anyone else have a problem with directory tab completion on windows with 1.10?
<Glenjamin> (as in, it doesnt happen)
<markh> Glenjamin: what do you mean exactly?  tab completion is generally handled by the "shell" (ie, the command-prompt)
<Glenjamin> oh, in bzr shell
<Glenjamin> should have mentioned that
<markh> I've never used it (and don't even know *what* it is :) - did it ever work, or this is just something you first tried now?
<Glenjamin> its always worked fine, but now the tab completion only seems to do commands
<markh> either way though, I'm afraid I'm not going to have a clue
<Glenjamin> fair enough
<markh> if it is a regression, it is certainly worth reporting in as much detail as you can
<markh> (ie, to launchpad)
<Glenjamin> mm, i thought i'd better try and see if its affecting anyone else, since i'm not using the proper win32 release
<Glenjamin> as i built my own while the build machine was broken
<doublep> hello.  is it possible to change commiter of a revision?  i forgot to set my email and a few commits are attributed to a wrong user
<moquist> I added a local copy of a huge library to my branch and committed it, and now I've changed my mind. 'bzr revert' seems only to change my working tree; how can I revert the entire branch so it's as if those files were never added and the branch committed?
<fullermd> You have to back the branch up to before all that happened.
<fullermd> Generally, you do that with either pull or uncommit.
<fullermd> Is this really recent (in branch history terms)?
<moquist> ah! uncommit - excellent. I hadn't yet found that in my meanderings through the help. Thx.
<moquist> fullermd: yes. This will be no problem.
<moquist> thx again.
<fullermd> Note that 'uncommit' takes you back to the state right before you committed.
<fullermd> Which means that the library is still "add"'d.  So if you commit again right away, you'll be right back where you started  ;)
<moquist> right, so the files will still be there.
 * moquist nods
<fullermd> You could revert the tree, though that would lose any other changes you had since the last commit.  Or use 'rm --keep' to un-add the library.
<moquist> I'll uncommit to one rev before what I want, then I can recommit that and manually merge in the tiny number of changes I've made to files I actually want to keep.
<fullermd> Another option is to make a new branch, from the rev before the one you want.
<fullermd> Then manually cherrypick the changes from the 'original' branch over into the new one, and finally just mv them around so you move onward in the 'new' branch.
<fullermd> That way you can keep the old one around untouched, just in case.
<moquist> That seems like the best idea.
<moquist> beautiful. I'm almost done.
<rocky> what's the simplest workflow case of having non-committed changes in one branch and then wanting to move those changes over into another new branch without committing them to the current one and then removing those changes from the currnet branch?
<rocky> i would have thought bzr shelve in the first branch and the bzr unshelve in the second branch but that doesn't seem to work
<rocky> bzr 1.10
<Peng_> rocky: "bzr merge --uncommitted"?
<rocky> Peng_: perfect, thanks :)
<Peng_> :)
<epsy> hi, is bzr-svn compatible with bzr 1.10 ?
<epsy> ok, I'm officially stupid, nevermind
<epsy> my second question - do you know of any tool which can help me find the latest common ancestor of two branches when they are not linked from bzr's point of view?
<LarstiQ> epsy: you're using a different definition of common ancestor than bzr in that case?
<epsy> well, the last revision that's common in two branches
<LarstiQ> epsy: if needed once, I'd figure that out from `bzr missing` output
<epsy> neat..can I check if a branch has diverged from an official branch using bzr missing? or is another command better-suited for this task, considering I would use it in a shell script?
<LarstiQ> epsy: bzr missing is a good choice for detecting divergence
<epsy> only if tree is not a checkout, right?
<LarstiQ> epsy: what do you mean? missing operates on branches, not trees
<epsy> well, actually, I will just need a way to dertermine the other branch properly
<derekmounce_> Silly question no doubt, but I'm coming from SVN...  Does Bazaar support access control?  I want to push a branch up to a server, but I want only people with access to get to it.
<beuno> derekmounce_, access control is based on who can read/write
<beuno> so you'd setup ssh accounts or ftp
<derekmounce_> beuno: Ok, cool, so it's not "built in" to bzr.  That makes sense...
<derekmounce_> Thanks for the answer. :)
<beuno> right, although there is a script in controb/ that helps you do some of that with ssh keys
<derekmounce_> Another question... I've pushed via ftp, but I'd also like to have a working tree up in FTP.  Is it possible to force the push to also create a working tree?
<lamalex> is there any way to have --using meld open the entire diff instead of files by file?
<brokencycle> Hi! I've got a number of random error messages from running the selftest suite. Where should I send them, for best results?
<rockstar> beuno, around?
<lamalex> Does the bzr support in meld work for anyone?
<beuno> rockstar, hi
<rockstar> beuno, have you seen the loggerhead branch for better linking of files?
<beuno> rockstar, I don't think so. Which one?
<rockstar> lp:~ree/loggerhead/abstract-paths-fix
<beuno> looks interesting
<rockstar> Basically, I wondered if there was a policy on XXX statements in Loggerhead, but basically, I don't think it needs to be there at all.
<beuno> yeah, it's kinda odd
<beuno> I do add FIXME's now and then, which I guess is the same thing
<beuno> the comment is useful though
<beuno> branch looks good otherwise
<beuno> are you reviewing it?  :)
<rockstar> beuno, yup.
<beuno> rockstar, awesome
<beuno> I have a branch 80% ready that uses YUI to get diffs through ajax
<beuno> instead of generating them every time
<Peng_> What does this change for users with JS disabled?
<beuno> Peng_, the URL will take you to a diff
<beuno> so you loose seeing all diffs in the same page I suppose
<beuno> is that terrible?
<rockstar> beuno, aren't we using javascript for that as it is?
<beuno> rockstar, yeah, for expanding and contracting
<Peng_> beuno: Ehh, it's not great. What about taking you to an ?diffs=all#somefile page or something?
<beuno> Peng_, I guess I could...
<rockstar> Peng_, it's not great, no, but for those who don't want javascript, they are already experiencing a less than great internets.
<Peng_> rockstar: Well yeah, but..
<beuno> Peng_, especially since you're our testsuite  ;)
<rockstar> beuno, We _can_ remedy that.
<Peng_> Whenever I use a diff page in Trac or something, I like to see all the files at once, but I don't do it frequently.
<Peng_> I more use them to see "what happened there?" than to actually debug stuff or anything like that..
<Peng_> Or maybe that is the normal usage. After all, if you wanted to do something more in-depth, that's what the VCS is for.
<beuno> rockstar, yeah, we do need to start writing tests...
<beuno> Peng_, I'll have the option to see all the diffs for a revision
<beuno> it's not too hard
<Peng_> Oh, that sounds good.
<Peng_> For both Ajax and non-Ajax? Or would that not be very useful?
<rockstar> beuno, I say non-Ajax tests.
<beuno> Peng_, I think that the link will be there when avascript is disabled
<beuno> rockstar, yeah, so did I
<Peng_> Wait, what page is this for? /revision?
<beuno> Peng_, yup
<Peng_> So it'll default to having every file collapsed?
<beuno> that's my idea, yes
<Peng_> Will you keep the "expand all/collapse all" button?
<beuno> yeap
<beuno> it will bring in all the diffs
<Peng_> Cool. :)
<Peng_> Possible suggestion: If only one file was changed, expand it by default?
<beuno> that would be interesting, yes
<beuno> although maybe confusing
<beuno> sometimes ahving diffs, sometimes not
<Peng_> True.
<beuno> Peng_, I'll poke you before merging into trunk
<Peng_> 'kay
<beuno> I also experimented with adding syntax highlighting, but it's a PITA to do with the way we currently do things
<Peng_> Oh, too bad.
#bzr 2009-01-03
<Peng_> It might be easier to throw in some sort of JavaScript syntax highlighting.
<beuno> yeah, I toyed with that too, but it was too hard on thw browser
<beuno> I keep on wanting more and more to develope a "loggerheadlib"
<beuno> from scratch
<beuno> and start building on top of that
<beuno> something that spits out html or json
<beuno> and then possibly have multiple frontends to that
<epsy> bzr branches have metadata, right?
<Peng_> epsy: What do you mean?
<epsy> sorry, that's the wrong way to ask my question
<epsy> Can I retrieve info about a branch, such as remembered pull location or parent branch location in a way that's easily readable by a machine?
<davidstrauss> epsy: It's stored in the .bzr/branch files
<Peng_> Or in ~/.bazaar/locations.conf.
<davidstrauss> epsy: The best bet is running a bzr command and parsing the output
<Peng_> Or using bzrlib.
<epsy> davidstrauss, meh :\
<beuno> epsy, if you're in python, you can get it through bzrlib
<beuno> if not, you also have the xmloutput plugin
<epsy> I'm in bash
<Peng_> bash can run Python. :D
<epsy> so I can use grep/awk/sed, but an easy way would have been nicer(to me and to the aspect of the code)
<davidstrauss> epsy: In that case, I would implement a large set of shell scripts that transparently replicate and reimplement Bazaar's capabilities
<davidstrauss> epsy: But only for repo versions .92 and newer
<davidstrauss> epsy: Supporting anything older with bash-bzr would be ridiculous
<epsy> would you?
<davidstrauss> I'm kidding :-)
<davidstrauss> But I've seen some pretty ridiculous shell scripts
<Peng_> Is awk turing-complete? Could we rewrite bzr in it?
<davidstrauss> All repo database manipulations would be written as sed regexes
<Peng_> (And by "we" I mean "someone completely insane".)
<Peng_> ("who is not me")
<davidstrauss> Peng: You haven't ruled out that you're completely insane; you'd only established that, despite your potential insanity, you wouldn't write bash-bzr
<davidstrauss> you've*
<davidstrauss> Peng: But what about in Windows PowerShell?
<Peng_> I like to think I still cling to a few...somethings of sanity.
<fullermd> Who is it that tries once in a while to use bzrlib in perl via Inline::Python or something?
 * fullermd always finds that really neat.
<rexbron> hey james_w, do you expect to have any time soon to review my branch?
<james_w> hi rexbron, I'll do it tomorrow.
<james_w> rexbron: thanks for the reminder
<epsy> what can I use with bzr log --log-format= ??
<james_w> epsy: by default "line" "log" and "short", but plugins can add others
<epsy> oh, that was the purpose, heh
<epsy> how would one count how many revisions, including merged revisions are in a branch?
<james_w> "bzr revision-history | wc -l" perhaps
<james_w> "bzr log | grep " *revno:" | wc -l"
<epsy> bzr log | grep -P '^ *revno: [0-9]+$' | wc -l
<epsy> that's what I came up with, but it can be spoofed
<james_w> yeah, not sure if "revision-history" lists merged revisions
<epsy> it does not, sadly
<epsy> even with -v
<james_w> try bzr info
<james_w> perhaps with -v
<epsy> the repo part shows something that seems to be a correct number, but it probably wont be on other configurations
<james_w> yeah, it's for the repo, so it's not what you want
<james_w> a couple of lines of python would do it
<epsy> heh
<epsy> would a couple of lines fit into one line ?
<james_w> it could
<epsy> right, I'll dig the bzrlib doc then..where is it?
<epsy> http://starship.python.net/crew/mwh/bzrlibapi/ this?
<james_w> yep
<james_w> you need to use Graph methods, using the graph from the repo, and the tip revision of the branch as a starting place
<james_w> and keep a set of visited revisions, and walk the graph
<epsy> graph ? tip revision?
<james_w> it might be a very long single line :-)
<epsy> ah
<epsy> heh
<epsy> hm, at that rate I'll still be in bzrlib's doc tomorrow
<epsy> I'll head for the spoof-able way
<epsy> (in the secret hope a perfectionnist comes around and fixes it)
<epsy> hrm, -d is lacking on bzr missing
<spiv> epsy: "bzr ancestry | wc -l" maybe
<epsy> spiv, ah, exactly!
<AfC> I still don't understand why `bzr info -v` doesn't report that number instead of the number of left hand revisions. Since the revno is the latter, it's really quite silly to report the number again, and meanwhile everyone wants to know the former.
 * fullermd blames the gnomes.
<epsy> what does bzr missing return when you use --this and there are missing revisions(on <other> but not on <this>) ?
<mcfletch> Stupid question, when bzr says "parsers.expat", what package is it referring to, as in:  mcfletch@sturm:~/OpenGL-dev/simpleparse$ bzr ls
<mcfletch> bzr: ERROR: No module named parsers.expat
<mcfletch> You may need to install this Python library separately.
<mcfletch> I'd thought it would be python-xml (on Ubuntu), but that doesn't eliminate the error.
<mdke> hi there
<mdke> if I do a bzr merge, but then want to revert it, how do I do that? I see that bzr revert still leaves me with a "pending merge"
<mdke> ah, running bzr revert a second time has done the trick
<mdke> ignore me :)
<spiv> mdke: bzr revert with no arguments will revert pending merges (and changes to files)
<spiv> mdke: you can also do "bzr revert --forget-merges"
<mdke> spiv: yeah, the first time I ran it I had done "bzr merge .", which i guess is why it didn't revert the merge, but only the files
<spiv> mdke: right
<epsy> hey..still working out stuff with bzr..
<epsy> I'm setting my branches to use a shared repo
<epsy> but somehow, when using bzr reconfigure --use-shared, it tells me both repositories(branch's personal and shared) aren't compatible:
<epsy> bzr: ERROR: KnitPackRepository('file:///home/epsy/CODE/armagetron/.bzr/repository/')
<epsy> is not compatible with
<epsy> KnitPackRepository('file:///home/epsy/CODE/armagetron/0.2.8/.bzr/repository/')
<epsy> different rich-root support
<ronny> LarstiQ: any idea where jelmer is?
<LarstiQ> ronny: no, his server froze on the 31st, I would have expected him back by now
<LarstiQ> ronny: but maybe he is also suffering from a case of the flu
<ronny> hmk
<joeljkp> i'm getting "no repository found" when i try to add the bzr-eclipse update site to eclipse 3.4; what's going on?
<garyvdm> Hi - I'm having trouble getting bzr to notice BZR_PLUGIN_PATH.
<garyvdm> see http://pastebin.com/d38d129ee
<garyvdm> I'm must be making a mistake some where.
<Peng_> garyvdm: This isn't really an answer, but I'd just put a symlink to the plugin in ~/.bazaar/plugins.
<garyvdm> The reason I want to change it is I want to test some changes I'm making to bar-upload, with out affecting my installation. ~/bzr-upload/wd/upload is my test area.
<garyvdm> *bzr-upload
<luks> export BZR_PLUGIN_PATH=...
<luks> without export it sets it only for the current command, which is nothing
<garyvdm> Oh - thanks
<virtuoso015> have a question... how to continue a new branch creation
<virtuoso015> i was downloading the mysql source from bazaar
<virtuoso015> and it got interrupted in between
<virtuoso015> i have already downloaded 300mb ... dont want to redo it again
<virtuoso015> this is the command and its output
<virtuoso015> $ bzr branch lp:mysql-server/6.0 mysql-6.0
<virtuoso015> bzr: ERROR: Target directory "mysql-6.0" already exists.
<garyvdm> virtuoso015: cd into your branch and then pull.
<garyvdm> cd mysql-6.0
<garyvdm> bzr pull
<virtuoso015> it is saying that its not a branch
<virtuoso015> bzr: ERROR: Not a branch: "/mysql-server/mysql-6.0/.bzr/branch/".
<garyvdm> Is mysql-server a shared repository?
<virtuoso015> sorry, i am a beginner at this...
<virtuoso015> although i can tell you the command i have used
<garyvdm> Ok no problem.
<garyvdm> Give me a sec.
<virtuoso015> shell> mkdir mysql-server shell> bzr init-repo --trees mysql-server              Once you have an initialized directory, you can             branch from the public MySQL server             repositories. To create a branch of a specific version:            shell> cd mysql-server shell> bzr branch lp:mysql-server/6.0 mysql-6.0
<virtuoso015> sorry... let me format that
<virtuoso015> shell> mkdir mysql-server
<virtuoso015> shell> bzr init-repo --trees mysql-server
<virtuoso015> shell> cd mysql-server
<virtuoso015> shell> bzr branch lp:mysql-server/6.0 mysql-6.0
<garyvdm> Ok - mysql-server IS a shared repository
<virtuoso015> meaning it can store more than one version of mysql at a time ??
<beuno> virtuoso015, meaning that if you branch again, it will probably only bring in the revisions you don't have
<garyvdm> You can delete /mysql-server/mysql-6.0 and then branch again
<beuno> a shared repo is a common database of revisions, indipendant of branches
<garyvdm> You won't delete the data allready downloaded, because it is stored in  mysql-server/
<virtuoso015> i seem to have a very big file , of size 300 MB, in /.bzr/repository/upload
<virtuoso015> its a .fetch file
<virtuoso015> oh... ok. So, all i need to do is to delete the mysql-6.0 folder
<garyvdm> Just a sec
<virtuoso015> and redo the branch command again ??
<virtuoso015> no prob
<garyvdm> What is the full path to that 300mb file?
<virtuoso015> ./mysql-server/.bzr/repository/upload
<virtuoso015> mysql-server is in my home directory
<garyvdm> Ok - I just wanted to check that it was not in the  /mysql-server/mysql-6.0 dir.
<virtuoso015> so, i now delete the mysql-6.0 dir and retry ??
<garyvdm> Yes
<garyvdm> I'm not 100% sure if it will continue with that .fetch file. I think it will.
<garyvdm> It won't redo the other data that was downloaded.
<virtuoso015> ok... the command is working
<virtuoso015> the progress bar has not yet come
<garyvdm> Maybe someone else can let us know if it will continue with the .fetch file.
<virtuoso015> ok, it seems to be working
<virtuoso015> the size of the .fetch file hasnt diminished
<virtuoso015> and the progress bar is starting from half way
<virtuoso015> hmmm... it seems to have created a new fetch file
<virtuoso015> lets see how this goes
<garyvdm> I've been checking out the annotate of the code to see who might be able to answer, and none of them are here :-(
<virtuoso015> no problem... live and learn... or is it, screw up and learn :D
<garyvdm> Yhea
<luke-jr> is it safe to use 'bzr branch' as an import method? eg, branch and then delete the origin?
<AmanicA> yes, but it will only contain comitted stuff
<LeoNerd> A branch is a complete copy of all history, yes. It doesn't refer to the origin
<luke-jr> AmanicA: eh?
<AmanicA> I normally have suff in there which I don't commit.
<luke-jr> well, in this case, the origin is svn
<AmanicA> like ide files
<AmanicA> also I normally don't delete anything without making a backup
<luke-jr> how can I specify the format of a branch?
<garyvdm> bzr upgrade
<luke-jr> garyvdm: can't do it at branch-time?
<luke-jr> why does bzr tell me --dirstate-with-subtree is deprecated?
<luke-jr> is there a replacement?
<garyvdm> luke-jr: You can't do it at branch time, which I find irritating.
<luke-jr> another question, slightly off-topic: can I have Launchpad automatically pull from a parent branch?
<garyvdm> dirstate-with-subtree:
<garyvdm> This format was introduced as a hidden format in Bazaar 0.15. It is an experimental format, not recommended for use.
<garyvdm> (http://bazaar-vcs.org/BazaarFormats)
<fullermd> d-w-s is a knit format, so yeah, it's old and deprecated.
<ronny> sup jelmer
<ronny> jelmer: whats the state on your leak-free svn bindings - i could really use them in anyvc
<garyvdm> luke-jr: to have launchpad pull your branch: https://code.launchpad.net/+code-imports/+new
<luke-jr> garyvdm: any idea if that has bzr-svn?
<luke-jr> garyvdm: dirstate-with-subtree is about the only format I could find that supports nested trees
<luke-jr> fullermd: can you recommend another one?
<fullermd> Well, there's a pack subtree variant.
<luke-jr> is there?
<fullermd> pack-0.92-subtree
<luke-jr> wait, pack is > dirstate?
<fullermd> mu
<fullermd> In this sense, yes.
<garyvdm> dirstate = dirstate + knit
<garyvdm> pack-0.92 = dirstate + pack
<garyvdm> pack > knit
<garyvdm> Hope that makes sense
<luke-jr> i c
<luke-jr> is pack-0.92-subtree as tested as dirstate-with-subtree ?
<fullermd> Well, I suspect the answer is "yes", but I'm not sure how much comfort can be drawn from that   ;)
<luke-jr> grr, it says pack-0.92-subtree is deprecated too
<luke-jr> and pack-0.92-subtree is broken -.-
<luke-jr> or maybe nested trees is just broken in general â¹
<beuno> luke-jr, right, bzr doesn't really support nested trees
<luke-jr> beuno: why not?
<luke-jr> it was working in 0.4â¦
<luke-jr> it's also a very necessary functionality
<fullermd> 0.4?
<beuno> 0.4?
 * fullermd winz!  :p
<beuno> damn!  lost the first round of the year
<fullermd> bzr has never _supported_ nested trees.  It's always been a half-formed future feature.
<fullermd> That's why the formats are squirreled away in a dark corner.
<beuno> ah, maybe he means bzr-svn?
<fullermd> Oh, that could be.
<luke-jr> beuno: no, I mean bazaar I think
<beuno> luke-jr, I hope you don't
<fullermd> There was never a bzr 0.4.
<luke-jr> oh :/
<fullermd> It went from 0.1.1 to 0.6
<luke-jr> so what do I do if I need nested trees? :/
<luke-jr> use Subversion?
<beuno> talk to LarstiQ   ;)
<fullermd> I think then you bug LarstiQ; he was the last one that touched it.
<luke-jr> LarstiQ: hi?
<beuno> 1-1
<fullermd> Blast!
<fullermd> He may have a branch around that's more solid; not sure.
<luke-jr> a branch :x
 * luke-jr DOES want other people to be able to checkout his code
<fullermd> Pfft.  Other people just cause problems.
<beuno> luke-jr, if you where using nested trees, then you where using bzr-svn
<luke-jr> beuno: oh?
<beuno> which also went recently from 0.4 -> 0.5
<fullermd> Why, I've got all sorts of programs that were totally bug-free until other people starting using them...
<luke-jr> nested trees don't exist w/o bzr-svn?
<beuno> luke-jr, I suspect that's the reality, but only jelmer can confirm that
<fullermd> Er, no, just that bzr-svn is the primary reason anybody ever used a subtree format (and shouldn't be nowadays anyway)
<luke-jr> fullermd: how about a real need for it?
<luke-jr> my project uses code from 2 other repositories
<fullermd> Nested tree support has never existed beyond a few low-level bits with a molecularly-thin UI on top of them.
<beuno> luke-jr, the answer always ends up with
<luke-jr> fullermd: it seems to be working, except for checkouts
<fullermd> Well, with a real need for it, you need the actual feature, not just the format.
<beuno> "bug LarstiQ"
<luke-jr> fullermd: yes, I do
<fullermd> A lot of the low-level stuff was written.  The higher-level glue, UI, polishing, etc, hasn't been done.
<luke-jr> that's fine
<luke-jr> my only requirement is that it works for third-party checkouts
<fullermd> Well, no, it's not fine.  It _doesn't work_.  It's never worked.  First steps were taken, and nobody has had the combination of interest and time to finish it.
<luke-jr> sigh
<fullermd> There's a fair continuing current of interest.  It's not like we _want_ it to be sitting around teasing people.
<fullermd> Just that it doesn't top anybody's priority list, so it sits around not really moving.  That's why it's hidden.
<fullermd> AFAIK, LarstiQ _is_ still working on it, but he's had something approaching 0 time for the last $WHILE.
<luke-jr> sigh
<luke-jr> so a Makefile that fetches the subtrees for now? â¹
<beuno> luke-jr, or maintain all of them in the same tree
<luke-jr> beuno: the subtrees are from different projects
<beuno> luke-jr, it's still legal...  ;)
<luke-jr> â¦
#bzr 2009-01-04
<garyvdm> luke-jr: Maybe scmproj might be a solution. http://launchpad.net/bzr-scmproj  Though It's not mature yet either.
<garyvdm> You can choose between the lesser of 2 evils....
<garyvdm> scmproj *is* being actively developed.
<spiv> garyvdm: interesting, I hadn't seen that one yet.  There's also https://launchpad.net/config-manager.
<luke-jr> is it possible to create a local change that cannot be pushed?
<headlessagnew> Does anybody with experience in bzr-svn happen to be around?  I'm getting "Unable to open an ra_local session" errors when I specify a single file for "bzr diff", but not when I do a directory.  (bzr 1.10, bzr-svn 0.5rc1)  Same thing for commit, as well.
<jelmer> headlessagnew, where does the error appear?
<jelmer> headlessagnew, what platform?
<headlessagnew> jelmer: I'm on OSX, running SVN 1.5.  The error shows up inside bzrlib/plugins/svn/subvertpy/ra.py at line 43, in RemoteAccess .
<jelmer> headlessagnew, how did you install bzr-svn?
<jelmer> running from ~/.bazaar/plugins ?
<headlessagnew> jelmer: Systemwide, I'm afraid, but by hand and not with easy_install
<jelmer> headlessagnew, I suspect you ended up with a broken install then
<jelmer> there were some fixes wrt the installer in rc1
<jelmer> s/fixes/issues/
<jelmer> they'll be fixed in the next rc
<headlessagnew> jelmer: Oh, I see.  Should I pull a new version from launchpad and try that?
<jelmer> headlessagnew, you can try using the 0.5 branch of bzr-svn
<jelmer> are you sure you want 0.5 though, not 0.4 ?
<headlessagnew> jelmer: I'll confess I don't have any stake in 0.5 over 0.4; I'll drop back to 0.4.16.
<headlessagnew> jelmer: much obliged, thanks!
<jelmer> headlessagnew, np
<j^> hi, trying to install bzr from https://launchpad.net/~bzr/+archive on hardy i get
<j^>   bzr: Depends: python-central (>= 0.6.7) but 0.6.5ubuntu1 is to be installed
<garyvdm> Hi - I'm trying to extend some tests in bzr-upload.
<garyvdm> It's a TestCaseWithTransport.
<garyvdm> I'm trying to push to the transport. When I do this, it just freezes.
<garyvdm> This is my code: http://bazaar.launchpad.net/~garyvdm/bzr-upload/nowt/revision/55
<garyvdm> I stepped through the code to see where it is freezing. It freezes on:
<garyvdm> dir_to = bzrdir.BzrDir.open_from_transport(to_transport)
<garyvdm> line 47 bzrlib/push.py
<garyvdm> I found my problem with the tests. It's prompting for a password. You cant see the prompt, but it waits for input.
<garyvdm> Does any one know how I should fix this?
<Snaggen> I'm investigating the "bzr commit --fixes= " feature to see it I can get that to change the status of a ticket in trac. Is there any server hook that can do this or any other solution? I think I saw something about this a long time ago, but I cant find anything now...
<ronny> moin
<ronny> jelmer: ping?
<yacc> Any way that I can pick which changes I want to go into a send patch?
<edgimar> If I have a bzr repo (repo 'a') which is branched from another repo (repo 'b'), and I commit a changeset to repo 'a', and thereafter changes are made to repo 'b', how do I pull those changesets from 'b' into 'a'?  I tried 'bzr merge <loc of b>', but I think I'm not understanding something...
<luks> first you should probably change the terminology :)
<luks> (to match bzr)
<edgimar> after doing that, if I do 'bzr st', I get "modified: .... [list of various files]", and "pending merges: ...".
<luks> you need to run bzr commit after bzr merge
<edgimar> luks: and then all the 'revisions' from repo 'b' will appear in 'a'?
<luks> yes
<luks> well, maybe not in the way you expect them
<luks> they will not be linear
<edgimar> ok - and how would I get them linear?
<luks> the simple answer is that you can't
<luks> why would you want that?
<edgimar> And..., if I make another commit to 'a', and want to 'push' both of the changes from a back into b, how does that work?
<luks> after push from 'a' to 'b' (after bzr merge & bzr commit), 'b' will be identical to 'a'
<luks> if you make another commit to a, and it won't be merged to b, bzr will refuse to push
<luks> it will fail with an error about diverged branches
<edgimar> hmm.  it would be cool if you could do something like git or hg rebase - is there something like that for bzr?
<luks> yes, there is bzr-rebase
<luks> but that doesn't "pull" the revisions
<luks> it creates new revisions that look like the original ones
<luks> (it is the same in git and hg)
<edgimar> then, I guess it would be possible to just keep 'a's changes on top of the revisions pulled from 'b'.
<edgimar> (and keep them linear)
<luks> yes, you can keep the changes, you can't keep the revisions
<edgimar> you mean revision numbers, or the commit message, etc?
<luks> mainly the revision IDs, which is something you don't normally see, but it tells bzr whether two revisions are identical
<luks> the patch, commit message, author, etc. are all kept when using bzr rebase
<edgimar> ok, that's good ;)
<edgimar> What happens when if you have a repo on launchpad, and you rebase your local repository, and try to push the changes back to launchpad -- I presume this won't work, right?
<luks> right, you can push --overwrite though
<edgimar> and what does that do?
<luks> running rebase on a public branch doesn't make much sense, though
<luks> well, it will overwrite the branch :)
<luks> meaning that it will remove the old revisions and add the new ones from the local branch
<edgimar> I see -- so everything gets overwritten, or only the 'non-common' parts?  (just wondering about how much time it would take, since bzr has been pretty slow for me in the past -- pushing taking like 20 minutes or so).
<edgimar> (an initial push, that is)
<luks> it will push only the new revisions
<luks> the revisions that are identical in both branches are keps as they are
<edgimar> luks: ok, good.  Thanks for your help.
<edgimar> one other thing -- how do I chop off (delete) revisions from a repo (starting at a given revno)?
<luks> bzr uncommit, if I understand the question correctly
<luks> that is, if you want to remove revisions from X to the head of the branch
<luks> if you want to remove revisions from 0 to X, there is no easy way
<edgimar> yes, uncommit should work then -- but I don't see it with the version of bzr I have installed.
<edgimar> (1.6.1)
<luks> bzr help uncommit should work
<luks> bzr help commands to see all available commands
<edgimar> never mind.  I think I just typed something wrong.
<edgimar> luks: hmm - rebase seems not to work so well -- I tried 'bzr rebase <trunk repo loc>", and get a traceback:  AttributeError: 'KnitPackRepository' object has no attribute 'revision_parents'.  Maybe I'll have to wait on using rebase...
<luks> hm, maybe you are not using compatible versions of bzr and bzr-rebase
<edgimar> (both installed from ubuntu repositories...)  oh well.
<luks> I don't know then, sorry
<Peng_> lifeless: fwiw, is bzr-search's new index format supposed to be 15% larger?
<rexbron> hey james_w, I had a thought about the way the config system is represented internally. Might it be better to make it like a dictionary in which the config object is loaded into memory at runtime and options are queried from the control logic, rather than as properties of the config file?
<jelmer> ronny, pong
<james_w> rexbron: yeah, I'm not keen on the config object, I wrote it ages ago, but haven't had the will to change it
<rexbron> james_w: that probably would address bug 309335
<ubottu> Launchpad bug 309335 in bzr-builddeb "Should either accept options with no section in config files, or warn about them" [Medium,Triaged] https://launchpad.net/bugs/309335
<james_w> rexbron: yeah
<rexbron> james_w: do you mean the bzr-bd config system or the one in bzrlib?
<james_w> rexbron: the bzr-bd Config object is the one I don't like
<james_w> rexbron: the bzrlib config system, built on configobj, is the one that we will need to investigate to see if we can query for section headers case-insensitively
<rexbron> james_w: looking quickly, there is bzrlib.utils.configobject that impliments a section based dictionary object
<Peng_> bzrlib.util.configobj isn't something unique to bzr; it's a packaged copy of ConfigObj.
<ronny> jelmer: ping
<jelmer> ronny, pong
<ronny> jelmer: did you write bindings for the svn workdir stuff, too?
<jelmer> ronny, yep
<ronny> jelmer: i didnt yet take a look, but i want to get rid of subprocess.call for anyvc's svn stuff
<jelmer> ronny, this is all part of subvertpy (not tied to bzr-svn)
<ronny> great
<jelmer> ronny, http://launchpad.net/subvertpy
<jelmer> the branch is in bzr at the moment, but I'm happy to migrate it to svn if that makes people more comfortable
<ronny> oh dammit
<ronny> gpl3 is an issue for me
<ronny> i need gpl2 support
<jelmer> Ok
<jelmer> I think that can be fixed :-)
<jelmer> Any particular reason you need GPLv2 ?
<ronny> hg is gpl2only
<ronny> jelmer: well, since bzr got better im more comfortable with bzr than with svn
<jelmer> ronny: Yeah, looks like relicensing should be possible since I'm the only copyright holder.
<ronny> jelmer: "gpl2 or later" would be fine
<jelmer> Yeah, that's what I would go with
<ronny> its unlikely that any of the hg/bzr libs will ever be lgpl, so there aint need to be lax
<ronny> jelmer: btw, im wondering, would it be possible to mimic a svn server using a bzr repository + the common conventions for branches + painfull magic
<jelmer> ronny, yes, we've done some work in that direction
<ronny> sounds like much pain tho
<jelmer> bzr-svn includes a "bzr svn-serve" command that provides a subversion server that accesses a bzr branch
<jelmer> it only does "/trunk" at the moment though, not any of the merged revisions yet
<ronny> hmm
<ronny> im kinda on war with bzr-svn, for some reason every time i installed it somethign in bzr broke
<jelmer> and it's quality doesn't reach beyond proof-of-concept atm
<ronny> most likely due to version missmatches
<jelmer> ronny, yeah, version mismatches are soon a problem because bzr-svn hooks into really a lot of the internal bzr APIs
<ronny> jelmer: building subvertpy complains about a missing apr-config, what package ships that?
<Peng_> ronny: Install libsvn-dev or whatever. It should pull in everything else.
<jelmer> ronny, libapr1-dev IIRC
<LarstiQ> libsvn-dev pulls in all dependencies afaik
<ronny> works fine now
<ronny> thanks
<ronny> hmm
<ronny> jelmer: btw, could the tests be moved out of the main package?
<ronny> and how fast could one get subvertpy packages into the distros
<jelmer> I'm planning on uploading to debian/ubuntu before the next version of bzr-svn
<jelmer> since it needs it
<jelmer> Any reason why you would want to see the tests moved out of the main package ?
<ronny> just seems more clean to have them out
<ronny> also makes comparing stuff more simple
<jelmer> hmmok
<jelmer> I don't have any objections to doing that per se, but need to make sure that certain utility classes/functions in tests/ are still installed, since they are used by bzr-svn for its tests
<ronny> oh, if its a dep, then you might either leave them just in, or make a util module
<ronny> jelmer: is there any doc for subvertpy
<jelmer> ronny, not much at the moment. Some of the basie guys mentioned they were working on docs but didn't hear much from them recently.
<jelmer> ronny, the tests should help to some degree (not sure how much tests there are for the working copy stuff though)
<ronny> there is one for add
<ronny> not much else
<jelmer> I'll see if I can add some more + fix the licensing after dinner
<jelmer> back later
<ronny> k, thanks
<ronny> anyone can tell me where that proposal for after-commit metadata is?
<Goundy> Hello everybody.
<Goundy> I've a quick question :)
<Goundy> I created an account+ project on launchpad
<Goundy> My source code is also hosted on launchpad and I want to learn how to delete a branch through my command line ?
<Goundy> I tried: bzr remove-tree lp:myuser/myProject/branch_name
<Goundy> but it doesn't work
<luks> you can
<luks> er
<luks> you can't delete a branch using bzr
<Goundy> ah
<Goundy> luks so I always should do it through the lp website ?
<luks> yes
<Goundy> ok no problem. Thank you luks ;)
<lifeless> moin
<lifeless> Peng_: its not surprising that it is
<Goundy> Btw, bzr rox ... it's so f***** cool !
<Goundy> I just left googlecode ... no longer wanna use svn :/
 * Goundy is going back to work
<Goundy> see you
<Peng_> lifeless: OK.
<Enisseo> hi everyone!
<Enisseo> Does someone know a way to export a changeset (every modified file of a changeset) into a file tree?
<Enisseo> for example, if in the last commit I changed file "A/b/c" and added file "d"
<Enisseo> I would do something like "bzr export -r 23..24 lastCommit/"
<Enisseo> and the file "lastCommit/A/b/c" and "lastCommit/d" are created
<Enisseo> so, maybe the "-r X..Y" and "-c X" options should be feature requests for the "bzr export" function :)
<fullermd> Mmm.  Only if export did something totally different from what it does...
<james_w> Enisseo: what would the content of the files be?
<Peng_> So, export complete copies of only the files that changed, or create patches or something?
<james_w> diffs, or the files at the last revision?
<Enisseo> the files
<Enisseo> not diff
<james_w> you could write a plugin to do that without too much trouble
<Enisseo> the idea is to zip and distribute the zip file with the files
<Peng_> You could also make the plugin zip 'em.
<Enisseo> for an user to unzip it in the right directory and overwrite existing files
<fullermd> How would that deal with moved or deleted files?
<Enisseo> Peng_: yes, indeed, as the export function does
<Enisseo> fullermd: moved or deleted files would not be managed
<Enisseo> james_w: yes, I will if no one else does know an existing plugin
<fullermd> You could hack up a prototype with just a little sh scripting.  Grab the output of stat between those revs, then cat the files into a tree.
<fullermd> Lot faster to write it directly on bzrlib of course, but...
<Enisseo> fullermd: I use Windows ;)
<lifeless> makes sense to be part of export to me
<Enisseo> To me too, since I tried "bzr export -r X..Y" directly without reading the doc
<nDuff> Where is iter_tree documented?
<nDuff> erm, iter_changes, rather
 * nDuff finds the relevant docs in InterTree.iter_changes
<leefmc> Anyone mind lookin at a little mistake command i did, and tell me where bzr pushed it to? I accidentally pushed a branch to "ssh".. ?
<leefmc> http://dpaste.com/105372/
<lifeless> well, you gave the url to push to as 'ssh'
<lifeless> so it pushed to 'ssh
<leefmc> well yea.. but where the hell is ssh? See i've had scenarios like this where i typo the push location, but it pushes anyway.. i wonder if its going somewhere weird on my comp, or my target comp, etc.. ?
<Peng_> leefmc: ls -l ~/projects/uioli/ssh
<lifeless> leefmc: its ./ssh
<leefmc> ah hah, ty
<leefmc> Now, while we are on the subject of pushing, is there any shorthand for sshing to home? I've tried lee@addy/~/repo but that didnt seem to work, i had to push to ssh lee@addy/home/lee/repo, thoughts?
<beuno> mwhudson, hi
<lifeless> leefmc: homedir isn't support on bzr+ssh yet, I believe spiv  is working on that atm
<beuno> how's it going?
<leefmc> lifeless: K ty, so the way i was forced to do is the best/only way then?
<lifeless> at the moment
<lifeless> hey beuno
<beuno> hey hey lifeless
<leefmc> ty
<beuno> lifeless, how was your break?
<lifeless> excellent
<beuno> cool, happy to see everyone back  :)
<beuno> mwhudson, I want to have a skype chat with you today about LH, if you're up to it
<mwhudson> beuno: hello
<leefmc> Question: I'm having trouble adding one repo into another, anyone know why this is? Eg, i have a projects folder which is a repo. This repo holds branches of my projects. One of these projects has many different aspects (design/programming/etc), so the programming side of it has a bzr repo and branches of its own. Its this programming repo i cannot seem to add to the project branch
<leefmc> http://dpaste.com/105382/
<leefmc> Thoughts? I've done this before with no trouble.. but im not sure what was different
<poolie> if it's versioned separately you can't add it to the enclosing repository
<poolie> unless
<poolie> you're using the experimental subtrees feature
<poolie> or you might be better using the scmproj plugin
<leefmc> well i've got almost this identical setup in another project branch.. i don't get why its working there but not here
<leefmc> hell, i was told this was a fine solution a while back in this channel heh.
<leefmc> This allows me to have entire projects be tracked/shared between all my computers, and have specific repos just focused on programming, allowing me to push to real repos and whatnot
<lifeless> I think we'd need more info on your working environment, I strongly suspect cross-wires of some sort
<leefmc> entirely possible
<leefmc> Im switching computers though, so i'll brb
<leefmc> Though.. i cant actually push my project like i would normally heh, so i gatta pindrive it :o
<leefmc> brb
<Leefmc> lifeless: Ok, so you mentioned cross wired.. Howso? Perhaps i did something wrong on this latest repo
<Leefmc> lifeless: Because i do have a different project branch, that has a repo inside of it which is use to track the actual programming. It works fine, no problems sharing, and no problems pushing/pulling
<lifeless> well bzr allows you to nest repostories, but it doesn't allow you to version a branch A as a element of branch B at the moment
<lifeless> so you *can* have A - a branch and A/B another branch, but to push them around you need to seperately push A and B
<Leefmc> lifeless: So you mean nesting branches, like repo/branchA/branchB vs nesting repoA/branchA/repoB/branchB ?
<lifeless> or use multipush or something like that
<Leefmc> because atm, i have repoA/branchA/repoB/branchB working great, just not on my latest project.. and im confused as to why
<lifeless> Leefmc: by working great, what do you mean ? :>
<Leefmc> lifeless: In repoB/branchB i am able to make modifications to the code/programming, commit them, just like i want. Then, if i need to share the entire project which has my files/etc, i can add/commit changes to branchA and commit them, then push them to my local server to be pulled by a different machine of mine
<lifeless> Leefmc: can you run 'bzr info -v' in branchA ?
<lifeless> pastebin the result
<Leefmc> An example of what i would need this for is i use an ide, and the ide has a project file for the ide. Now this file has my personal settings and junk in it, stuff i wouldn't want to submit to the public if i pushed the code to launchpad. So i actually track that aswell, in what i call a "project branch". This way i can commit&push the ide files and everything else that are just "mine" to my local server, for sharing with all my computers, a
<Leefmc> nd i still can have a repo inside the project for actual programming. Ie, stuff i would push to launchpad
<Leefmc> k one sec
<Leefmc> lifeless: I forgot, it didnt push when i switched computers (hence the problem), though on my other project im not seeing the project. Perhaps it ghosted me.. and i thought it was working?
<Leefmc> lifeless: So your saying this workflow is not possible in bazaar?
<lifeless> Leefmc: bzr won't manage the link between the branches for you today; it is planned but not done yet
<Leefmc> I've actually grown quite accustom to not having to thumbdrive my working files around computers..
<Leefmc> gotcha
<lifeless> Leefmc: you can certainly have the two branches laid out on disk in that manner
<lifeless> you just have to run bzr push in each branch yourself
<Leefmc> lifeless: Not sure if its worth it, nesting branches and pushing to multiple places just to change computers seems odd
<nDuff> Leefmc, I'm just curious as opposed to likely to be helpful -- but what's the purpose of having repoB, as opposed to putting branchB in repoA?
<Leefmc> Ie, i'd be pushing incomplete code to launchpad if i wanted to change comps, or i'd have to manage multiple places to push to (incompelete/complete/etc)
<lifeless> nDuff: I think its so that personal stuff doesn't pollute the main tree
<lifeless> nDuff: e.g. in the example above IDE settings in a containing branch, code in a subordinate one
<Leefmc> nDuff: Well for one, im a bit of a nut with clean directory structures. In this case, my project repo is strictly projects, which houses all my personal settings/notes/files for an actual project. Anything from reference images to example code to whatever. Inside that project is where i actually do work, so that may have a repo of its own where the programming is actually done. Its a matter of having strict places where things belong
<Leefmc> I've always had this project repository idea, but i've never revisioned it. Revisioning it offered insane ease of use when sharing between multiple computers, not to mention nifty bonuses (.. reivisioning) for my project itself.
<Leefmc> I probably "could" have a master repository, but then i'd be maintaining multiple sets of commits/pushes for the sake of sharing between computers and whatnot.
<Leefmc> Ie, if i have some code that is not commit-able, but i want to switch to a different computer, i'd rather not commit&push it to launchpad. So then i start managing two places to push this single branch, along with having poor commit reasons, etc.
<Leefmc> Its not impossible/implausible by any means, i just prefer a certain workflow and project organization
<Leefmc> the bad thing is now i've become addicted to the ease of pushing/pulling when i need to share my projects between my computers.. oh how will i get out of this now :o
<Leefmc> Im trying to figure out of git can handle this now
<lifeless> Leefmc: it has submodules, but AIUI you have to push each seperately too
<Leefmc> lifeless: I think i am just going to go with something a bit more advanced like some type of syncing software.
<lifeless> Leefmc: Unison is pretty nice
<the_Lorax> Howdy, Does anybody know if there is a way to install Bazaar on Windows without admin rights?
<nDuff> the_Lorax, Bazaar can be run directly out of a source directory if you're desperate, though you need to have a Python interpreter handy.
<the_Lorax> yeah, don't have python installed at work either :(
<the_Lorax> Managed to get an older version of bzr installed into a personal directory & working.
<the_Lorax> Wonder if I can just install it on a different PC and then copy over the program directory?
<igc> morning
<lifeless> the_Lorax: I'm not sure, but if there isn't an option please file a bug askinf for it :)
<lifeless> the_Lorax: because I can see that being generally useful
<lifeless> hi igc
<spiv> igc: morning.
<igc> hi lifeless, spiv!
<the_Lorax> Lifeless: I guess I'll try and if I can't get it working I'll file a bug and see if anything happens. Thanks
<lifeless> the_Lorax: the shell extensions may be tricky
<the_Lorax> lifeless: don't particularly care about the shell extensions - command line is just fine for me.
<Leefmc> lifeless: You know that projects repository i had earlier? deleting the .bzr in that will not harm any sub-repositories/files correct?
<Leefmc> Also, unison seems perfect, ty
<lifeless> Leefmc: if there are branches uses the repository you will break them
<lifeless> you can check by running 'bzr info' in the sub things and see what repository they report using
<Leefmc> but by "break them" you mean the bzr commands will not work correct? No harm to the actual files
<lifeless> I mean break
<lifeless> If they contained things have their own repository they will not be affected at all
<lifeless> if they are using the repository you want to delete, clearly they will stop working when you remove the repository
<Leefmc> yea
<lifeless> I don't know what files in specific you mean
<lifeless> if you mean 'are my checked out files on disk going to go away when I remove .bzr' -> no
<Leefmc> my bad :)
<Leefmc> yea, more like that
<lifeless> if you mean 'are the files that bzr uses independent of a containing repository' -> depends on if they are using it
<Leefmc> if i see files, deleting .bzr wont touch it. :)
<lifeless> right, bzr isn't hooked into file system at that level ;P
<Leefmc> haha
<Leefmc> good thing i got backups
<Leefmc> I forgot i don't have any working trees on my server, where i just deleted the .bzr .. :D
<lifeless> :>
<Leefmc> This is nice though, assuming unison can work the way i want it (pretty sure) i can continue to use bzr.
<Leefmc> Which is good, i've come to like it
<Leefmc> Though eventually i'll be moving back to git im sure. Once google adopts it
<Leefmc> they're working on supporting a dvcs now, and we all assume its git
<lifeless> what about google code do you like most ?
<Leefmc> Well for one, launchpad has annoyed me with its speed. It has been horrendously slow so often that i wanted to peel my eyes out heh. Thats mostly it for me. A guy who leads another project i work on is very adamant about how launchpad is confusing to clients though.. i don't personally see it that much, but google code is much cleaner/simpler when thinking from the client side
<Leefmc> Personally, i found launchpads branch system a bit confusing, and never delved that deeply into it, but from what i gather of it i actually like it. (Despite what i lack in understanding)
<Leefmc> Thats something i dont think google code even offers, where as many sites are. Forking in github, etc
<Leefmc> plus Google Code's web based code viewer is much cleaner/friendlier than i found logger to be. I found logger to be a bit ugly, too spaced out, etc.
<Leefmc> Not that easy to navigate around a code base
<Leefmc> But really, my main issue is the speed heh
<Leefmc> speed being, the time it takes for a page to load.
<jml> Leefmc: what in particular did you find confusing about the branch system?
<Leefmc> jml: That was just very early on, but i dont recall the specifics. It just took some getting used to, how a project is actually owned by a user, and not owned by the project, etc.
<jml> Leefmc: yeah, I got tripped up by that early on.
<Leefmc> And if were on the topic of making constructive criticisms here, does launchpad offer a wiki? IIRC, it does not, and for all it does offer, i was honestly very surprised it doesn't. It should, in my opinion
<jml> Leefmc: it doesn't, and pretty much everyone agrees it should. :)
<Leefmc> It seems to integrate so much, but a very common feature, a wiki, is not included
<Leefmc> jml: I actually found it simply odd that it didnt. I saw so much, so i kept assuming i was missing it :o
#bzr 2010-01-04
<_Andrew> Hi all, How do I setup the --fixed command so that it works system wide?
<_Andrew> I want to add a bug tacker for our office so that we can do something like  --fixed LR:1234
<_Andrew> tracker**
<poolie> jml, lifeless: skype apparently crashed
<poolie> jml, lifeless: actually nm, not a good use of time
<jml> poolie, ok.
<poolie> _Andrew: http://doc.bazaar.canonical.com/bzr.2.0/en/user-reference/index.html#bug-tracker-settings
<poolie> jml, lifeless, i was basically just going to say that the matcher stuff seems a bit more wordy to define and use than would really be optimal
<jml> poolie, do you have any thoughts on how it could be better?
<_Andrew> poolie, Is there a system wide config file?
<_Andrew> In the documentation it says it can go into bazaar.conf
<poolie> _Andrew: i don't think there is at the moment
<_Andrew> ah, because that's the bit I'm stuck on : /
<MFen> is there a bzr equivalent of 'hg rollback' - uncommit the last transaction harmlessly, leaving nothing in history?
<bob2> bzr uncomit
<bob2> er, spelt correctly
<MFen> also, in general what are the bzr 'undo' commands? i'm trying to figure it out from an hg background, where i have hg rollback (undo last txn), hg backout (commit a new entry that reverses a particular commit), hg strip (forcibly strip a revision from history)
<MFen> aha, thanks
<spiv> You can do "bzr merge -r -2..-3" to merge the reverse of -2 (-2 is the 2nd last commit).
<spiv> You can probably use the rebase command (from the bzr-rewrite plugin) to do the equivalent of hg strip, but I haven't looked closely (it's not an operation I've needed to do myself).
<spiv> Plus of course 'bzr revert'.
<MFen> ah right, found that one
<Peng> Note that "bzr uncommit" doesn't strip it from the repository like "hg rollback" does.
<Peng> Mostly, bzr users ignore the cruft, since it's not significant unless you commit an ISO or something.
<MFen> Peng: it doesn't?  it gave me the exact same revision number when i committed it the second time, and bzr log does not show the cruft one
<Peng> MFen: Bazaar structures things a bit differently than Mercurial./
<MFen> where would i go to observe this cruft
<Peng> MFen: You wouldn't.
<Peng> MFen: Well, the heads command from the bzrtools plugin, I guess.
<MFen> Peng: so it's dark cruft?
<spiv> MFen: yeah.  It's still in the big bucket of revisions we call the "repository", but nothing refers to it.
<spiv> MFen: in fact, when you do "bzr uncommit", it emits a command that will resurrect it if you want to un-uncommit ;)
<MFen> so does it get pushed when changes go out?
<spiv> MFen: nope
<MFen> oh ok. it's not really that different from hg then
<Peng> MFen: Except it still exists.
<MFen> no, even with that
<MFen> with strip (not 100% sure about rollback), the removed revision is saved in a backup file. but it doesn't ever leave the local clone unless you use it
<_Andrew> If you uncommit and the commit does it still exist?
<Peng> _Andrew: Yes.
<Peng> _Andrew: Did you mean "and then commit"?
<_Andrew> or what if you uncommit and then push your repo somewhere does this dark commit exist in the pushed repo?
<Peng> _Andrew: Push only pushes the revisions in the branch you're pushing.
<spiv> _Andrew: you push branches, not repos
<Peng> (Push push pushy push.)
<spiv> _Andrew: and pushing a branch will only push revisions that are part of the history of that branch
<spiv> _Andrew: so the short answer is no, it won't exist in the pushed repo.
<Peng> Yeah, your version sounds better.
<_Andrew> ah interesting
<_Andrew> So this dark commit just exists locally where you did the command
<Peng> Unless you pushed or pulled or copied it somewhere else.
<MFen> i can see how bzr's integration with launchpad could be useful.  it is convenient to say "related to this branch over here
<igc1> hi all
<MFen> seems like a lot of server maintenance though. i bet it's a headache keeping all those services working together
<spiv> igc: hey, happy new year!
<igc> hi spiv!
<igc> ditto
<spiv> MFen: no worse any other 400+ kLoC project I'm sure ;)
<spiv> (Although given that ohloh thinks that source includes -3153 lines of comments in SQL, maybe I shouldn't trust it so much...)
<MFen> every line of sql is so obscuring that it actually destroys 10 lines of comments
<MFen> if you get enough sql in one place, it starts eating python docstrings too
<AfC> :)
<MFen> god help you if there's perl.
<Peng> Idea: Embed Perl in SQL!
<spiv> MFen: https://www.ohloh.net/p/launchpad/analyses/latest says 3 code lines of Perl, and 54 comment lines...
<MFen> heh i like that the html line count is also negative
<MFen> that's because HTML is not code.
<MFen> (but it does have comments.)
<lifeless> jml: skype death?
<poolie> lifeless, spiv does bug 501254 ring any bells?
<ubottu> Launchpad bug 501254 in bzr "NoSuchRevision after parallel commit to 2 branches in 1 repos" [Undecided,New] https://launchpad.net/bugs/501254
<lifeless> poolie: not offhand
<vila> hi all, and Happy New Year !
<poolie> hello vila!
<spiv> poolie: not for me either... but 1.17 is relatively old now.
<igc> night all
<dholbach> hiya
<dholbach> is there some kind of work-around when you're not able to branch or merge from a "bazaar-ng loom branch format 7" branch with Bazaar 2.0.3?
<Peng> dholbach: ....Install the bzr-loom plugin?
<dholbach> Peng: does that loom-ify all kinds of branches?
<dholbach> I wouldn't like others to run into the same problems just because I installed the plugin
<dholbach> ... and pushed a couple of changes somewhere
<lifeless> dholbach: loomification is always an explicit step
<dholbach> lifeless: alright, thanks for that
<Borek> Hi I'm considering bzr for my version control needs and found out that the Visual Studio integration is quite dated and possibly abandoned
<Borek> How well will bzr work with code refactorings (which includes file renames, directory moves etc.) when not done via 'bzr' commands but from within Visual Studio?
<marsilainen> hi there, I'm new to bazaar, just playing with it using the olive gui
<marsilainen> is it possible to sign commits using olive?
<spiv> Borek: pretty well
<spiv> Borek: 'bzr mv --auto' will do its best to guess what the renames were, even if some edits were made to the contents of renamed file.
<marsilainen> I added 'create_signatures = always' to ~/.bazaar/bazaar.conf and then commits using olive fail when it tries to add the signature
<Borek> spiv: thanks for the pointer to mv --auto, sounds like this should do. i'll try, thanks again
<spiv> marsilainen: Hmm, that sounds like the right approach.  Hopefully someone can help you figure out why that isn't working.  Does that work for you if you use 'bzr commit' directly, without olive?
<marsilainen> spiv: hmmm, yes it does - it prompts for the gpg passphrase in the interactive terminal though so I don't know if that could be the issue
<spiv> marsilainen: could be, maybe you need to set the signing command too, to use a gpg gui
<marsilainen> spiv: ah yes, thanks - I installed gnome-gpg and set the signing command to use that - seems to work now :)
<marsilainen> spiv: thanks for your help
<spiv> marsilainen: you're welcome :)
<beuno> vila, hi
<marsilainen> ok, so I'm using bazaar for the first time... I'm starting a project which will just have me working on it initially but will then (hopefully) widen to have others working on it too
<marsilainen> if I want others to be able to view all my revisions sometime in the future, what should best-practise be from the start?
<marsilainen> should I just work with bazaar locally? or should I push each change to a server copy?
<fullermd> It doesn't really matter whether you push now or later.
<marsilainen> ok
<fullermd> Of course, you'd have trouble sharing later if you just worked locally, and then your local system blew up.
<marsilainen> heh :)
<marsilainen> maybe I will just use a remote repository in the first place
<marsilainen> at least then the workflow seems more like what I'm familiar with from svn etc
<Pilky> marsilainen: I'd recommend having a remote copy somewhere, even if you just use it for backup purposes
<Pilky> marsilainen: but there's some good workflow ideas in the user guide
<marsilainen> yeah, makes a lot of sense, and that's what I'd normally do with something like svn. I just wasn't sure if that was the appropriate way of working in a distributed version control like bazaar
<marsilainen> I'm reading http://doc.bazaar.canonical.com/bzr.1.18/en/tutorials/centralized_workflow.html now and I will probably go with something from there
<marsilainen> thanks for the help
 * Kinnison finds that the bzr 'centralized workflow' doesn't work well for him.
<Pilky> one of the huge benefits of bzr over the other DVCSs is that it is incredibly flexible with the workflow
 * Kinnison has been using bzr since it was barely able to revision-control itself though :-)
<Pilky> heh
<beuno> vila, when you get a chance, and you take a peak at: https://code.edge.launchpad.net/~beuno/bzr-upload/bug-499525/+merge/16552
<bialix> happy new year bzr!
<rubbs> happy new year bialix
<bialix> and you roo
<bialix> and you too
<bialix> sorry
<rubbs> no problem
<Noldorin> hello. i'm trying to use bzr-git here to push to git-hub, but i've noticed that dpush seems to be using the wrong plugin:
<Noldorin> in bzr.log:
<Noldorin> 0.851  bzr-svn: using Subversion 1.5.6 ()
<Noldorin> the URL is however: git+ssh://git@github.com/Noldorin/IRC.NET.git
<Noldorin> what am i doing wrong here?
<vila> beuno: I saw it, it's on my TODO list. We should reuse more bzrlib code, but it's not as easy as it should. But using is_inside_any looks... risky, are you sure you won't get false positives with it ?
<beuno> vila, I started writing something that was almost the same, so I read through it and re-used it
<vila> beuno: you mean is)inside_any
<vila> beuno: you refer to is_inside_any ?
<beuno> vila, yes
<Pilky> hey all, I've got a question about the capabilities of the shelf API
<vila> beuno: my concern is that bzrlib doesn't do that and I don't want to have a divergent implementation (users will get confused, we'll need to document the differences, etc)
<Pilky> is it possible to unshelve individual changes and show shelved changes as a flat set
<james_w> Pilky: unshelve individual changes: probably with some work (depending on the granularity)
<vila> Pilky: you can *shelve* individual changes, not unshelve them
<james_w> Pilky: what do you mean by "a flat set"?
<james_w> vila: with the API
<james_w> happy new year too :-)
<Pilky> well I'm trying to design a UI for it in BazaarX, and I'm looking at showing the shelved changes in a list and unshelved changes in a list, and you can drag changes on and off the shelf
<vila> james_w: given what is exposed from command line, I suspect that's also true for the API.
<vila> Pilky: what do you call an individual change ?
<beuno> vila, bzrlib doesn't do what?
<james_w> vila: yes, the API doesn't provide for it, but if you make the merger then you can do .set_interesting_files() for the files level.
<vila> beuno: use is_inside_any
<Pilky> vila: what the shelf API classes as an individual change
<james_w> for hunks you would have to create a memory tree and then re-shelve hunks back off it or something
<james_w> I imagine it is tricky but possible
<Pilky> right
<james_w> doing it for individual changes should be straightforward
<james_w> <make changes>; bzr shelve --all; <make changes>; bzr shelve --all; will show up as two things
<james_w> manipulating those two things as they are should be straightforward
<vila> beuno: bzrlib builds a globber and then try matching paths against it, I think that generalizes what you tried with is_inside_any, but I need to check more carefully what you did and what bzrlib does
<beuno> vila, ok. So I leave it with you?
<Pilky> james_w: yeah possibly
<vila> beuno: yup, I'll try to review asap
<beuno> vila, thanks  :)
<vila> beuno: thanks for working on it :-D
<jelmer> vila: Hi
<vila> jelmer: hey !
<jelmer> vila: First of all, happy new year :-)
<jelmer> Do you have some thoughts about this, is it something we can fix:
<vila> jelmer: same to you :D
<jelmer> wilmer@ruby:~/src/bitlbee/libpurple$ bzr pull http://code.bitlbee.org/wilmer/libpurple/
<jelmer>  http://code.bitlbee.org/wilmer/libpurple is permanently redirected to http://code.bitlbee.org/wilmer/libpurple/
<jelmer> vila: Why is the trailing slash lost somewhere?
<vila> jelmer: it's a one-line fix to bzrlib to make it stop to remove that trailing slash
<vila> I remembered abentley and lifeless talking about it.... months ago at a sprint, but it seems that the patch got lost somehwere..
<Noldorin> hi jelmer. i think i've figured out what the problem was
<vila> ...well, nobody looked at the consequences if any to be honest
<jelmer> vila: Ah, thanks
<jelmer> Noldorin: Cool, what was it?
<Pilky> james_w: might be worth just changing how the UI works to fit in with how it is intended to work, so that it doesn't confuse bzr users.
<vila> jelmer: but my recollection of the problem is that many places handle (or not) the final slash, and I've always pushed that item down my stack...
<Noldorin> jelmer: well, it's not solved....but what is happening is it seems to be using the bzr-svn plugin still :S
<Noldorin> in bzr.log:
<Noldorin> 0.851  bzr-svn: using Subversion 1.5.6 ()
<Noldorin> even when i use git+ssh url
<jelmer> Noldorin: That's only loading the svn plugin, not using it.
<Noldorin> hmm
<Noldorin> so maybe not :S
<jelmer> It's correct, the bzr-svn plugin has to register itself on startup (bzr-git does something similar)
<Noldorin> i see
<Noldorin> jelmer: http://pastebin.com/m4c073a7 is the last part of the log
<Noldorin> jelmer: does that help?
<jelmer> Noldorin: no idea, sorry
<Noldorin> ok no prob
<james_w`> vila!!!
<james_w`> nice resolve proposal, thanks
<vila> james_w`: glad you like it :)
<james_w`> it's a small thing, but will be very useful
<vila> james_w`: it was pretty hard to isolate, but more can (and will)  be done
<james_w`> oh, sorry, I didn't mean to detract from your effort :-)
<vila> as said in the cover letter, there are many hints already inserted in the relevant places
<james_w`> I meant that it's not a headline feature, but will be very useful
<vila> james_w`: I think so, the tree-shape conflicts are confusing for many people (including me no later than 2 hours ago :)
<james_w`> heh
<vila> james_w`: and for people that have to deal with tenths if not hundreds of conflicts, I think it's a bit more than a small feature :-D
<fullermd> All features are small.  Until you need them.
<vila> . o O ( Small hammers ? Really ?)
<fullermd> If the only tool you have is a hammer, every problem looks like a thumb.
<Tak> jelmer: pong ;-P
<jelmer> Tak: heh, that was a roundtrip of a couple of days ? :-P
<Tak> at least
<Tak> I'd better check my connection
<Noldorin> hello
<Noldorin> i've accidentally just done a merge from a remote branch...
<Noldorin> which has just renamed all my working files to .moved
<Noldorin> how i restore these .moved files to be the normal ones?
<Noldorin> (overwriting the ones i just pulled from the remote branch)
<Noldorin> ?
<fullermd> revert.
<fullermd> But if it really renamed a huge pile, that's probably a sign that something's not what you think it is.
<Noldorin> fullermd: revert reverts to my last commit
<Noldorin> i made changes, then updated before i committed
<fullermd> Well, revert on the individual files.
<Noldorin> hmm ok
<fullermd> But still, having a big number of files conflict like that is a big flashing danger sign anyway.
<idnar> well, he said the merge was accidental
<Noldorin> fullermd: yeah, revert isn't quite what i want
<Noldorin> basically i want to find a way to revert to all my .moved files/dirs
<Noldorin> jelmer: i've given up on git for the moment and am just trying to get bzr-svn to work...
<Noldorin> the problem is just that i get this error when i try to push: bzr: ERROR: These branches have diverged.
<jam> good afternoon #bzr world
<beuno> heya jam
<kirkland> how do I solve this: http://pastebin.ubuntu.com/351370/
<kirkland> "different rich-root support" error
<beuno> kirkland, upgrade locally or remotely
<kirkland> beuno: "bzr upgrade" ?
<beuno> kirkland, if you have 2.0+, yes
<kirkland> beuno: karmic
<beuno> /tmp/tmp.7XKeNG4ej8/ubuntu is likely the old one
<beuno> kirkland, yes, just plain upgrade
<kirkland> beuno: cool
<jelmer> Noldorin: what are you trying to do exactly?
<Noldorin> jelmer: simply push to a svn server
<Noldorin> (on codeplex)
<Noldorin> just created a project
<jelmer> Noldorin: are you pushing a new branch?
<Noldorin> yep
<Noldorin> https://ircdotnet.svn.codeplex.com/svn
<jelmer> Noldorin: and you're pushing to  https://ircdotnet.svn.codeplex.com/svn/trunk ?
<Noldorin> yep
<Noldorin> erm
<Noldorin> jelmer: heh, seems the problem has stopped now, never mind :)
<Noldorin> jelmer: well, in case it helps: the problem with bzr-git and the publickey being denied happens for whatever url i put in :S
<Noldorin> seems we're both clueless here though
<jelmer> Noldorin: I suspect it's windows specific
<Noldorin> jelmer: yeah. well, i'll leave it to you if that's alright...
<Noldorin> jelmer: feel free to ping me any time if you want me to do some testing though
<elmo> hey, is there any way to import a single file and it's history into another tree that's unrelated to the tree that file came from?
<jelmer> elmo: only by merging the other tree and then reverting all of the files other than the one you want to merge
<elmo> failcats
<elmo> jelmer: ok, thanks
<fullermd> elmo: Alternate phrasing: files don't have history; history has files.
<elmo> I think 'failcats' is shorter and more to the point
<elmo> ;-)
<fullermd> Yes, but such a slur against the feline race is likely to get you murdered in your sleep by one or ten of them.
<jelmer> :)
<phoenixz> Its normal for BZR to take 95% CPYU for a long time when bzr log of a specific project sub directory?
<beuno> phoenixz, it's not
<beuno> what version of bzr and what format is the branch?
<phoenixz> beuno: should be one of latest, one sec..
<phoenixz> beuno: 2.0.0
<beuno> phoenixz, and what does
<beuno> "bzr info -v" say?
<phoenixz> beuno: bzr log .
<phoenixz> beuno: http://pastebin.com/f65622fb1
<beuno> so it's the latest and greates
<beuno> *greatest
<beuno> phoenixz, is the branch public?
<phoenixz> beuno: public? nah, its on my local computer
<beuno> phoenixz, I'd file a bug about it, but it may be hard to debug without the actual branch
<phoenixz> beuno: bzr log works like a charm though.. bzr log in a sub directory makes it hang like this
<beuno> right, it's a more expensive operation, but it shoulldn
<phoenixz> beuno: well, problem is that I cant publish (all) the code.. I'll try to have the open source part republished soon
<beuno> be so bad
<beuno> jam, you around?  any idea how to transform phoenixz's issue into a bug report?
<jam> just a sec, open bug
<phoenixz> jam: this is an existing bug?
<jam> bug #374730
<ubottu> Launchpad bug 374730 in bzr "log dir is slow in development-rich-root" [Medium,Fix committed] https://launchpad.net/bugs/374730
<jam> This should be in 2.0.1
<jam> well, my phase-1 fix is supposed to be there
<jam> phoenixz: ^^ you might try upgrading your bzr and see if it helps
<jam> phoenixz: If you look at my timings, for small subdirs you can see:
<jam> "time bzr log -n0 --no-aliases tools" went from
<jam> Â Â real    5m16.959s
<jam> down to
<jam> Â Â real    0m37.888s
<jam> for a larger dir (bzrlib) it was only ~2m
<beuno> wow
<phoenixz> jam: wow..
<phoenixz> jam: well, this project has about 40.000 files so I expect it not to be realtime but Ive b een waiting 5 mins with bzr on 95% :)
<jam> phoenixz: how big is the subdir you are looking at?
<phoenixz> jam: not big, like.. total of 7 directories and 30 files in the entire tree..
<jam> phoenixz: definitely try bzr 2.0.1+ (or 2.1*)
<phoenixz> jam:  will do
<knittl> hi, what is the current way to create a bzr branch?
<knittl> i have an old copy lying around, but it won't update
<knittl> "permamently moved to xxx. not a branch: xxx"
<beuno> knittl, a new branch?  bzr init .
<knittl> beuno: no, i want to clone the official bzr repo
<beuno> knittl, bzr branch lp:bzr
<knittl> can i change the remote of my current repo?
<knittl> i don't want to pull everything again
<beuno> knittl, bzr pull lp:bzr --remember
<knittl> great, thanks
<fullermd> If it's old enough to be using a nonexistent URL, I tend to suspect it's also a pre-2a format branch too.
<fullermd> And re-pulling everything is probably faster than doing a local upgrade, unless you have a pretty slow connection.
<knittl> fullermd: it's alreaty finished pulling
<fullermd> Oh.  Then ignore me   8-}
<knittl> * already
<knittl> need to clone all dvcs
<knittl> :)
<knittl> phew, hg was fast
<ronny> knittl: why clone all of them?
<knittl> i'm writing a paper
<knittl> and i want to have the latest incarnation of each
<ronny> on what?
<knittl> on dvcs's
<maxb> knittl: ooi, what's your definition of "all" ?
<knittl> xD git, hg, bzr, maybe darcs
<lifeless> ah, so 'some'
<knittl> the most popular ones
<knittl> and open-source
<knittl> monotone if i have time
<ronny> knittl: well, so what is the exact topic?
<knittl> analysis and comparison of distributed version control systems
<ronny> i see
<ronny> i suppose you wont propose ideas for conceptual unifications
<ronny> (im writing a vcs abstraction lib, good ideas might be helpfull)
<knittl> no *g*
<knittl> is there a bzr online browser? like git's gitweb
<beuno> knittl, yes
<beuno> loggerhead
<knittl> for the official repo?
<beuno> this is a working version: http://bazaar.launchpad.net/~loggerhead-team/loggerhead/trunk/changes
<beuno> this is for the official repo: http://bazaar.launchpad.net/~bzr/bzr/trunk/changes
<knittl> i need to browse commits by id
<beuno> sure
<beuno> http://bazaar.launchpad.net/~bzr/bzr/trunk/revision/pqm@pqm.ubuntu.com-20090903012533-qc6kvh5ujgk8042p
<beuno> http://bazaar.launchpad.net/~bzr/bzr/trunk/revision/$id
<beuno> you can run loggerhead locally if you want
<beuno> it will probably be much faster  :)
<knittl> no, i need official urls for my paper
<dobey> hi all
<dobey> http://pastebin.ubuntu.com/351433/ <- anyone have an idea what that would be? i'm quite confused :)
<knittl> permission problems with the lockfile/folder?
<dobey> i'd think permisions would give -EPERM no? and it's a fresh branch, so nothing should have changed perms
<lifeless> knittl: I don't know what you mean by official urls
<lifeless> knittl: its a distributed system
<knittl> lifeless: beuno's urls are perfect
<knittl> i know it's distributed. i understand the idea behind distributed systems
<dobey> oh nevermind
<dobey> i am an idiot
<scanferlato> hi knittl, mind a question?
<knittl> scanferlato: what is it?
 * dobey suddenly remembers that the bzr gtk things hold the lock
<dobey> sorry to bother :)
<scanferlato> i.e. when you checkin, the repository stores the checkin and mtime of the file
<scanferlato> when you chekcout/branch/export, it gives you three choices for the mtime: current, checkin, and last modification
<scanferlato> AFAIK, only one VCS has it, and it is not a good one (Visual Source Safe)
<knittl> â¦ and the question is?
<knittl> it's never good to rely on mtimes
<knittl> but having certain mtimes for files might be a good thing for build systems like make
<scanferlato> yes, that's when you uses a DVCS to store source code. But you can store other things as well
<fullermd> I don't think bzr stores mtimes in the first place.
<scanferlato> the question is: do you know of any DVCS that has this feature?
<knittl> when is mtime important?
<fullermd> I don't know of any that store mtime.  I'd be a little surprised to find out any did.
<fullermd> I'm pretty sure none use the commit time by default.  Not sure if any have the option.
<jam> fullermd: you *can* use the commit time, but no, we don't store the last-modified time at commit
<scanferlato> when you store e.g. a Word document, and your company policy is to print the date of last change on the first page of the document
<jam> scanferlato: wouldn't that either be a Word feature, or something you have to do before checking it in anyway?
<jam> you could always do "bzr log FILE" to find out after the fact
<scanferlato> jam: even if you have tens of documents in several folders?
<jam> so, if it is supposed to be in the document, that obviously needs to be done before commit
<jam> and if you had to do it after the fact
<jam> you would probably prefer to give it the
<scanferlato> yes, it is the mtime set by Word itself, when you save it
<jam> timestamp of the actual content change
<jam> rather than the time that you added the timestamp
<jam> scanferlato: so Word has an option to include the mtime of the file as a date-stamp in the document?
<jam> Wouldn't it record an actual 'last modified' time internally?
<jam> since if I send a file to you
<jam> without you changing it
<jam> just saving
<jam> would create a new mtime
<jam> by OS rules
<scanferlato> yes, it is something like a macro or an internal variable
<jam> my point is to be valid, it really has to be an *internal* variable
<jam> using the filesystem's mtime is bogus
<jam> for *lots* of reasons
<jam> copy file.doc newname.doc
<jam> etc
<scanferlato> I have to check this
<knittl> there's no way in word to use last mtime
<knittl> it's possible to use a fixed time or "current" system time
<scanferlato> the point is to get the file from the repository exactly as it was when I check in. Including the timestamps
<scanferlato> *checked
<knittl> is this even possible from an os standpoint?
<jam> bzr log --last 1 FILENAME | munge to date | xargs touch FILENAME
<jam> knittl: you can set mtime usually
<jam> but not atime
<jam> or ctime
<jam> scanferlato: note that we also don't version anything but whether it was executable
<jam> so we won't give you group or user
<jam> or permission bits
<jam> (acls for Windows users)
<scanferlato> no problem, so far I did not need permissions
<knittl> hmâ¦
<scanferlato> group, user, etc. Just the timestamp of the last change
<jam> scanferlato: so you could get the commit timestamp out, especially if you use bzrlib's code.
<jam> but there isn't a way to tell bzr to touch all the files with that time
<jam> spiv: /wave
<scanferlato> I believe CVS is able to do that
<spiv> jam: hey
<jam> just saw you on the bugtracker, figured I'd say hi :)
<spiv> jam: I just reviewed your fix for 'cdef void'
<spiv> jam: short version: it's good, but you missed a bit ;)
<spiv> jam: (as in, it fixes this bug, but it looks like the same bug is lurking elsewhere in our pyx files)
<jam> spiv: will respond when I see the message
<spiv> jam: you'll particularly love the instance of it in _knit_load_data_pyx I think ;)
<jam> spiv:Don't care about _knit_load_data, tbh
<jam> *old* code, only used in knit formats
<jam> which are 2 major versions old now :)
<spiv> Yeah, and its not an important bug even then... but still funny.
<fullermd> scanferlato: CVS doesn't store *time.  cvs co does set the file timestamp to the commit time.
<scanferlato> I believe CVS is able to do that;
<scanferlato> sorry
<knittl> i don't believe in cvs, sorry
<scanferlato> fullermd: yes, CVS exports/checkouts set either current or commit times
<scanferlato> knittl: ideally we should not believe in anything, but use whatever works well and does what we need
<knittl> cvs does not work well for me
<knittl> ^^
<scanferlato> so far only VSS does what I need, but I refuse to use it
<igc> morning
<igc> hi spiv, jam
<fullermd> Well, *I* believe in CVS.  I've seen the fire stirring in the belly of the beast...
<lifeless> james_w: hi
<james_w> hi lifeless
<lifeless> james_w: is my ppa watching bzr builder branch merged ?
<james_w> not yet
<lifeless> ok
<lifeless> is there more I need to do than nag? :)
<scanferlato> g'night all, and thanks for your time
<james_w> did you say that you had fixed some of the issues?
<lifeless> james_w: yes, I did
<james_w> that will help then
<lifeless> Its important to the dx team that this works, and for stopping it be adhoc-deployed by being able to switch to packaged releases of buidler
<lifeless> As I've said I'm happy to do fixes to it in trunk too.
<jam> morning igc
<jam> and lifeless
<lifeless> hi jam igc spiv poolie
<igc> hi lifeless - Happy New Year
<poolie> hello igc!
<igc> hi poolie james_w
<james_w> hi igc and everyone
<poolie> welcome back, all
<jam> hey poolie, didn't think i'd see you tonight
<poolie> hi jam
<poolie> on phone atm
<lifeless> jam: still around?
<jam> lifeless: I am right now, but probably not much longer
<lifeless> was wondering if junitxml + subunit was working better for you now, with the releases I did
<jam> lifeless: I haven't been playing with hudson for a while
<jam> I think it was going in the right direction, but I haven't tested it
<lifeless> ok, thanks.
<jam> off for now, see y'all around tomorrow
<jam> spiv: you might want to take a look at lp:///~jameinel/bzr/2.0.4-pyrex-propagation
<jam> and tell me what you think
<lifeless> jam: night
<spiv> jam: ok, thanks
<poolie> hi spiv, lifeless
<poolie> lifeless: quick call?
<lifeless> sure
#bzr 2010-01-05
<igc> poolie: can I land https://code.edge.launchpad.net/~ian-clatworthy/bzr/user-ref-topics/+merge/16750 now?
<jelmer> lifeless: Hi
<kirkland> i need to generate a diff with bzr diff, but I need the resulting patch to have a -p1
<kirkland> is there some option i can pass to bzr diff to add an arbitrary additional leading dir?
<fullermd> -p
<kirkland> fullermd: cheers
<poolie> hi igc
<poolie> igc, yes
<igc> poolie: thanks
<bendj> Hi.  Reading in UserGuide, "Trailing slashes on patterns are ignored. If the pattern contains a slash or is a regular expression, it is compared to the whole path from the branch root. Otherwise, it is compared to only the last component of the path."  is unclear to me.  If I want to ignore a directory (e.g. "sites/") and all it's contents that's in my current directory, which of the following do i add to .bzrignore?  "sites", "sites/", "./sites", etc etc ?
<spiv> bendj: do you want to ignore any file/directory called 'sites' anywhere in your tree, or just at the root?
<spiv> if you just want to ignore it (and thus everything under it) at the root, you want "./sites" I think.
<lifeless> jelmer: hi
<jelmer> lifeless: Any chance you could follow up to my reply in https://code.edge.launchpad.net/~jelmer/bzr/repo-size/+merge/16582 ?
<jelmer> lifeless: Basically, I'd like to have an overridable function for the number of revisions since that's all I want to override for foreign branch implementations
<spiv> bendj: to be precise, "./sites" will ignore (root)/sites as well as everything under it.  If just want to ignore everything under it (but not ignore (root)/sites), then I think you'd want "./sites/*".
<meoblast001> hi, i accidently did something in the middle of writting a commit message that locked my branch, how do i force unlock?
<cody-somerville> meoblast001, bzr break-lock
<spiv> meoblast001: perhaps you have "bzr diff | less" or similar still open in another terminal?
<meoblast001> bzr: ERROR: The lock for '/home/braden/Documents/Development/citrine' is in use and cannot be broken.
<meoblast001> spiv: i accidently hit control+z
<meoblast001> fixed it
<meoblast001> what's this
<meoblast001> unknown:   bzr_log.kvvUj5   bzr_log.kvvUj5.save
<Peng> meoblast001: You ran "bzr commit" without supplying a message, and it bzr opened an editor, with that filename.
<Peng> meoblast001: The .save file is presumably something from your editor/
<bendj> spiv Thanks.  That clears it up!
<spiv> bendj: great, glad I could help :)
<poolie> hi spiv
<poolie> spiv, patch pilot mail?
<spiv> poolie: ah right, yes.
<poolie> this is your cue to nag me about the hottest100 mail :)
<spiv> poolie: consider yourself nagged ;)
<poolie> :)
<chalkbag> Hey folks, is there a way to change author info on revisions committed locally?
<chalkbag> I put in a wrong email addy :(
<bob2> you could use bzr-rebase, I think
<chalkbag> bob2, hmm, I don't think it's in Fedora repos :o
<lifeless> its now called rewrite
<bob2> ah
<chalkbag> Sigh - still not there :( I'll install it from source, I guess. Thanks for the pointer!
<_Andrew> Is there a way to check  --append-revisions-only has been set on a branch and also, is there a way to set it after a branch has been initialized?
<bob2> you can edit .bzr/branch.conf or so
<_Andrew> ah
<_Andrew> when you init a bzr with  --append-revisions-only it just adds a setting in the branch.conf
<_Andrew> Thanks, I understand now
<brmassa> guys, how can i disable the bzr-notify from my ubuntu?
<AfC> brmassa: uninstall the bzr-dbus package?
<brmassa> AfC: i dont know exactly. it seems bzr-notify only notifies me that i commited some code, which is pointless since i know what i just did. and its using my pc's resources. so i want to remove it at least from boot.
<_Andrew> Can I merge changes from branch6 format into 2a format?
<Peng> _Andrew: Those two branch formats can intermingle fine. It's the repo format where you may run into trouble.
<_Andrew> repo format?
<spiv> _Andrew: look at the output of 'bzr info -v', for instance.
<_Andrew> ah ok
<spiv> The formats of the different components (working tree, branch, repository) are largely orthogonal.
<_Andrew> http://paste.ubuntu.com/351642/
<_Andrew> Well, that's what I have before and after upgrade
<_Andrew> It looks like the repository format is different too, so does that mean it's a problem?
<Peng> I don't see a problem?
<spiv> _Andrew: that all looks fine to me
<_Andrew> great
<_Andrew> thanks
<spiv> _Andrew: those are all the most current formats
<spiv> _Andrew: and the same as you'd get with e.g. 'bzr init' from a new version of bzr.
<_Andrew> because we have some code I need to merge into the newly upgraded repo from the old format
<_Andrew> from another repo in the old format **
<spiv> Unless you've been using experimental formats, you can always take history from old to new.
<_Andrew> ah ok
<spiv> (In this case you won't be able to take commits made in the new repo back into your old repo though.)
<_Andrew> That's fine. I just want to be able to move over all the commits from everyones branches before moving everyone over to the new repo
<poolie> vila, hi?
<vila> hi all !
<vila> hey poolie !
<poolie> hi vila
<poolie> how about a quick call?
<vila> poolie: just a sec
<bialix> heya bzr
<Peng> Good morning. :)
<bialix> hi Peng
<vila> hi bialix
<bialix> hi vila, happy new year!
<vila> bialix: you too  !
<jszakmeister> hi balix!
<jszakmeister> Would have time for some QBzr/QShelve related questions?
<jszakmeister> If not, I can just send them to the list.
<mathrick> hiya
<mathrick> is there a way to find out what revisions are in the store that aren't in the tree?
<mathrick> ie. if I have uncommitted some time ago and would like now to get back that revision, how do I get to that revspec bzr prints when you do uncommit?
<bialix> hi jszakmeister!
<bialix> happy new year
 * bialix bbiab
<bob2> mathrick: bzr heads
<Peng> mathrick: The original uncommit command, and the "bzr pull" suggestion it spits out, might still be in your .bzr.log as well.
<mathrick> bob2: thanks, lemme try that
<mathrick> uh-huh, it seems to go through everything in this shared repo
<bob2> could be
<mathrick> and now it hits some SVN branch which tries to "analyse layouts" of 1365 revisions at the rate of 1 revision per 5 minutes
<jszakmeister> mathrick: maybe use --dead-only?
<jszakmeister> I've not used bzr heads much... so I can't so for sure it will help you.
<mathrick> jszakmeister: that's what I tried, but it still insists on touching that bzr-svn one
<mathrick> I'm trying to dissuade it now
<jszakmeister> Bummer. :-(
 * bialix back
<bialix> jszakmeister: ping?
<jszakmeister> Yep, I'm here.
<jszakmeister> Quick question
<jszakmeister> I'm looking at qshelve stuff again (sorry for the long break)...
<jszakmeister> I was originally thinking of using the TreeWidget...
<Peng> At worst, you can temporarily disable bzr-svn.
<Peng> mathrick: ^
<jszakmeister> but the more I look at it, the more I'm thinking that maybe I shouldn't
<jszakmeister> I need to open the diff editor by default, need tristate checks (which I think I can do, but I'm not sure yet), and there were a couple other small things.
<jszakmeister> Should I just do something else, or should I refactor TreeWidget to allow me to override the behaviors I need?
<bialix> oh
<bialix> maybe ScrollableArea?
<bialix> do you want to use side-by-side diff?
<jszakmeister> I thought we were going to call out to a tool as a first cut?
<bialix> mmm, I don't understand
<mathrick> peng: yeah, that's what I arrived at now, trying to make it not raise from the dead :)
<jszakmeister> I meant I need to override the default double click behavior in TreeWidget in the changes view.
<jszakmeister> I think we want it to open the external tool when you double click on a modified file so that you can shelve some of the changes, right?
<bialix> jszakmeister: I think I forgot some details
<jszakmeister> It's been a while. :-)
<bialix> yep
<bialix> and I was too busy with work
<jszakmeister> Same here
<jszakmeister> Lemme dig up a link real quick...
<bialix> TreeWidget is the most universal widget it seems
<bialix> do we really want it?
<jszakmeister> That's basically my question.  It's nice because it already collects the changed files...
<bialix> just to create list of files? that's will be nice,we have similar in treewidget.py
<jszakmeister> I'm sorry... that's the tree widget I'm talking about. :-)
<bialix> do you mean built-in qt QTreeWidget or Gary's treewidget.py?
<jszakmeister> Gary's
<bialix> oh
<bialix> yep
<bialix> I'm guess reusing that widget is the right way
<bialix> it's already has enough power and allows customization
<bialix> you made a sketch at first about 2 panel side-by-side interface
<jszakmeister> Is it a problem if I subclass it?
<bialix> but then we talked about using external tool to get more fine grained control over changes to shelve
<bialix> why that's a problem?
<jszakmeister> Just looking to do what is acceptable. :-)
<jszakmeister> I've been on some projects that have a methodology that discourages subclassing.
<jszakmeister> I think I can subclass and override the few bits that I need to make it launch an external tool.
<bialix> do you need subclassing to override some methods?
<jszakmeister> Yes.
<bialix> if these bits are not generic enough then I don't see a problem with subclass
<bialix> what is the reasons to avoid subclassing?
<bialix> speed of python?
<jszakmeister> Seriously, I have no idea... they're were just adamant about a few things, and that was one of them.
<bialix> it was a python project? or?
<jszakmeister> Either you built everything into the class, or you duplicated code. :-(
<jszakmeister> Java, IIRC
<bialix> have no real experience with Java, sorry
<jszakmeister> It was just stupid policy. :-)
<bialix> in Python very deep subclassing may affects performance, IIRC
<bialix> but it's not the case yet
<jszakmeister> I could see that with having to scan the base classes for a method.
<bialix> yep
<jszakmeister> Thanks for the help.  I'm gonna see if I can get something more working this week.
<jszakmeister> Off to work!  Happy New Year!
<bialix> will be nice! let the power be with you :-)
<bialix> :-)
<bialix> rats, wrong quote
 * bialix sighs
<mgolisch> whats the easiest way to setup some location to store bzr branches?
<mgolisch> sftp?
<Peng> mgolisch: I'd probably do it over SSH, but I'm already SSHed into my bzr server anyway.
<Peng> mgolisch: bzr init-repo should be able to take a remote location/
<mgolisch> is there a way to list all branches and some info about them from a repository?
<mgolisch> didnt find anything that sounds like that from bzr help commands
<jam> morning all
<Peng> mgolisch: The bzrtools plugin provides a "bzr branches" command. Just gives a list, no other info, though.
<Peng> mgolisch: Also, can be horribly slow in the face of bzr-svn...
<mgolisch> basicaly what i want is setup a shared repo that could be accessed by all workstations here, and that would allow ppl to create new branches in it and operate in them from their workstations
<mgolisch> without having to do any fancy cmdline foo on the server to create new branches etc
<Peng> Oh.
<Peng> I thought you meant the initial setup.
<Peng> Sure, creating new branches just takes a "bzr push".
<Peng> Dunno how you should set it up, though... You could give everybody one SSH login, or give them each their own shared repo (or use stacked branches) and have them use different users.
<Peng> s/give everybody one SSH login/use the same SSH login for everybody/
<bialix> hi jam, and happy new year!
<mgolisch> Peng: thx i think ill go with only one ssh login/user
<mgolisch> :)
<jam> happy new year to you bialix
<bialix> :-)
<jam> james_w: are you around for a chat?
<james_w> hi jam
<jam> james_w: just trying to follow up on udd/hottest100 and feel a bit lost
<jam> I figured I might as well poke at the bugs you've filed so far
<jam> and at least see where they are at
<jam> for example, bug #496764, are you working on that, and/or is it something that helps the import stuff?
<ubottu> Launchpad bug 496764 in bzr "want a hook for diverged graphs" [Medium,Confirmed] https://launchpad.net/bugs/496764
<jam> Or is it just helpful for the builder side?
<james_w> it's not an import thing
<james_w> it's for the user experience
<jam> james_w: what about bug #484228
<ubottu> Launchpad bug 484228 in bzr "Issue when merging cwidget: bzrlib.errors.NoSuchFile: No such file: ('changelog-blahblah') in iter_file_bytes" [High,Confirmed] https://launchpad.net/bugs/484228
<jam> you marked it invalid in bzr-builddeb
<jam> but it is still open in bzr
<jam> the discussion sounds like it is just a dupe of another bzr bug which has been fixed
<james_w> that may well be the case
<jam> and bug #492647, that seems more like import-side issues, but is it hitting any of the 'hottest100' ?
<ubottu> Launchpad bug 492647 in bzr "\r not allowed in commit message" [Low,Confirmed] https://launchpad.net/bugs/492647
<james_w> I left the bzr task open so someone more familiar with the other bug could make the judgement
<jam> k, I'll close #484228
<jam> we can re-open later if necessary
<james_w> I don't know if that's a hottest100
<james_w> as you say, kerberos isn't, I just opened it at the request of mathiaz
<james_w> should we have a hottest100 tag as well as udd?
<jam> james_w: that is what it sounded like in Martin's last email
<jam> the idea being our first focus target for helping udd is getting the top 100 imports working
<jam> james_w: and the last udd bug #488724
<ubottu> Launchpad bug 488724 in bzr "commands updating working tree should provide the same modification time for all modified files" [High,Confirmed] https://launchpad.net/bugs/488724
<jam> this sounds like we need to settle on a timestamp, and then have transform set the mtime on all files before it moves them into the working dir.
<jam> But I don't really understand why this is a udd bug
<james_w> yep, was just thinking from an organisational perspective. You will want to see the list of outstanding hottest100, while we still want lists of udd bugs.
<jam> james_w: right
<james_w> I'm not exactly sure about that one
<james_w> I think it was filed after discussions at UDS, but I can't remember if I was involved, or which problem we were talking about
<vila> jam: because it was mentioned as a top wish list item in UDS
<jam> hey vila, happy new year, btw
<jam> I was missing you around here :)
<vila> jam: hey, yeah, you too :)
<jam> I should be getting my espresso machine today
<jam> \o/
<vila> hehe, can't start the day without one myself :)
<jam> well, I have a crummy steam-powered one that does both drip and "espresso", but I'm upgrading to a genuine one
<jam> vila: http://www.amazon.com/dp/B000TBEU3S/ref=asc_df_B000TBEU3S994674?smid=ATVPDKIKX0DER&tag=googlecom09c9-20&linkCode=asn&creative=380341&creativeASIN=B000TBEU3S
<vila> ouch,mine is far less expensive (I seem to remember we pay ~100 euros, maybe 150) but still makes the best expresso I know about :) I could buy a new SSD for that price :-D
<vila> hmm, wth happens on my SSD *right* now ? :-/
<jam> vila: well, I got it from a different place that had a cheaper base price *and* 20% off. I was just looking for a picture :)
<jam> and at the EU => USD conversion, isn't that about the same price now? :)
<vila> lol, I wish :)
<jam> http://www.google.com/search?q=euro+to+usd
<jam> says 1.44:1
<jam> So I guess closer to 210EU
<vila> wow, I'm still not used to that, I'm used to Apple prices being 1 EU == 1$ :-D
<vila> http://www.amazon.fr/Krups-F88042-Cafeti%C3%A8re-espresso-noir/dp/B0002JZ2D4/ref=sr_1_23?ie=UTF8&s=kitchen&qid=1262711038&sr=8-23
<vila> I wasn;t that far, 160EU
<vila> And you should taste it soon hopefully :-/
<vila> :-) I meant
 * vila will have a hard time explaining the typo :-)
<jam> vila: The review's I've read said "stay away from crema-enhancing" models. The give you crema at the expense of flavor
<Pilky> vila: in all fairness to Apple, the EU prices are with VAT and the US are without sales tax
<jam> Anyway, I had originally planned to shoot for closer to $200, but I saw this one on a good deal and couldn't resist
<vila> jam: Enjoy ! Is all I have to say :)
<jam> Pilky: except when ordering online, you don't always pay sales tax
<Pilky> that said, an iMac is $1200 in the US, but ~$1325 in the UK/EU without tax
<jam> though I think you are supposed to report it to your state gov, and pay it there...
<vila> jam: You have to use the local Apple Store and the taxes apply there
<jam> Pilky: that is just the cost of the euro/pound key :)
<vila> Pilky: : Enjoy ! Is all I have to say :) I love my Apple hardware even when I run Ubuntu on it :)
<Pilky> oh well, even if I bought it at the US price, I'm still too poor to afford a Core i7 27" iMac at the moment :p
<Pilky> jam: also the cost of having a vertical enter key rather than the annoying horizontal ones on US keyboards ;)
<vila> Pilky: don'tmention that ! I bought a US keyboard without realizing that :-(
<Pilky> I once tried typing on my friend's US MacBook and kept hitting the
<Pilky> \ key
<Pilky> because I always hit the top of the return key
<vila> really ?
<vila> :-/
<Pilky> Of course I'm currently using an MS keyboard so half the keys type different things
<Pilky> UK Windows keyboards are weird in some places
<jam> Pilky: seems better to hit the lower part, since it is closer to home row...
<Pilky> like " is shift-2 and @ is shift-'
<jam> Pilky: really old commodore keyboards had that
<Pilky> which to me makes no logical sense, but oh well
<Pilky> jam: well that's how modern UK windows keyboards work. Macs flip it around. Never thought to check any Linux distros
<Pilky> oh well, even if the keys are labelled wrong, I still love my keyboard :p
<Pilky> jfroy: ping
<jfroy> Pilky: morning
<Pilky> jfroy: got some more mockups for you: http://dropbox.mcubedsw.com/bazaarxdesigndoc/bazaarxdesigndoc.html
<Pilky> still tweaking but most of the screens are there
<jam> Pilky: of course I have a US layout, but run Dvorak
<jam> so none of my keys type what they should :)
<jam> well, except the number keys
<Pilky> lol
<Pilky> well I couldn't even re-arrange my keys if I wanted as I've got an ergonomic keyboard so they can pretty much only fit in once place
<jam> vila: does OSX have futimens ?
 * fullermd shudders.
<vila> futimes ! damn I was wondering what you were talking about :)
<fullermd> Just LOOKING at an "ergonomic" keyboard makes my hands hurt.
<vila> jam: yes
<jam> vila: http://www.kernel.org/doc/man-pages/online/pages/man2/utimensat.2.html fu-time-ns
<jam> so we'd need to track down the function for Win32, but we could probably expose futimens in the _read_dir extension
<tedg1> Is there a way to regenerate indexes?  I thought there was, but I can't find it now.
<vila> jam: then no
<jam> vila: well fu-time-s would be sufficient for our need
<jam> if it also exists elsewhere
<jam> 1s resolution is enough for the bug
<vila> I was about to ask, yes
<Pilky> fullermd: http://www.infoprix.ca/images/pieces/921_1-Microsoft-Natural-Ergonomic-4000-Fr..jpg :p
 * fullermd twitches.
<Pilky> heh
 * fullermd cuddles up with his 18 year old Type M.
<Pilky> jam: this could help with OS X http://developer.apple.com/mac/library/documentation/Darwin/Reference/ManPages/index.html#group_Section_1_man_FA
<A4Tech> hi all
<A4Tech> i have a some trouble... http://paste.ubuntu.com/351882/
<stakh> hello, I'm trying to use bzr, but have difficulties doing push or pull between my branches. I always get a bzr: ERROR: invalid header line: ''
<stakh> error message
<stakh> Any ideas of what could be going wrong?
<james_w> stakh: could you try again passing -Derror on the command line?
<stakh> $ bzr push -Derror ~/WebDav/myDisk/webpage/PIM/
<stakh> bzr: ERROR: bzrlib.errors.BzrError: invalid header line: ''
<stakh> Traceback (most recent call last):
<stakh>   File "/usr/lib/python2.6/site-packages/bzrlib/commands.py", line 842, in exception_to_return_code
<stakh>     return the_callable(*args, **kwargs)
<stakh>   File "/usr/lib/python2.6/site-packages/bzrlib/commands.py", line 1037, in run_bzr
<stakh>     ret = run(*run_argv)
<stakh>   File "/usr/lib/python2.6/site-packages/bzrlib/commands.py", line 654, in run_argv_aliases
<stakh>     return self.run(**all_cmd_args)
<stakh>   File "/usr/lib/python2.6/site-packages/bzrlib/builtins.py", line 1156, in run
<stakh>     use_existing_dir=use_existing_dir)
<stakh>   File "/usr/lib/python2.6/site-packages/bzrlib/push.py", line 128, in _show_push_branch
<stakh>     remember, create_prefix)
<stakh>   File "/usr/lib/python2.6/site-packages/bzrlib/bzrdir.py", line 1293, in push_branch
<stakh>     tree_to.update()
<stakh>   File "/usr/lib/python2.6/site-packages/bzrlib/workingtree.py", line 2216, in update
<stakh>     return self._update_tree(old_tip, change_reporter)
<stakh>   File "/usr/lib/python2.6/site-packages/bzrlib/mutabletree.py", line 53, in tree_write_locked
<stakh>     return unbound(self, *args, **kwargs)
<stakh>   File "/usr/lib/python2.6/site-packages/bzrlib/workingtree.py", line 2239, in _update_tree
<A4Tech> ...
<stakh>     last_rev = self.get_parent_ids()[0]
<stakh>   File "/usr/lib/python2.6/site-packages/bzrlib/decorators.py", line 138, in read_locked
<stakh>     result = unbound(self, *args, **kwargs)
<stakh>   File "/usr/lib/python2.6/site-packages/bzrlib/workingtree_4.py", line 413, in get_parent_ids
<stakh>     return self.current_dirstate().get_parent_ids()
<stakh>   File "/usr/lib/python2.6/site-packages/bzrlib/dirstate.py", line 1903, in get_parent_ids
<stakh>     self._read_header_if_needed()
<stakh>   File "/usr/lib/python2.6/site-packages/bzrlib/dirstate.py", line 2228, in _read_header_if_needed
<stakh>     self._read_header()
<stakh>   File "/usr/lib/python2.6/site-packages/bzrlib/dirstate.py", line 2210, in _read_header
<stakh>     self._read_prelude()
<nailuj24> ahem ^^
<stakh>   File "/usr/lib/python2.6/site-packages/bzrlib/dirstate.py", line 2242, in _read_prelude
<stakh>     'invalid header line: %r' % (header,))
 * beuno facepalm
<stakh> BzrError: invalid header line: ''
<stakh> sorry for the spamming...
<A4Tech> stakh: USE PASTBIN ==> http://paste.ubuntu.com
 * nailuj24 points stakh to www.paste.ubuntu.com
<stakh> that's better : http://paste.ubuntu.com/351895/
<nailuj24> thanks
<Flimm> How can I get bzr gdiff to ignore whitespace?
<stakh> actually, I realized that it's also impossible to add files in one of the branches. Something must be corrupted with it
<stakh> I solved the issue by deleting the defective branch and recreating it. Seems to be working now, just hope it does not happen too often
<happyaron> hi, how can I make my local bzr repository show files in a specific revision?
<beuno> happyaron, you can branch at a specific revision
<beuno> or, if it's just one file:  bzr cat FILENAME -r REVNO
<beuno> or if you want to revert the whole tree, bzr revert -r REVNO
<happyaron> beuno: oh, just revert, but how can I turn back then?
<beuno> happyaron, don't commit, and then just "bzr revert"
<happyaron> ok, thanks
<beuno> but I'd branch off if you're going to experiment  ;)
<A4Tech> https://bugs.launchpad.net/bzr/+bug/503465 need help
<ubottu> Ubuntu bug 503465 in bzr "bzr crash when tying login in launchpad" [Undecided,New]
<happyaron> beuno: oh, I will make another copy first
<beuno> happyaron, why not just branch off then?
<beuno> it's effectively the same thing
<happyaron> beuno: I am new with bzr, and always mess up
<happyaron> and I don't want to check out everything for a second time ...
<happyaron> beuno: I think it works, thanks
<lifeless> jam: are we fully  redundant now ?
<lifeless> jam: AFAIK we still had ambiguous records in the pack
<jam> lifeless: text files don't store the parent graph
<jam> and neither do revisions, but we could infer that
<jam> from the Revision data
<jam> infering the text graph requires going through the inventories and regenerating it, etc.
<jam> so we are *sort of * redundant :)
<jam> not trivially so
<lifeless> jam: right, and not in the presence of bugs generating the original data.
<jam> lifeless: well, you could set the data to empty, and then run reconcile, right ? :)
<jam> oh...
<jam> and we don't store the file-id for the text content
<jam> only in the index
<jam> so we would have to guess
<lifeless> well, use the sha1 from the inventory
<lifeless> and hope its not the DoD's birthday.
<lifeless> jam: can you finish helping ted? I'm really not well.
<jam> lifeless: sure
<jam> feel better
<A4Tech> Why my commits by bzr on launchpad.net displayed as Registry Administrators <https://launchpad.net/~registry>
<A4Tech> mb offtopic? but on #launchpad unaware
<marsilainen> can I commit binary files (eg. a png image file) to bazaar in just the same way as text files?
<nailuj24> marsilainen: yes
<marsilainen> ok, thanks
<nailuj24> np
<thumper> hi people
<thumper> what answer do we give to people who have branched a packs repo into a local 2a
<thumper> and try to push / commit back?
<thumper> (happening on #launchpad right now)
<jam> A4Tech: can you point to an actual commit that shows up that way?
<jam> thumper: push upstream to upgrade
<jam> and/or
<jam> start over
<jam> I'm not sure if 'rebase' provides enough support to allow you to regenerate the commits easily.
<A4Tech> jam trouble fixed
<spiv> Good morning.
<Peng> Good morning. :D
<A4Tech> morning?! :)
<A4Tech> Although of course I know we should not forget that - when I got up, then the morning :)
<saedelaere> hi
<saedelaere> i'am using the bzr explorer and this tool is great. but there is one question.
<Peng> Just one? I guess that's pretty good. :D
<saedelaere> when i want to push a new commit a new dialog opens and at the top i can choose a location. there the last location that i was using is stored. but there is this down arrow, can it be used to choose different locations? where would i have to define them?
<wahben> Hi all!
<wahben> I am new to version control systems. What is the best approach to prevent some files from being uploaded; example: I created a project on launchpad where I uploaded a web-application code. Some parts of the code contain data that is specific to my development environment (database passwords, smtp auth passwords, etc). How do people usually deal with this kind of situation? Does bzr provide some kind of functionality to handle this kind of situation?
<nailuj24> wahben: bzr ignore --help
<nailuj24> :)
<bob2> put them in config files
<bob2> and don't add the config files
<saedelaere> right, never add that kind of data to the source code
<wahben> and if I create a branch using "bzr branch ./trunk ./dev" then I push the trunk using "bzr push (..launchpad)", will the "dev" branch also appear on launchpad or only the trunk?
<bob2> only the one you push
<wahben> I see.. earlier I branched out my "dev" to create a "trunk", then made changes to the settings file to remove sensitive data, did a "commit" and then pushed to launchpad. Revision 1 & 2 appeared on launchpad, revision 1 containing all my sensitive data... that kinda sucked...
<bob2> yes
<bob2> if you're only at rev 2, you might want to start over
<saedelaere> i'am normaly using sourceforge for my projects. now i added one also to launchpad. i'Am completely new to this interface and just don't find where i can upload files. What do i have to do?
<wahben> i did start over
<bob2> that's not starting over
<bob2> or did you do something else?
<wahben> I mean I removed the .bzr folder, removed the branch from launchpad and re-pushed the proper way
<bob2> saedelaere: try #launchpad if no one pipes up here
<wahben> but now I am being more careful with what I do... anyways, i'll look into ignore.
<bob2> ah, so you're sorted?  launchpad doesn't host your passwords anymore?
<wahben> bob2, of course, I sorted that in the 30 seconds after I realized what I had done
<bob2> ah
<bob2> sorry, I thought you were asking how to fix that
 * saedelaere zzz
<wahben> thanks for your help, i'll look into  --ignore
<jml> is there any known way to work with a moin wiki using bzr?
<ronny> jml: you mean a vzr backend for moinmoin?
<ronny> *bzr
<jml> ronny, not necessarily
<ronny> jml: then what do you mean?
<ronny> ima a part-time moinmoin contributor (i.e. conference based patching)
<jml> ronny, I mean, being able to have local copies of moin wiki pages, to be able to edit them, commit, revert, merge updates from the wiki and then push them to the wiki when I am ready to publish
<ronny> ah, so you mean a foreign repo format
<jml> ronny, yeah, I think that's closer to what I mean.
<jml> ronny, I mean, if moin had a bzr backend (which it probably ought to), that would give me what I want for free -- provided I could convince wiki maintainers to switch
<ronny> for now a bzr backend is unlikely
<ronny> at least a sane one
<jml> ronny, fair enough.
<jml> ronny, what about a remote repo format?
<ronny> versioned file metadata is required
<ronny> possible
<ronny> but you better target the 2.0
<jml> 'the 2.0'?
<ronny> moin 2.0 has a completely different storage system
<jml> ronny, ahh, I see.
<ronny> lifeless: btw, is there any reasonable way to add versioned per-file metadata? afair a2 doesnt have it
<jml> ronny, I would have guessed that the remote repo format would operate via the webservice anyway
<ronny> jml: the moinmoin < 2.0 has a kind of messy storage engine
<ronny> 2.0 fixes that
<ronny> in a really good way
<ronny> hmm
#bzr 2010-01-06
<lifeless> ronny: put it in .bzrmeta/yourapp - make that a file that records what you need for each fileid
<lifeless> ronny: we don't have a scalable lookaside engine for arbitrary metadata
<lifeless> ronny: or put the metadata in the files - what metadata is needed for moin ?
<ronny> its arbitrary key value storage per revision of an item
<ronny> a revlog based backend is on my todo, they already have a normal hg one (metadata in the file tree), a anyvc one based on that is also on my todo
<lifeless> ronny: what keys and values?
<ronny> keys are strings, values are strings/lists of strings
<lifeless> so you could do metadata in the file tree easily with bzr too
<lifeless> what query patterns are used on the metadata
<ronny> moinmoin will index the metadata
<ronny> lifeless: file level metadata i can keep track of would be rather nice, practically versioned xattrs
<lifeless> so - a full scan - how often ?
<lifeless> does it do partial scans? when? do they read the current file content at the same time?
<ronny> it will keep a separate index, it doesnt have to read file data for metadata indexing
<lifeless> thats a disk index ?
<ronny> yes
<lifeless> heh
<lifeless> sounds like there is duplication there, then.
<ronny> well, the cache is there to make querying fast, its discardable
<ronny> so the storage doesnt have to deal with metadata indexing/querying, just storage/retrival
<ronny> lifeless: so its not really duplication, its just speed-up for disk space
<pickscrape> If I upgrade a shared repository from pack-0.92 to rich-root-pack, do I need to do anything with the branches in that repository?
<bob2> can you go all the way to the 2a format?
<pickscrape> Not in this case
<pickscrape> We are actually moving to 2a, but need to keep an older format mirror around to allow for out debian-bound sysadmins who are seemingly opposed to upgrading anything :)
<pickscrape> But in order to be able to mirror from 2a, we need rich root
<pickscrape> Hmm, a test conversion seems to suggest that I don't need to do anything with the branches...
<pickscrape> In fact, bzr complains if I try to. Well, that makes the instructions easier. :)
<sven_oostenbrink> Does bzr recognize symlinks?
<sven_oostenbrink> what if I use symlinks pointing to directories inside and / or outside bzr WTs?
<pickscrape> It will still version control the symlink AIUI.
<sven_oostenbrink> AIUI?
<pickscrape> As I Understand It
<sven_oostenbrink> pickscrape: And what if I have a symlink to a directory within the WT? Will that directory be VCSed twice?
<pickscrape> The symlink will be version controlled as a symlink, and nothing else. So effectively its content will be a string
<sven_oostenbrink> pickscrape: that should be perfect.. thanks!
<sven_oostenbrink> pickscrape: bzr st . also shows it ending with an @, so it recognizes it..
<pickscrape> sven_oostenbrink: yes, that makes it nicely clear :)
<sven_oostenbrink> bzr: ERROR: An inconsistent delta was supplied involving 'lib.je/php-ext/resources/ext-2.0.2', 'ext2.0.2-20100106002643-5jhck8c23hf464tt-50'
<sven_oostenbrink> reason: The file id was deleted but its children were not deleted.
<sven_oostenbrink> Possible bzr bug? bzr: ERROR: An inconsistent delta was supplied involving 'lib.je/php-ext/resources/ext-2.0.2', 'ext2.0.2-20100106002643-5jhck8c23hf464tt-50' reason: The file id was deleted but its children were not deleted.
<shodan45> I'm trying to "easy_install bzr" on a centos5/rhel5 box, but get compile errors. Is this a known problem?
<pickscrape> sven_oostenbrink: That doesn't look good :)
<sven_oostenbrink> pickscrape: nah, found it already, my bad :)
<sven_oostenbrink> fixed
<pickscrape> sven_oostenbrink: was a directory replaced by a symlink under bzr's nose there?
<sven_oostenbrink> pickscrape: not really... added tree, removed (with rm) a sub dir, then bzr remove --keep tree
<sven_oostenbrink> pickscrape: ow, better even, the sub dir was replaced with that symlink yeah... man, Im messing up here!
<neoTheCat> how can i restore an accidently deleted file if i am using the centralized repository?
<neoTheCat> in svn, i was able to do an "svn update", and it would pull any missing files from the directory?
<neoTheCat> thanks...
<gutworth> bzr revert
<bob2> bzr revert filename
<neoTheCat> thanks.
<mac9416> How can I clear a branch of everything without deleting it?
<gutworth> clear of changes you mean?
<mac9416> Yep.
<gutworth> bzr revert
<mac9416> I'm new to bzr BTW, so don't beat me up.
<mac9416> OK, thanks. :-)
<mac9416> Hmmm, that didn't remove all the commits.
<_Andrew> Hi guys, I'm checkout out a copy of our bzr repo and it's so slow. They have 400 commits and over 1.6 gig in the repo. Is there anyway to make the checkout process faster?
<_Andrew> We have**
<gutworth> mac9416: bzr uncommit then, but be careful
<gutworth> _Andrew: what protocol?
<_Andrew> from file.. it is checking out on the same machine
<mac9416> gutworth, how do I uncommit a _lot_ of revisions?
<gutworth> do you have a shared repo?
<gutworth> mac9416: why do you want to do that?
<mac9416> gutworth, the short story is that I pushed 88 revisions to an empty branch that I should have branched, merged the code into and pushed.
<mac9416> So now I have 88 revisions I want to get rid of so I can do it right.
<mac9416> gutworth, the project I work on has very loose bzr rules. Small development team.
<gutworth> try pulling from your own branch and giving -r
<mac9416> -r?
<_Andrew> shared between different users? Yes
<gutworth> mac9416: specify a revision
<gutworth> _Andrew: no, like bzr init-repo
<mac9416> OK, I'll try.
<_Andrew> I'm not sure
<gutworth> if you branch within a shared repo, revisions don't have to be copied
<mwhudson> mac9416: you can do bzr pull --overwrite -r -88 .
<_Andrew> I'm using the bzr checkout command ?
<mac9416> mwhudson, that got it. Thanks.
<spiv> _Andrew: checkouts can use shared repositories too.
<mwhudson> mac9416: np
<spiv> _Andrew: although perhaps you simply want "bzr checkout --lightweight"?
<_Andrew> maybe, i'm not sure on what they all mean
<spiv> _Andrew: basically, if it's on the same machine, you probably don't want to actually make second copy of the 1.6 gig of history.
<_Andrew> ah yes
<spiv> _Andrew: a lightweight checkout will simply point to an existing branch and repository (the repo is the bit that holds all that history), rather than copy it.
<_Andrew> ah...
<_Andrew> So it doesn't copy the .bzr data just the files
<spiv> _Andrew: the other option mentioned is to make a shared repository with "bzr init-repo"... all branches (and heavyweight checkouts) created inside that repository will use the shared repository rather than keeping a standalone copy.
<spiv> _Andrew: well, there will still be a .bzr directory, just less stuff in it :)
<_Andrew> I think the first option is what I need
<spiv> Yeah, sounds like it, if you want to use checkouts anyway.
<spiv> If you want to keep multiple branches you may want a shared repository as well at some point, but worry about that when it happens :)
<_Andrew> We have multiple branches too
<_Andrew> for example we have different tags etc
<spiv> Well, there's the 'bzr tag' command so you don't need branches for that.
<spiv> A common way to work is to have a shared repository made with "bzr init-repo --no-trees", so that the branches in it don't have working trees automatically.
<spiv> So you have a directory that has all your branches, and all those branches share a single repository so disk isn't wasted and making new branches is really fast, etc.
<spiv> And then you might have a single lightweight checkout somewhere else, and you use 'bzr switch' to switch it to different branches depending on which one you're working on.
 * spiv -> lunch
<poolie> hello all
<mac9416> bzr: ERROR: RemoteRepository(bzr+ssh://bazaar.launchpad.net/~keryx-admins/keryx/devel/.bzr/)
<mac9416> is not compatible with
<mac9416> CHKInventoryRepository('file:///home/mac9416/aaaaaa/.bzr/repository/')
<mac9416> different rich-root support
<mac9416> Pardon the paste. Any ideas?
<gutworth> mac9416: you need to upgrade the remote repo apparently
<poolie> mac9416: or, perhaps easier, rename it and push a new one
<mac9416> Hmm, how do I upgrade the remote one?
<mac9416> Because I'm kinda attached to the name.
<mkanat_> mac9416: Maybe you could just rename the existing one and then push a new one with the same name.
<gutworth> bzr push --overwrite
<gutworth> (I believe)
<mac9416> Overwrite didn't work. Same error.
<mac9416> mkanat_, I'm sorry, I don't quite understand...
<mac9416> Perhaps bzr upgrade <branch> ?
<RAOF> bzr upgrade $BRANCH will work, yeah.
<RAOF> It'll possibly take a while, though; it (still!) needs to download & re-upload everything :(
<mac9416> lol, I was about to ask you if it was normal to take a while. :-)
<mac9416> It's a fairly small branch.
<poolie> jml: just what is bzr-tools-grep
<mwhudson> poolie: it's an emacs thingy
<mwhudson> it basically does the bzr ls | xargs grep thing into a grep-mode buffer
<jml> poolie, what mwhudson said. the exact shell command it uses is in the email
<poolie> mm
<poolie> i thought it was a bzr alias or plugin
<dOxxx> good evening
<lifeless> jml: I disagree on cleanups
<lifeless> jml: I hope I've made a convincing case in mail; please let me know if otherwise.
<vila> hi all
<vila> lifeless: I'm not sure I understand where you stand about cleanups, in one mail you said: "we should be able to reinstate that behaviour - it was removed by oversight, not intention.", as in cleanups before tearDown and in an other you said: "If you put cleanups after teardown...I argue that this is safer"
<vila> lifeless: ISTM you prefer the later but can you confirm ?
<lifeless> vila: the behaviour I refer to is not running teardown if setup raises an exception
<lifeless> that was an oversight
<lifeless> the order of teardowns vs cleanups is deliberate
<vila> ok. So in the end, that means banning tearDown for bzrlib (I think there are still a couple of classes that use it, in a safe way)
<lifeless> vila: well we can make teardown always run again
<lifeless> thats what I was saying
<vila> ok on that (and that's important), I mixed the two.
<lifeless> we could even do it in bzrlib
<lifeless> addCleanup(self.maybeTearDown)
<lifeless> def maybeTearDown(self): if not self._teardon_run: self.tearDown()
<lifeless> def tearDown(self):
<lifeless>     self._teardown_run = True
<lifeless> [/sketch]
<bialix> hello all
<jszakmeister> Hi bialix
<bialix> hi jszakmeister
<jszakmeister> Bummer.  The shelve-editor hasn't made it into bzr.dev yet.
<jszakmeister> s/shelve-editor/shelve-editor branch/
<jszakmeister> Geez... updating bzr.dev pulled involved 9.5MB of transfer. :-(
<jszakmeister> I take that back... shelve-editor did make it in!
<saedelaere> is there a changelog for the latest version of the bzr-explorer?
<jszakmeister> The most up-to-date one is here: http://bazaar.launchpad.net/%7Ebzr-explorer-dev/bzr-explorer/trunk/annotate/head%3A/NEWS
<jszakmeister> Or here (for 0.10.0): https://launchpad.net/bzr-explorer/trunk/0.10.0
<saedelaere> ah yes thank you very much
<jszakmeister> You're welcome.
<_Andrew> is there anything similar to propset in bzr so that I can insert the revision number into my files?
 * saedelaere waves
<ahasenack> when I do a "bzr info" and get back "format: unnamed", what does it mean?
<ahasenack> what format is it?
<ahasenack> if I do it at the shared repository level, I get 2a
<ahasenack> but if I cd into a checkout (bound branch) and repeat it, I get "unnamed"
<jelmer> ahasenack: a named format is a combination of a repository format, branch format and working tree format
<jelmer> in your case the branch format/repository format combination used is not available as a named "bzr init --format=" option
<jelmer> ahasenack: if you run "bzr upgrade --2a" in the branch it should make a trivial change to the branch and "bzr info" should display 2a as the format name
<jelmer> ahasenack: "bzr info -v" should show you the names of the branch, repository and working tree formats
<ahasenack> jelmer: is it possible for the root of the shared repository to have one format and the checkouts inside it have a different one?
<jelmer> this situation be introduced when you upgrade a repository but not the branches inside of it
<ahasenack> it's quite possible this is what happened
<ahasenack> I have no idea now what was upgraded and what wasn't
<jelmer> ahasenack: I'd recommend just running "bzr upgrade" in the repository root and the branches
<jelmer> that should be a no-op if the control dir is already up to date
<ahasenack> bzr: ERROR: The branch format Meta directory format 1 is already at the most recent format.
<ahasenack> I guess it is
<ahasenack> or at least the root of the shared repository is
<ahasenack> so I can run "bzr upgrade" at the root of the shared repo
<ahasenack> and I can also run it inside each repo from this shared repo?
<ahasenack> it's a bit confusing
<ahasenack> the shared bits can be upgraded separately from the rest?
<jelmer> yes
<jelmer> I agree it's a bit confusing
<ahasenack> if I run the upgrade at the root level of the shared repository, I still have to run it inside each repository?
<jelmer> ahasenack: inside of each branch, yes.
<ahasenack> ok
<ahasenack> weird:   shared repository: bzr+ssh://bazaar.launchpad.net/~landscape/landscape/trunk/
<ahasenack> trunk itself is a shared repo?
<ahasenack> ops, wrong channel
<vila> ahasenack: a branch uses a repository, it is not a repo itself. As such, a repo can be shared between branches. Standalone branches use their own (private, not shared) repo
<maxb> ahasenack: bzr info -v will tell you the repository branch and tree formats separately - handy when they rollup is 'unnamed'
<ahasenack> maxb: even remotely?
<maxb> You might need to prefix the URL with nosmart+ for that
<ahasenack> aha, magic tricks
<ahasenack> because just bzr info -v lp:~landscape/landscape/trunk doesn't tell me that
<jam> morning all
<__monty__> Good afternoon.
 * bialix waves at jam
 * vila waves
<vila> jam: inventory paths use /\'/ as \\
<vila> grrr
<vila> jam: inventory paths use /\'/ as \\
<jam> hey vila
<vila> argh
<jam> waiting for one more "growl" :)
<vila> jam: inventory paths use '/' as separator on *all* platforms right ?
 * vila curses Apple keyboard and its \ / delete and return keys all in the same place :)
<jam> vila: id2path will always return '/' in the path
<jam> we try (too) hard to make sure we always use '/' internally
<jam> if you look at the os functions
<jam> sorry
<jam> osutils
<jam> on windows, lots of them end with ".replace('\', '/')"
<jam> vila: so yes, internally '/' is our path separator
<vila> ok so changes_from() most likely obeys that rule
<jam> I would assume so
<vila> I just discovered/realize that I can't filter changes_from output with is_ignored() (in bzr-upload context) because smart_add is the only place where *parents* are pruned when they are ignored :-/
<jam> the main issue with supporting '\' in filenames, is just that right now, we do all we can to squash '\' to '/'
<jam> vila: so you mean if I "ignore foo/" then "foo/bar" isn't getting added?
<vila> jam: yes
<jam> if I ignore "foo/" but add "foo/bar/" then "foo/bar/baz" (i believe) will show up as unknown
<jam> testing
<vila> 'ignore foo' is enough
<jam> vila: confirmed
<jam> I was using '/' to denote that they were dirs
<vila> ok
<jam> vila: so ignoring 'foo/' just means we won't recurse by default
<jam> but if 'foo/bar' is versioned, then we will search everything underneath
<vila> hmm, the context is .bzrignore-upload
<jam> vila: I expected as such
<jam> I just wanted to mention *why* it seems to work for add
<vila> So there is no way to "force" as we do with bzr add
<jam> and that is because we don't recurse into ignored dirs
<vila> sure, makes sense
<jam> vila: you may want "foo/**/*"
<jam> which is "ignore everything under foo"
<jam> note that it *doesn't* ignore foo
<vila> yup, but that doesn't ignore foo itself :-/
<vila> hehe
<jam> vila: so I don't know what you want to do with bzr-ignore-upload
<jam> I just wanted to note that there *is* a syntax for "ignore everything under foo"
<vila> don't upload items described in .bzrignore-upload
<vila> the main difference is that we are talking about inventory paths here, not filesystem paths, so I have to check if a filename is ignored or any of its parents (this isn't needed in bzrlib except in smart_add)
<vila> that also means I can't use osutils.dirname :-/
<jam> vila: dirname works fine
<jam> as would "osutils.split"
<jam> splitting doesn't involve adding a '/'
<vila> err, on windows dirname() will recognize '/' ?
<jam> vila: windows already recognizes '/' as a path chare
<jam> char
<jam> it just *also* recognizes '\'
<vila> s/char/pathsep/ ?
<jam> vila: well in python pathsep == : or ;
<jam> directory separator
<jam> Windows recognizes both '\' and '/' as directory separators
<vila> grr, not pathsep, the other one :)
<vila> oooh, good news
<vila> Do we accept '\' in .bzrignore as meaning '/' ?
<vila> Or do we just don't handle them ?
<jam> vila: I think we switch them to '/', checking
<vila> globbing.normalize_pattern seems to handle the formet
<jam> vila: yep
<vila> pfew
<vila> I'm glad I asked :)
<jam> _slashes = re.compile('[\\/]')
<jam> so, '\/\/\/' will be treated as 1 '/'
<vila> beuno-lunch: lunch is for... well, may be not :) .bzrignore-upload was far more complex than I thought, see the new merge proposal
<barry> hi everyone.  recently, i've been getting tons of 'No handlers could be found for logger "bzr"' messages for things like 'bzr push'.  google seemed unhelpful.  anybody know what's going on, or how to fix or debug the issue?  i'm sure it's a python logging thing, but i'm not clear on how bzr sets that up.  ftr: Bazaar (bzr) 2.0.3 on karmic
<james_w> it's usually permissions, but I think you ruled that out?
<barry> james_w: i did verify that ~/.bzr.log is owned by me
<barry> james_w: as are everything in ~/.bazaar
<barry> james_w: that is the one issue google spewed up for me, but i can't find anything e.g. owned by root
<james_w> are the permission bits sensible on ~/.bzr.log?
<barry> james_w: yep. 664
<james_w> if you strace it is it trying to open another log file?
<barry> james_w: hmm, good idea. let me try
<james_w> strace -e open /usr/bin/bzr info 2>&1 | grep log
<james_w> and this is usual bzr operations with a plain unpatched bzr?
<james_w> does it still happen with --no-plugins?
<jam> barry: also, if you could do a run where you see it, and stop with ^\ to get into the debugger
<james_w> c = self
<james_w> while c:
<jam> then we can poke around with what is going on
<james_w> that's rather odd code in a method isn't it?
<jam> james_w: that does look a little odd
<barry> james_w: i only see it trying to open ~/.bzr.log; this is stock /usr/bin/bzr; still happens with --no-plugins
<james_w> barry: and it succeeds in opening ~/.bzr.log?
<barry> james_w: it does
<barry> james_w: and writing to it
<barry> jam: let me see if i can catch it
<jam> barry: if i understand the problem correctly, it should happen any time you try to connect to an sftp location, or ssh location using paramiko
<jam> barry: this is using bzr 2.0.3 ?
<barry> jam it is and this is a bzr+ssh url
<jam> do you have BZR_SSH set?
<jam> (env var)
<barry> jam: no
<james_w> del bzr_logger.handlers[:]
<james_w> doesn't that delete a copy of the list, and so is basically a no-op?
<jam> k, well if it is 2.0.3, I'm pretty sure poolie's "stop using the logging" module isn't present
<idnar> james_w: no, it empties the list
<jam> james_w: no, that is python syntax for clear the list
<james_w> ok
<idnar> del "operates" on names, not references
<jam> bad syntax IMO, but that is the syntax
<idnar> there's effectively a whole bunch of special forms of del
<jam> same as 'del d[key]'
<barry> lists should really have a .clear() method like dicts, but that's a digression :)
<idnar> "del foo" deletes a local name, "del foo.bar" invokes __delattr__, "del foo[bar]" invokes __delitem__
<jam> idnar: so is it the parser that turns it into the special construct?
<barry> jam: so it sounds like this is a known issue in 2.0.3.  if so, i will happily ignore it :)
<jam> barry: I don't think it is
<jam> It sounds like something strange happening
<jam> you could also just try
<jam> from bzrlib import logging
<jam> sorry
<barry> jam: ok!  i'd file a bug, but it seems like i don't have enough information yet :/
<jam> from bzrlib import trace; trace.enable_default_logging()
<idnar> jam: I'm not sure of the exact mechanics, but it ultimately compiles to different bytecode ops
<jam> and see if that has a problem
<jam> idnar: *glee*
<jam> barry: and what were you using before you ran into this problem? 2.0.2 ?
<idnar> there's DELETE_GLOBAL and DELETE_FAST for names, DELETE_SUSCR for del foo[bar], and DELETE_ATTR for del foo.bar
<jam> (I'm trying to understand how it "just started" )
<barry> jam: python -c "from bzrlib import trace; trace.enable_default_logging()" produces no such message
<jam> barry: Now I would expect: "from bzrlib import trace; trace.mutter('foo')" to generate that
<jam> and
<jam> "from bzrlib import trace; trace.enable_default_logging(); trace.mutter('bar')" not to
<barry> jam: well, that's the thing, i'm not entirely sure when it started.  "recently" is the best i can say.  the only thing that comes to mind is that i started using etckeeper, but i would have thought --no-plugins would eliminate that (and i'm not doing pushes in /etc)
<jam> sorry 'trace.note()' but I can't reproduce that here
<jam> barry: and once again I'm proven wrong
<jam> it takes "trace.warning" to provoke the handlers issue
<barry> jam:
<barry> % python -c "from bzrlib import trace; trace.enable_default_logging(); trace.warning('bar')"
<barry> bar
<barry> no logger warning
<jam> barry: and without the "enable_default_logging"
<barry> jam: bingo!
<jam> barry: right
<barry> warning and no "bar"
<jam> so you have to try to log something that looks severe enough, but not have a handler enabled
<barry> jam: why, or maybe who, is not installing the handler?
<jam> barry: we install the handler as part of main, IIRC
<jam> checking
<james_w> the difference between note and warning is that warning will go through the added stderr handler
<jam> barry: it looks like it is in the "bzr" main script
<jam> before calling main
<jam> barry: care to put an "import pdb; pdb.set_trace()" in 'bzr' and step through it to see when the warning hits?
<GaryvdM> jszakmeister: ping
<beuno> vila, ah, that's quite a change
<barry> jam: yep, that does seem like the next step.
<jam> barry: looking at the 'bzr' code, it looks like we would have to be emitting a warning during import
<vila> beuno: yeah, not that simple :)
<jam> as plugins aren't even loaded yet
<jam> barry: the common case is when "enable_default_logging()" itself fails
<jam> specifically:     except IOError, e:
<jam>         warning("failed to open trace file: %s" % (e))
<jam> which because it cannot open the trace file has not yet set up logging, and ends up getting suppressed
<jam> we should probably just change that to "sys.stderr.write()"
<james_w> jelmer: isn't that log bug caused by ghosts?
<jam> barry: however, you claimed that ~/.bzr.log isn't a problem
<james_w> jelmer: oh no, ignore me, sorry
<barry> jam: right.  does not seem to be!
<jam> barry: you know what, check ~/.bzr.log.old
<jam> I wonder if your log is full, and it is failing to get rid of the old one
<barry> jam: i have no ~/.bzr.log.old
<jam> barry: anyway, stepping through with pdb is the best way to isolate it
<jam> barry: what size is ~/.bzr.log ?
<barry> jam: 782715
<jam> hmm.. we roll at 4MB, so no issue there
<jam> back to pdb :)
<barry> :)  trying...
<barry> jam: so far, i've narrowed it down to push.py:83 in bzr.dev
<barry> dir_to = bzrdir.BzrDir.open_from_transport(to_transport)
<jam> barry: so this seems to be happening a long time after bzrlib.trace.enable_default_logging() has been called
<barry> yep
<jam> barry: does that fit what you are seeing
<jam> very strange
<barry> remote.py:124
<jam> barry: you could try putting something into 'trace.warning' but I have the feeling something is going directly to the logging module
<barry> jam: happens before we hit the first call to warning()
<jam> barry: I think error would also trigger it
<jam> but 'note' and 'mutter' seem to be defaulted to silence
<jam> maybe there is an 'info' call?
<barry> happens before the first call to error too
<barry> and before the first call to info()
<barry> in fact, before the first call to anything in trace.py
<jam> barry: btw, does *python* guarantee that "open().name" works?
<jam> I'm trying to define an api, and I want to know whether I have to pass a path as well as a file object, or if I can assume the file object has a .name attribute
<barry> jam: well, the stdlib says "may not be present on all file-like objects" but i belive for actual file objects, yes it does guarantee that
<jam> barry: sure, StringIO may not have it, but that doesn't have an fs path either :)
<barry> right :)
<barry> jam: narrowed down to client.py:87
<barry> jam: where method='BzrDir.open_2.1'
<jam> barry: sure, I'm guessing that send_request is causing an actual connection to be spawned
<jam> oh, and if you are sitting there
<jam> we can try something else
<jam> namely, check the transport
<jam> and its connection
<jam> and see whether it is using paramiko itself
<jam> etc
<barry> would that be self?
<barry> or rather, i'm not sure where transport and connection are
<barry> protocol.py:1303
<barry> or maybe 1302
<barry> jam: well, here's an interesting thing.  in ssh.py:367 it calls subprocess.Popen() where argv[0] == 'ssh'.  it is in this call that the No handlers warning gets emitted
<barry> jam: is it possible this is happening on the server?
<jam> barry: hmm... that at least looks like the server is generating an error
<jam> barry: it is definitely possible
 * barry checks the server
<jam> and the error would get propogated over ssh's stderr output
<jam> without bzr doing anything
<jam> so if on the *server* you have a problem with ~/.bzr.log
<jam> this would be much less suprising
<barry> jam: bing
<barry> er, bingo :)
<jam> old mac's dog?
<barry> jam: :)  ~/.bzr.log on the server was owned by root.  fixing that made the problem go away.  this explains everything, since this is a new-ish server and it explains why all the clients suddenly saw the same thing
<jam> barry: of course it is unfortunate that this was so hard to diagnose
<jam> #1 we need to fix _open_bzr_log
<barry> jam: thanks!  so problem solved, but i wonder if the debugging output couldn't have helped indicate that the message was coming from the server?
<jam> to just write to stderr, since we know logging isn't set up yet
<barry> jam: are there bugs here i can file or would you like the honors? :)
<jam> barry: You can file a bug if you want, I was just going to fix it
<jam> It *is* nice to close bugs :)
<barry> jam: you kw :)
<vila> kw == kilowatt ?
<barry> vila: first word: karma
<vila> LOL
<vila> well, I think the intent here is more to *document*, karma is unfair for jam anyway :-D
<barry> :)  but yes +1, especially because my previous google search was unhelpful.  filing bug now
<jam> barry: I was thinking keyword myself :)
<vila> mostly because lp doesn't take the number of clones jam is using when calculating karma :D
<jam> vila: well for a long time lp didn't count code changes as karma
<jam> so mine was actually quite low
<jam> too many people triaging bugs
<jam> so the amount I did, did not amount to much
<jam> if you wanted real karma *blueprints* were where it was at
<barry> jam: don't i know it!  when i was doing the lp mlist stuff i blueprinted out the wazoo.  lots of yummy karma
<vila> which is a bit silly since we don't use blueprints :D
<jam> vila: \o/ I somehow managed to have the highest karma of people I can find right now
<jam> I don't know how that happened
<jam> ah, lots of commits
<jam> https://edge.launchpad.net/~jameinel/+karma
<jam> 30k karma from "bazaar branches"
<barry> jam: bug 503886
<ubottu> Launchpad bug 503886 in bzr "Server errors are hard to debug" [Undecided,New] https://launchpad.net/bugs/503886
<jam> I'm certainly a branch whore
<barry> and with that, i give you my thanks and take leave for lunch!
<jam> barry: eat hearty my friend
<barry> :)  bye all
<jam> vila: it would appear that merge-proposals are the new karma hotness :)
<vila> good move :)
<jam> well, if you look at https://edge.launchpad.net/~jameinel/+karma, I have about 10x more karma from branches
<jam> though I guess "new branch registered" also appears on the list
<jam> and I don't think I'm *shabby* on the bug tracker
<vila> jam: you suck at translations though...
<vila> ;-P
<jam> yeah
<jam> which is true enough anyway :)
<EdWyse_Mobile> I have to use bzr on Fedora 6 connecting to a newer repository.  The latest fc6 rpm is 0.91.1 but when I attempt to init to the server, I get "Unknown branch format...". If I try to bdist_rpm version 2.0.3 it fails because of: "bzrlib/_annotator_pyx.c:30:27: error: python-compat.h: No such file or directory".
<maxb> EdWyse_Mobile: bzr 0.91.1 !? That's unspeakably ancient!
<EdWyse_Mobile> Yeah, so is FC6, but I'm stuck with it on this machine. They took a feature I need out of the kernel.
<maxb> I'm afraid I know nothing about bdist_rpm, so I would suggest installing bzr 2.0.3 from source to /usr/local
<EdWyse_Mobile> Just to be clear, I do mean "python setup.py bdist_rpm"
<ronny> EdWyse_Mobile: you lakc the python development packages
<EdWyse_Mobile> Oh! That makes sense.
<EdWyse_Mobile> Well, made sense but that wasn't it.
<jam> EdWyse_Mobile: where are you getting the code from?
<jam> I don't see how it would have _annotator_pyx.c but not python-compat.h
<jam> EdWyse_Mobile: another option would be to just run from source, which is what I do on an *FC3* machine :)
<EdWyse_Mobile> That's what I'm doing for now.
<lifeless> moin
<jam> hi lifeless
<jam> EdWyse_Mobile: looks like I get the same failure, investigating
<jam> it seems that bdist_rpm is building in build/temp... but isn't including bzrlib itself
<jam> so it probably thinks we should be including "bzrlib/python-compat.h"
<jam> EdWyse_Mobile: hmm... bdist_rpm seems to start by hardlinking everything into a new directory
<jam> but doesn't seem to include python-compat.h
<EdWyse_Mobile> Hmm, sounds like a simple bug.
<jam> I don't quite understand how it figures out what files to copy
<lifeless> jam: check that sdist includes python-compat.h
<jam>  lifeless: the tarball it creates does *not* have python-compat.h, or any of the pyrex generated .c files
<lifeless> I'm fiarly sure that they select in common
<lifeless> excuse me, more coughing.
<jam> lifeless: looks like that is true
<jam> looking here for possible answers: http://www.python.org/doc/2.3.5/dist/source-dist.html
<jam> It does mention: all C source files mentioned in the ext_modules or   libraries options
<jam> however: http://paste.ubuntu.com/352492/ doesn't seem to catch it
<jam> this seems to work: http://paste.ubuntu.com/352494/
<jam> EdWyse_Mobile: ^^
<jam> That will also include the pyrex generated files in the tarball
<jam> which is something we would want anyway
<jam> oh, and you probably need more for stuff like bzrlib/help-topics, etc
<jam> so we probably need a *.txt in there as well
<jam> lifeless, jelmer: Any idea why subvertpy debs are in the bzr 2.0/2.0.3 download location?
<jam> https://edge.launchpad.net/bzr/2.0/2.0.3/
<EdWyse_Mobile> cool, thanks
<jam> and bzr_2.0.3-1~bazaar1~hardy_powerpc.changes seems a bit strange to have
<jam> it at least looks like someone uploaded to +download instead of to a ppa
<lifeless> jam: no idea
<lifeless> seems odd
<jam> Any way to tell who uploaded them?
<lifeless> who uploaded them ?
<lifeless> jinx
<lifeless> thats a question for #launchpad(-dev)? I think
<dutchie> is there a way to make a shelved change dump out the diff saved?
<snorkelbuckle> Hi!
<GaryvdM> dutchie: maybe bzr unshelve --dry-run
<GaryvdM> Hi snorkelbuckle!
<dutchie> it just prints out a little summary message, even with -v
<snorkelbuckle> New user here, anybody here who can spend 5 minutes to help me with setting up centralized shared repos?  Its installed on linux and I'm having trouble accessing via windows tortoise bazaar.
<snorkelbuckle> I did the following, bzr init-repo --no-trees /bzrepos, then from tortoise did and 'Init' no trees to following bzr+ssh://hostname/bzrepos/newproj
<snorkelbuckle> now if i check out newproj, I get erro Not a branch
<snorkelbuckle> what am I not understanding about setting up new repos?
<GaryvdM> snorkelbuckle: are you maybe a user of another vcs?
<GaryvdM> snorkelbuckle: If I understand you correctly, you have a branch stored on a linux box, and you want a copy of it on your win box?
<snorkelbuckle> GaryvdM: yes, I've used svn, yes I suppose a branc on linux box, but it is empty I only just initizliued it.  So I assume once it is init, then I can check it out to my win box and add files to it
<GaryvdM> snorkelbuckle: what url did you use?
<snorkelbuckle> GaryvdM: bzr+ssh://myinternalhost.com/bzrepos/myproject
<lifeless> snorkelbuckle: in one line you say bzr+ssh://hostname/bzrepos/newproj in another bzr+ssh://myinternalhost.com/bzrepos/myproject
<lifeless> snorkelbuckle: the urls will need to be the same :)
<snorkelbuckle> lifeless: thanks, first line was generlized, second line is accurate.  :)
<snorkelbuckle> okay, now I tink I understand what is wrong...but I don't understand then how I should use bazaar...I think the terminology is different from what I'm used to.
<snorkelbuckle> What I did was did bzr init-repo for /repos
<snorkelbuckle> and then under /repos, I did also init-repo
<snorkelbuckle> for a different dir
<snorkelbuckle> so then this is a sub-repos under a repos?  This is allowed?  Thus I don't yet have a branch which I must do with bzr 'init'  as opposed to 'init-repos'?
<GaryvdM> snorkelbuckle: http://doc.bazaar.canonical.com/latest/en/user-guide/core_concepts.html will help
<snorkelbuckle> GaryvdM: thanks
<GaryvdM> btw: I've just changed from Qwerty to dvorak so my typing is painfull slow :-(
<snorkelbuckle> GaryvdM: what is the reason you changed?
<GaryvdM> hopefully I will become faster in the long run :-)
<snorkelbuckle> GaryvdM: thanks for your time in helping me.  I must have missed those reference pages, explains a lot.  I've got things working now.
<GaryvdM> Good!
<snorkelbuckle> GaryvdM: I guess my main problem was that I had not actually any branches to checkout from the repos, thus the error.  However, I find this a minor problem with tortoise bazaar (maybe there is a way to do it), but there doesn't seem to be a way to create a branch on an empty remote repository.
<lifeless> snorkelbuckle: yes repos can be nested but its not what you want
<lifeless> snorkelbuckle: you want to init under the first repo
<jam> GaryvdM: good luck, I've been there
<jam> It took me about 1 month before I was at reasonable speed vs qwerty
<jam> I'll note that I don't think I'm faster today than I was w/ qwerty
<jam> though the bottleneck is not really my fingers
<jam> I *do* feel that there is less motion in my fingers
<jam> and I believe poolie has had good results wrt strain
<GaryvdM> Hi jam
<jam> GaryvdM: I'll also mention that I was decent at switching for a long time, before I started working exclusively on my laptopt
<jam> now I can switch somewhat, but ViM is still a real pain in the wrong keyboard
<GaryvdM> In the typing tutor, I can do 10 wpm, but when I'm much slower when I've got other things on my mind.
<idnar> yeah, I observed about the same; once I was up to speed, I wasn't any faster on dvorak, but I wasn't any slower either, and the strain on my wrists was much less
<GaryvdM> I find 'L' to be a bit of a strain.
<marsilainen> I would seriously consider switching to dvorak if there were a decent selection of keyboards to buy..
<lifeless> marsilainen: any keyboard with homogenous keys
<jam> marsilainen: well, it helps you become a better touch typist
<jam> lifeless: except the F & J keys have bits on them to guide your fingers
<jam> but I did rearrange a keyboard
<jam> and just swapped those two keys appropriately so that I still had the dots, and just had 4 keys in the wrong place
<jam> well, except for the fact that I made mistakes and never bothered to fix them (V & W, IIRC)
<poolie> hello jam, gary
<poolie> i never switched the keycaps
<poolie> i just learned to do things from the dots on the home row
<poolie> that possibly improved my results independently of switching to dvorak
<poolie> iow relearning any layout this way may have helped
<poolie> i'd like to do a small hack some time that measures errors (backspaces) as a feedback technique
<jam> hey poolie
<jam> abentley: are you around?
<GaryvdM> Hi poolie
<poolie> hi, happy new year
<poolie> jam, if it's not too late, we could talk
<poolie> otherwise i'll set an alarm for earlier tomorrow :)
<jam> poolie: I'm heading out the door now
<jam> I suppose you could call my cell if you wanted
<poolie> nm, if i call you at 2200utc tomorrow would that work?
<jam> sure
<jam> I've been trying to investigate bug #494269, and our tree root handling just seems ... broken
<jam> everywhere
<ubottu> Launchpad bug 494269 in bzr "tree transform cannot change root id" [Medium,Confirmed] https://launchpad.net/bugs/494269
<jam> calling "wt.set_root_id(new)"
<poolie> hm :/
<jam> causes "wt.id2path(new)" to fail
<jam> well, wt.id2path(wt.path2id('')) breaks
<poolie> with problems in dirstate, or tt,or maybe both?
<jam> both
<jam> wt.id2path(wt.path2id('')) is a dirstate bug
<jam> 'bzr revert' fails
<jam> but seems to be a TreeTransform bug
<jam> etc,
<jam> update/pull use different code paths to achieve 90% the same thing
<jam> and update will call set_root_id() if it is None
<jam> pull doesn't
<jam> etc.
<jam> anyway, I'm off for now
<igc> morning
#bzr 2010-01-07
<poolie> hello igc
<chalkbag_> Hey folks, is there a way to rewrite author info on locally committed revisions? I got the email wrong there...
<chalkbag_> I tried bzr rebase but it doesn't seem to allow that, it looks like it only reapplies the local changes to the tip of the parent tree
<spiv> chalkbag_: perhaps the bzr-fastimport plugin can help.  You could fast-export the revisions, edit the export and then import it again.
<spiv> chalkbag_: I think the fast-import-filter command may even support rewriting authors directly.
<chalkbag_> Ah, interesting - I was actually wondering if there was a way to create smth like a change set of diffs ala git. bzr send seems to be creating a monolitic diff of everything that changed and doesn't preserve individual commits - unless I missed something there
<spiv> chalkbag_: bzr send will preserve the individual commits
<spiv> chalkbag_: but as a blob that you can't really edit.
<chalkbag_> really? How do I "replay" them? I tried "bzr patch" but is seems to have applied them all at once - will I see individual revisions after I commit?
<chalkbag_> So I assume it'll preserve author info as well, right? If not, I can just reapply the patch after changing my email in the config...
<james_w> chalkbag_: bzr merge or bzr pull
<bob2> there's the bzr-rewrite plugin, too
<chalkbag_> bob2 - yeah, I tried that one, it's not like git's rebase, i.e., it won't really let me change anything in the commits, it just reapplies them at the tip as far as I can tell
<chalkbag_> james_w - I'm not sure I understand how merge/pull would help me?
<spiv> chalkbag_: you can "bzr merge"/"bzr pull" from the file that "bzr send" outputs.
<james_w> chalkbag_: that's how you apply what bzr send creates, but you are right that it won't help solve your problem
<chalkbag_> Hmm, and it won't preserve the author info? That might indeed be the easiest way to do that then
<chalkbag_> Let me give it a quick try :p
<chalkbag_> yeah, merge wrote the merge commit with my new author info but whatever it merged contains the original email. I guess I'll have to play with fast-import then...
<bob2> do you care that much?
<chalkbag_> Not too much but it looks like people on launchpad seem to be using real email addresses and all I've got is smth like foo@mylaptop :(
<chalkbag_> I should've thought about that before doing the commits but I expected this would be something quite easy to change later on - I guess I got spoiled by git :o
<chalkbag_> besides, it sounds like a challenge of sorts :p
<chalkbag_> ok, it looks like fast-export/import should do that, fast-import-filter has an example for rewriting user ids in the --help
<chalkbag_> thanks folks!
<poolie> spiv, re bug 503878, i thought we now did better than TooManyConcurrentRequests when the server dropped the connection
<ubottu> Launchpad bug 503878 in bzr ""Too many concurrent requests" error during reconcile" [Undecided,New] https://launchpad.net/bugs/503878
<spiv> poolie: often, although I see that bzrlib/reconcile.py has a "try: ... finally: collection._unlock_names()" which is what's been tripped here.
<spiv> poolie: i.e. an unconditional attempt to perform a cleanup over the network even if the network connection has gone away.
<poolie> right
<spiv> I'll put together a simple fix for that for trunk.
<poolie> oh ok
<poolie> i'll reopen it
<Akilla> Hey, all, quick question. We're using BZR to make local changes to a public SVN repo. So, we need to maintain the ability to both update from the public SVN server and make our own loacl cchanges with BZR. Some aspects of tihs work fine, but when we try to do individual file commands (i.e. remove) it tries to access the SVN server. Is there any way to disable the SVN functionality of the bzr binaries so that it will just perform B
<poolie> Akilla: so you have one working tree that's both a svn checkout (controlled by svn) and a bzr checkout (controlled by bzr?)
<mwhudson> jelmer: hello, did you see http://launchpadlibrarian.net/37520409/squeezebox-7.5-log.txt ?
<Akilla> yeah... turns out tortoisebzr had a subversion integration installation option.
<Akilla> just reinstalled adn rebooted and now i'm getting different errors that look like it's trying to actually access the bzr repo.
<Akilla> yeah, apparently this is just a user error as a result of a default option in the tortoisebzr installer.
<Akilla> ignore me. :) thanks!
<GungaDin> hi
<GungaDin> I have an old repo (bzr version 1.xx), and now I'm using bzr 2.0.2 and I keep getting bzr: "ERROR: No repository present: "file:///home...." when I'm trying to do something...
<GungaDin> any ideas what the problem might be?
 * igc lunch
<Peng> GungaDin: Just for fun, try "bzr --no-plugins info" or whatever.
<Peng> GungaDin: Aside from that, upgrading bzr won't break anything. So, most likely there's no repo present...
<GungaDin> there always has been...
<Peng> Well, there have been a couple changes, but if they break anything, it should be pretty obscure.
<GungaDin> I can see the .bzr dir
<Peng> GungaDin: OK, but what about .bzr/repository?
<Peng> GungaDin: And what does "bzr info" say?
<GungaDin> same error
<Peng> GungaDin: Oh oh. Did you try to "bzr upgrade"? Does .bzr/repository.backup or backup.bzr exist?
<GungaDin> no
<Peng> GungaDin: Did you do "bzr reconfigure" or anything else?
<GungaDin> bzr upgrade gives the same error
<GungaDin> no
<Peng> Erk. Not what I meant!
<Peng> I was asking if you had run "bzr upgrade", not saying you should. Oh well, doesn't matter.
<Peng> Whoops.
<GungaDin> should I try bzr reconfigure?
<GungaDin> any ideas?
<maxb> GungaDin: Perhaps you could pastebin the output of 'find path/to/that/.bzr'
<GungaDin> http://pastebin.com/d30ca28ad
<maxb> So, that's a branch with no repository internally, so it must be expecting to find a shared repository in a parent directory's .bzr
<maxb> If there is no such repository, then directories have been moved around on disk in a way which has broken things
<GungaDin> but I haven't moved anything...
<GungaDin> shit...
<GungaDin> something must have happened here...
<GungaDin> I'm getting this with pretty much all my branches :S
<Peng> GungaDin: Maybe you accidentally had a shared repo very high up, e.g. /.bzr, /home/.bzr or /home/you/.bzr.
<GungaDin> *sigh*
<GungaDin> could be...
<jdub> what up bzroes!
<jdub> i have an http smart server issue
<jdub> after 10 successful POSTs to .bzr/smart, i get a timeout...
<jdub> i have just upped my proxy timeout to 300s
<jdub> and trying it again, but it looks like it's going to fail
<jdub> (the smart server is loggerhead behind nginx with http auth)
<spiv> jdub: hmm, what smart request, do you know?
<spiv> jdub: (run the client with -Dhpss and peek in ~/.bzr.log)
<jdub> will do
<jdub> aha!
<jdub> was waiting for a timeout
<jdub> but the client had actually already returned (nothing in logs)
<jdub> bzr: ERROR: Could not acquire lock "(remote lock)":
<jdub> should i try break-lock first?
<spiv> jdub: ah, yeah, probably
<spiv> jdub: this is a 'bzr push'?
<jdub> yeah
<jdub> ok, i broke the lock
<jdub> trying again
<spiv> jdub: my random speculation would be that that insert_stream request might be very large, and would arrive as a single POST â it should be streamed gradually (maybe after a small initial pause), but depending on the various HTTP server bits it's easy to see how that might timeout or cause issues.
<jdub> rock, that worked
<spiv> Ah, good :)
<jdub> so the biggest POST of about 15 that time was 15078
<spiv> Oh, pfft :)
<jdub> is there an "i'm waiting patiently for this lock to go away" delay?
<spiv> 300 seconds, I think, I don't remember the precise circumstance.
<jdub> heh
<spiv> The server won't delay, though (unless your server has a very old bzr!)
<jdub> 2.0.3
<jdub> and was previously running 2.0.2
<spiv> I don't think the client will via HPSS either (unless maybe if it's fallen back to non-smart VFS methods for some reason)
<jdub> (before i restarted loggerhead)
<spiv> Ok, that's not even close to what I meant by "very old" :)
<spiv> So, not sure why there was a delay for you.
<jdub> 8)
<poolie> hi jdub
<jdub> yo poolie
<jdub> poolie: will you be in welly?
<poolie> hi
<poolie> no, i have clashing travel
<jdub> nooooooo
<poolie> so did you work out your issue with the delay?
<poolie> i'd probably try stracing the server subprocess
<poolie> and perhaps put that into a bug
<jdub> poolie: well, until i cranked up the proxy timeout, it didn't have enough time to tell me about the lock
<jdub> poolie: once the lock was broken, it worked fine
<jdub> that it took so long to report about the lock is a bit worrying though
<poolie> it is
<poolie> so it would be nice to know what it was doing for all that time
<jdub> can i just touch a file to create a stray lock?
<poolie> it needs to be a directory called 'held' containing a file called 'info'
<poolie> i think the file can be empty, at least for your purposes here
<spiv> jdub: python -c "from bzrlib.bzrdir import BzrDir; branch = BzrDir.open($URL).open_branch(); branch.lock_write(); branch.leave_lock_in_place()"
<spiv> jdub: you'll need to use break-lock to tidy up afterwards, of course.
<poolie> spiv, re bug 504102
<ubottu> Launchpad bug 504102 in bzr "test_format_initialize_find_open has some isolation problems" [High,In progress] https://launchpad.net/bugs/504102
<poolie> can you tell me off hand when the network_name should be set in a remotebzrdirformat?
<spiv> poolie: as soon as it is known, IIRC.
<spiv> poolie: it varies by circumstance a little, I think, which makes it confusing.
<poolie> and so either initializing a bzrdir, or doing find_format on an existing one ought to set it?
<spiv> I think so, yes.
<igc> hi poolie
<igc> poolie: can we make Sphinx a dependency for 2.1 packagers?
<igc> poolie: I'd like to drop the old pure-rest docs because ...
<igc> supporting them breaks some things in Sphinx (e.g. PDF generation of the User Reference)
<jam1> hey igc
<igc> hi jam!
<igc> Happy New Year
<jam> So did I read correctly that you may show up in Strasbourg?
<igc> jam: maybe - I need to chat to poolie about it
<jam> igc: well, so far I still need to find out if *I'm* going
<jam> my wife has a potential trip around the same time, which she should find out about tomorrow
<poolie> hello igc
<poolie> igc, the non-sphinx things do make things a bit more confusing too
<poolie> there are some index.txts that don't go into the sphinx stuff
<poolie> you can do what you think best
<igc> poolie: thanks
<poolie> i'll also mention, though it's not super urgent, the bug asking for rest->texinfo translation
<igc> I'll email the list anyway asking for objections
<poolie> apparently jam looked and there is a tool but it doesn't completely work
<poolie> shall we talk now?
<igc> as in on phone?
<poolie> if you like
<poolie> or here
<spiv> Yeah, I've been tripped up by two slightly different doc generation systems, so it would be nice if it were just Sphinx.
<igc> either is good by me
<spiv> I think I wanted to use some sort of link to another doc that Sphinx supports, but it turned out that the pure-rest stuff didn't.
<jam> igc, poolie: yeah, getting to texinfo is tricky, and texinfo likes to have "type" info that we wouldn't have
<jam> (code vs variable vs etc that all generate fixed-width output)
<jam> spiv: yeah, I'm a bit surprised plain rest doesn't let you link via a '.txt' and then have that translated to a '.html' link when necessary
<Guest56789> ALGUIEN ABLA ESPAÃOL
<poolie> igc, https://edge.launchpad.net/software-center has mvo with the most karma
<poolie> spiv, don't forget as pilot you can nag other people for a second review
<poolie> or even when not a pilot :)
<spiv> poolie: sure, but it's not really worth it for a one-liner :)
<poolie> yeah i know
<poolie> just meant in general
<spiv> Fair enough.
<poolie> but also, i really like the way you're handling them
<poolie> that was nicely put
<vila> hi all !
<vila> hmm, I haven't realized that MPs now present the post-review commits in the comments, nice. The sugar on top would be a button to present the associated diff :)
<jml> locked 145 hours, 58 minutes ago
<jml> niiiice.
<jml> vila, you can click on the revno to get the diff
<vila> ooh, but they are ! revnos are clickable and show just that !
<vila> jml: hehe
<jml> 145 hours ago is not a helpful number
<vila> I just love those moments where you think: "IWBN if they put it here... try... it works !"
<jml> (the rule is, if your number makes people want to do arithmetic, it's the wrong number)
<spiv> jml: sure it is, it means "less than one week"... doesn't everyone know that a week is 168 hours (and that a day is 86400 seconds...)?
<vila> spiv: wrong, may French still think a week is 35 hours :-D
<vila> s/may/many/
 * vila always made typos in jokes :-/
<jml> vila, :D
 * igc dinner
<spiv> vila: hah
<vila> spiv: in case things happen without further warnings: enjoy your new life as a dad ! It's certainly one of the most exciting experience in life :-)
<spiv> vila: thanks!
<MFen> have a conceptual question
<MFen> i have a branch of lp:txgenshi, call it O for original.  i also have three branches working on different features for it
<MFen> call them A, B, and C. they build on each other in that order (B contains changes from A, C contains changes from B)
<MFen> i'm currently working on *B*.  however i need changes from C.  how do i do that without just making B and C the same?
<MFen> i want it to be possible to review B without looking at the changes in C
<MFen> does stacking help me out in any way with this?
<Peng> No.
<Peng> Wellll, if you're using Launchpad's review system, when filing the merge proposal for B, you can set C as a prerequisite; then the diff will be against C, so you'll only see B's changes.
<Peng> Well, I don't know what exactly the diff will be against, but that's the end result.
<MFen> but that'll be circular. B is already a prerequisite for C
<spiv> MFen: do you need all of C in B?
<MFen> probably, yeah
<MFen> B is a bugfix. C is unit tests. they were opened as separate bugs.  i want to add unit tests for the bug fix, but the unit tests didn't exist before I made C
<spiv> So you really want to the ordering to be A, C, B, rather than A, B, C?
<Peng> You could add B's unit tests in C.
<MFen> um. maybe!  C hasn't been reviewed yet, though. what if i need to make changes to C after that?
<Peng> Then C would need B, but B would not need C.
<MFen> i don't understand what stacking does, if it doesn't allow me to segregate my changes
<spiv> MFen: stacking is a storage and network transfer optimisation, not a semantic difference.
<MFen> crap.
<spiv> MFen: so it allows you to push up just the changes unique to a branch, and say in that branch "you'll find the rest of the history over *there*".
<MFen> so basically C is B plus some changes.  therefore it doesn't make any sense to talk about making changes to B that aren't part of C
<MFen> right
<spiv> Hm, I'm having trouble following you.  One moment it seems that you say B is meant to contain all of C's changes (and history), then the next you say it's the other way around.
<MFen> it's both. i *want* to be able to make changes to either one without impacting the other
<spiv> I guess the question to ask is "what do you want to present to the reviewers?"?
<MFen> otherwise none of this makes any sense, workflow-wise
<MFen> it's not just a question of what i present to the reviewers
<MFen> that only matters if we all assume my changes are perfect
<MFen> if there are any changes needed post-review, then i need to make them in both places
<spiv> Well, if your changes are assumed to be perfect, you wouldn't need reviewers ;)
<MFen> which means "why did i make two branches in the first place"
<spiv> Well,
<spiv> if say the branches are ordered A,B,C, and you need to make post-review changes to B...
<spiv> Then the change you'd make in C, if it is important that C is kept current with those changes, is just a merge from B.
<lifeless> MFen: you ask 'without making B and C the same' - merge B to C regularly. Don't merge C to B ever.
<lifeless> MFen: then they won't be the same.
<spiv> Which might not impact things like the diff of C vs. B at all.
<MFen> lifeless: if i do that, won't the reviewer reviewing C be looking at the changes from B?
<lifeless> MFen: depends on how they review
<spiv> MFen: not if the reviewer is reviewing C with respect to B.
<lifeless> if they look at (B, C] then they get only stuff new to C
<lifeless> if they look at (trunk, C] then they get all of A,B,C
<MFen> well, let's assume they're using lp's diff view
<spiv> MFen: i.e. assume B as a pre-requisite that is being reviewed separately (Launchpad's review system has good support for this)
<lifeless> MFen: lp's diff view? do you mean loggerhead?
<MFen> hells if i know. i made a merge request, and i see a diff button.
<lifeless> MFen: more precisely, gimme a url to be clear about what you mean.
<MFen> https://bugs.launchpad.net/txgenshi/+bug/502821 green diff link
<MFen> that is C
<MFen> 520823 is B
<spiv> MFen: then LP will basically show the reviewer the output of "cd lp:.../B && bzr merge --preview lp:.../C"
<MFen> spiv: how does it know?
<lifeless> MFen: when you propose the merge, you tell it where B is
<spiv> MFen: there is a "prerequisite branch" field on the "merge proposal" form
<MFen> yeah, but i didn't fill it in
<lifeless> MFen: workaround time: cancel that merge proposal. Do it again.
<MFen> oh ok, and it is in fact showing my B changes, i think
<spiv> MFen: https://code.edge.launchpad.net/~corydodt/txgenshi/502823/+merge/16954 looks promising :)
<MFen> ok, cleaning up those merge requests helped, now the diffs show only (B, C]
<MFen> spiv: are you claiming the review or just telling me i did it right?
<spiv> MFen: just saying that appears you've navigated the lp merge proposal stuff successfully.
<MFen> yeah. i think i did that much right
<MFen> so moving on to the next step
<spiv> MFen: although the __provides__ hack looks a bit alarming tbh!
<MFen> yes.
<MFen> bzr merge B into C ... the diff for C will still ignore anything merged from B?
<spiv> MFen: it may well be right, of course, but I'll leave that to someone with some actually knowledge of the situation to review :)
<MFen> no, it sucks. my proposal for this bug eliminates the need for the hack
<spiv> MFen: yes, if you update C (including merging a newer B into C) the updated diff will still only show the changes new in C
<MFen> ah, because it actually does cd into B first like you said. great.
<spiv> MFen: (well, not cd literally, it uses the bzrlib API, but equivalent to that yeah)
<MFen> yeah, i get it conceptually
<spiv> Cool.
<Peng> Say you have branches a, b and c. You file a proposal to merge c into a, with b as a prerequisite. Is the diff just "cd b; bzr merge --preview ../c", or is it like "cd a; bzr merge b; bzr merge --preview ../c"?
<Peng> Err, "bzr merge ../b". But you get the point.
<spiv> Peng: yes ;)
<Peng> Jerk. :P Heh.
<spiv> Peng: not sure, abentley or someone else from the lp code team could answer I'm sure, or you could look at the source.  My guess is the former, though.
<Peng> I'm sure I could do an experiment, but I'm too sleepy to figure out how.
<Peng> Ah. A should have revisions 1-2. B should have 1-X, and C should have 1-Y, I think?
<MFen> Peng: what you just described is exactly what i've been doing, i think. so i can tell you it's the first one
<Peng> OK. You sure?
<MFen> i have a <- b <- c
<lifeless> Peng: check the code
<Peng> :(
<MFen> merge request for c into a, depends on b. the diff shows c diff b, not c diff a
<MFen> it assumes you will land b first, i guess
<Peng> Not c diff a+b?
<MFen> nope
<Peng> Huh.
<Peng> That would be more complicated and more likely to cause conflicts, but also more correct...
<MFen> if you're going to land c before b, then you really don't need b at all. landing c will cause b to land
<MFen> in my case i expect b to land first, so it makes more sense to me
<MFen> ok, one more question along these lines:
<MFen> if i use bzr bind, does that automatically merge changes into whatever location i gave it?
<MFen> (therefore, should i always bind A to B and B to C, forward along the dependency chain)?
<lifeless> no
<lifeless> bind makes a branch work like a checkout
<lifeless> e.g. its useful for a shared branch that multiple people commit to, nothing else.
<MFen> the glossary says bound branch and checkout are synonyms, so that isn't helping me :)
<lifeless> checkout is what svn does
<MFen> ok, so it does a push?
<lifeless> no
<MFen> what happens when i commit to a bound branch
<lifeless> it just changes the behaviour of subsequent commands in that directory
<lifeless> when you commit in a bound branch it does a 2-phase commit to both the master and the cwd
<MFen> is there any difference between that and a puh?
<MFen> push
<spiv> MFen: bind basically means "keep this branch in sync with the target branch", so when you make a commit both cwd and master are locked, then new revision written to both, then that transaction is committed.
<MFen> k
<spiv> MFen: whereas if you are unbound and push, the end result is typically the same (both branches at same rev), but obviously how you get there is a bit different, and if other people might write to your branch then the master can diverge between you doing "bzr commit" and you doing "bzr push".
<MFen> spiv: is it committed locally in both cases?
<spiv> I'm not sure what you mean.
<spiv> (I know what sort of things I'd mean by that phrase, but not what you do)
<MFen> bzr st will show nothing modified after
<Raim> if the commit fails on the bound branch, it fails locally, too
<spiv> MFen: right
<MFen> ok. so that is a different end result
<MFen> in commit+push, it is committed locally even if push fails. in bind+commit, it is not.
<spiv> MFen: (assuming the commit succeeds, as Raim points out, though commits may fail for reasons other than a bound branch with diverged master, e.g. pre-commit hook)
<spiv> So if you like the big difference is that when things have diverged you'll get a failure at the commit step rather than later.
<MFen> ok
<lifeless> MFen: there are two key differences between bound commits and  push:
<lifeless> firstly, parent ordering is preserved (because you do merges with the same parents as the master)
<lifeless> secondly, out of date branches cannot commit when bound.
<lifeless> MFen: spiv: sorry for echoing spiv late there, I didn't read to the bottom :)
<jelmer> mwhudson: no idea, I thought I had fixed all places where that appears
<henninge> HI, I know I had figured it out before but I can't remember how it worked.
<henninge> I want to use bzr-pipelines (again) to hack on Launchpad.
<henninge> I have my lp-branches repository and in there the devel branch (and other's).
<henninge> (forget the ')
<henninge> I know pipelines are "just" light-weight check-outs - but of what?
<henninge> I don't want a light-weight check-out of devel, because then I'd be committing all changes there.
<henninge> Actually, my situation is even different. I have a (heavy-weight) branch of devel that I have been hacking on but now I want to add a pipe to do extra work. I don't know how. I must be missing something obvious.
<james_w> bzr reconfigure-pipeline to start I believe
<jelmer> mwhudson: these issues usually take up quite a bit of time, perhaps we could have a look in NZ?
<henninge> james_w: appearently not if you already have a repository.
<henninge> james_w: from bzr help reconfigure-pipeline:
<henninge>   This is suitable if you have a standalone tree, but if you have a
<henninge>   shared repository with its own organization scheme already, it's probably
<henninge>   better to just create a lightweight checkout.
<henninge> james_w: I figured it out now:
<henninge> bzr branch devel mywork-pipe1
<henninge> bzr checkout --lightweight mywork-pipe1 mywork
<henninge> cd mywork
<henninge> bzr add-pipe mywork-pipe2
<henninge> This will create all pipes as siblings, so in my repository I now have directories "mywork", "mywork-pipe1" and "mywork-pipe2".
<henninge> The confusing thing is that that the pipe directories don't show any changes, no matter what I commit in mywork, I guess that's because the pipline commands only work on the branch, not the tree. (Or is it the other way round?)
<james_w> yeah, I think you "bzr update ../mywork-pipe1" you will see the changes appear
<henninge> james_w: yes, it does! cool, thanks
<marek_> hi i have a problem, i have two computers and one server, every one has repo , from 1 computer i can push and other can merge, but when i try it in other way - while i try to push i can see "no revisions to push" but i changed some files
<marek_> can you help me?
<Peng> marek_: Have you committed?
<marek_> locally
<marek_> yes
<marek_> bzr status -> clean
<Peng> marek_: Then I guess you've already pushed?
<Peng> marek_: Do "bzr log -r -1 -n 1 :push".
<Peng> Hmm, that looks a little Git-like. :P
<awilkins> You might have a checkout rather than a branch?
<awilkins> aka "bound branch"
<Peng> Ah, good point. marek_: What does "bzr info" on your local branh say it is?
<awilkins> Revisions committed locally automatically committed to remote branch... do `bzr info` in tree
<marek_> on server: bzr info:
<marek_> http://pastebin.com/m66579407
<marek_> on local i can also see something about
<marek_> related branches
<Peng> marek_: OK, but what's the first line of the client's info?
<marek_> standalano tree
<Peng> Ah.
<Peng> marek_: Then, most likely, you already pushed.
<marek_> but i cannot see it on server
<marek_> ecen after update
<marek_> on othe computer if i merge changes i dont see modified files :(
<Peng> marek_: Ohh? What does "bzr log -r -1" say on both branches?
<marek_> on local: revno 25 [merge] and commiter - local user
<marek_> on server:
<marek_> revno 23 and different user
<Peng> Huh.
<Peng> It's possible something has gone horribly awry, but most likely it's something basic like you're pushing to the wrong place...
<awilkins> do `bzr missing --mine <server branch>`
<marek_> gosh other pc was using bzr explorer
<marek_> and path was ....
<marek_> local !!! ^&%&^!%^&@!
<mok0> Is there a trick you need to do to update the directory tree in the "central" repo? I have a checkout on my laptop at home, I did a "commit" but I can't seem to extract the changes on my main workstation.
<mok0> ... bzr update doesn't do it, I should say.
<awilkins> mok0, If the revision you committed on your laptop hasn't been pushed to the main workstation (or a repository it can see) then you can't see those changes
<mok0> awilkins: it's a checkout
<mok0> awilkins: it gets pushed when I commit
<awilkins> They're both checkouts of the same repo?
<mok0> yes
<mok0> awilkins: I can check tonite if I did something wrong
<mok0> Just puzzled
<mok0> awilkins: the laptop dir is a checkout of my working dir on the workstation
<mok0> awilkins: just wondering if there's a bzr command I don't know about.
<awilkins> mok0, Did you do the commit while on the same network as the workstation?
<mok0> awilkins: I am using the bzr+ssh protocol. I am not sure I know what you mean by "same network"
<awilkins> Try "revert"
<mok0> awilkins: nothing happens
<awilkins> Can you see the revision you committed from the laptop in the local log?
<mok0> no
<mok0> Perhaps there's something in .bzr that could give a clue?
<awilkins> You have your laptop with you?
<mok0> awilkins: No :-) that's the problem. I did some work at home, committed it (AFAIR) and went to work
<mok0> w/o the laptop :-)
<awilkins> The tree on the laptop is either a standalone, or you committed with the --local flag
<mok0> awilkins: well, you must be right
<awilkins> Or it's bound to another branch
<awilkins> That isn't the one you're working on
<mok0> awilkins: apparently :-/
<awilkins> Still, merges are easy :-)
<mok0> awilkins: fortunately! Oh well I'll figure out what's going on when I get home
<awilkins> Before policy locked out thumbdrives I used to bind my checkouts to a folder on a thumb drive
<mok0> awilkins: what policy is that?
<awilkins> Our management policy
<mok0> Ah
<mok0> I guess thumbdrives are inherently unsafe
<rubbs> so are users, but they don't stop those from connecting ;)
<awilkins> That worked very nicely... since I take my laptop home I now just run a bzr:// server on it when I want to sync
<mok0> "oops I lost my thumbdrive, the entire IP of my company has gone missing"
<mok0> :)
<awilkins> The idiotic bit is that we're working hard to open-source as much of my work as possible
<rubbs> oops, I just left the company with all the newest ideas in my head.
<awilkins> And I don't have any confidential data
<rubbs> haha
<awilkins> (I work for a government agency)
<mok0> Well managers love to enforce stupid rules they think are important
<awilkins> Since we are the IT arm of this agency we get to guinea-pig all the stupid ideas for the parts that DO have confidential data
<mok0> Sysadms are generally opposed to openness. The create restrictions just because it's possible
<rubbs> I resent that!
<rubbs> hehe ;) I'm a part time admin
<awilkins> The fewer degrees of freedom your workstation has, the lower the skill required to adminster it
<mok0> rubbs: resent what, my statement or what I'm saying?
<mok0> rubbs: so am I
<mok0> awilkins: hehe
<rubbs> just that sysadmins are apposed to openness. I wouldn't quite say that
<awilkins> I think it's sensible to prevent normal users doing stuff
<rubbs> this is true
<mok0> rubbs: I didn't say _all_ sysadms
<rubbs> ah, then I'm sorry I over reacted
<awilkins> But it's a pain in the ass for developers.. we have a different class of support problems though
<rubbs> awilkins: I've been in your boat too, that's why I try to make it easy. finding the balance is hard.
<awilkins> Like the time last month when I trashed the stupid full-disk encryption boot block on both my machines... because standard users don't dual-boot Linux from external drives
<rubbs> luckily I have a pretty small support group, so I don't have to juggle too many needs.
<rubbs> awilkins: haha
<awilkins> The knee jerk response would be to prevent booting from external drives.. and would cripple my productivity
<awilkins> More interesting than "I forgot my password" though
<awilkins> They're now removing admin rights from our users that need them though, on general principles
<awilkins> So when you get a new machine on the refresh program, you lose admin rights until you kick up a fuss about it
<awilkins> Even if you are developer
<mok0> I've been admin for our local network (~20 workstations) for 10-15 years. I've had hacker visits 2-3 times. Always amateurs, and it's taken 5 minutes to get rid of them once I discovered them
<awilkins> Windows?
<mok0> That is w/o firewall
<mok0> awilkins: No! Linux
<mok0> Just using the standard tools like iptables etc. to block intruders
<awilkins> I just wish our infratructure was friendlier to Linux
<mok0> That's why I frown at sysadms who restrict their users in every possible way in fear of hackers
<awilkins> They got rid of a perfectly good IMAP server that you could access outside the office network
<awilkins> And replaced it with Exchange
<mok0> awilkins: isn't that the PURPOSE of an imap server :-)
<fullermd> Who needs IMAP?  Everybody just uses gmail, right?
<awilkins> Which you dare not expose on the internet, so it's closeted behind an XMLRPC firewall
<mok0> fullermd: I use gmail
<awilkins> So only Outlook and OWA
<awilkins> Can't use gmail
<mok0> I use gmail's IMAP :-)
<awilkins> Stupid patient-confidentiality rules, dammit
<rubbs> awilkins: know that well. I work with PHI too.
<mok0> awilkins: can't you encrypt them?
<fullermd> Pointless.  Google Knows All And Sees All anyway.
<awilkins> Used to be able to use thunderbird inside and out
<awilkins> Now I use Outlook because otherwise I'll have to use VPN, which is a PITA, or Outlook Web Access which sucketh mightily
<mok0> awilkins: :-(
<awilkins> mok0, We wouldn't have a large enough contingent of people who understand encryption
<mok0> awilkins: hmm. People can be educated
<awilkins> mok0, This is an organisation which advocates using an approved motorbike courier because it's apparently secure
<awilkins> And destroying _encrypted_ flash media after they served their pupose
<mok0> awilkins: what if someone rams him and steals the documents?
<awilkins> mok0, Indeed.. they also advocate that sending mails to people on our own email domain to be secure
 * mok0 is for unlimited openess on the internets
<awilkins> mok0, But as we know, damn sysadmins will just read it
<awilkins> mok0, my personal position is GPG for everything
<mok0> awilkins: ... and then people print out the confidential mails and bring them home :-)
<awilkins> And screw the couriers
<mok0> awilkins: I agree
<awilkins> And post
<mok0> awilkins: absolutely
<awilkins> Problem is they take their encryption advice from GCHQ which has the wrong set of requirements
<awilkins> Like key escrow
<mok0> awilkins: there's no remedy for incompetence in the upper cadres
<awilkins> "GPG for everything confidential" is a lot simpler than memorizing rules about whether it's OK to mail someone with a gmail account or which bike messengers are accredited
<mok0> awilkins: indeed. And security != control
<awilkins> I mean, key escrow for signing keys on medical records... no practitioner will go for that
<mok0> I actually don't know key escrow
<awilkins> They keep a copy of the private keys centrally
<mok0> Ah
<mok0> awilkins: that's for unsophisticated users
<awilkins> So, what doctor would be happy with "Hey, your records can be VERIFIED to be from you.. apart from if <agency X> wants to fake them"
<mok0> exactly
<awilkins> Or some hacker steals the escrow DB, which lets face it, would be a FAT target
<mok0> Most encryption schemes don't take into consideration that the "bad guy" is the government or some other agency
<mok0> That's where GPG differs
<awilkins> Or some schmuck in the data centre offered a few $10k for the key database
<mok0> awilkins: right
<mok0> Well, the climate guys from East Anglia are probably sorry that they didn't encrypt their mail correspondence
<awilkins> Whereas my medical record architecture is so private that the patient can potentially restrict access to his records to everyone, except himself.
<awilkins> :-)
<awilkins> Shame it'll never catch on
<awilkins> I should write it up just as a thought experiment and see if I can get a presentation of it under the wire
<mok0> awilkins: I'm in a university and I have to tell the students about GPG
<mok0> awilkins: good idea
<awilkins> I discovered PGP in my first year
<awilkins> (some time ago)
<mok0> My position used to be this: "I have no secrets, I don't care if ppl see my email correspondence"
<mok0> Now I'm not so sure. If someone evil got hold of it all, I'm sure they could dig up some dirt to throw at me
<awilkins> Then you have Eric Schmidt saying "Hey, if people have no secrets, they shouldn't care if we see their email"
<awilkins> And get worried
<mok0> and Eric Schmidt is...
<mok0> ?
<awilkins> Google person?
<mok0> ah
<awilkins> I may have wrong guy
<awilkins> Nope, right guy
<mok0> ... and those statements are meant as a comment to their searching gmail accounts?
<awilkins> http://gawker.com/5419271/google-ceo-secrets-are-for-filthy-people
 * mok0 looks
 * rubbs goes and checks it out as well.
<mok0> Oh... In principle I agree with Eric Schmidt on this very particular subject
<awilkins> I do plenty of things that are legal that I wouldn't want people knowing about
<mok0> Although I don't agree with the header... it's somewhat misleading anyway
<mok0> awilkins: yes
<awilkins>  "If you have something that you don't want anyone to know, maybe you shouldn't be doing it in the first place."
<mok0> Of course there are things that are secret. But if they're not, you can't complain that Google finds them
<mok0> awilkins: I'm sure that's taken out of context
<mok0> Idunno
<mok0> Google doesn't index email
<mok0> and they shouldnt
<awilkins> It seems more reasonable when you view the clip
<awilkins> They don't publicly index email
<awilkins> They must index it somewhere for you to be able to search it so quickly
<mok0> Ah, ok, but my Google Chromium browser wont show it :-D
<awilkins> Odd, I'm running Chrome and I see it fine
<mok0> I disabled falsh
<mok0> flash
<awilkins> Ah
<awilkins> And they process email so they can show context ads
<awilkins> (which you don't see over IMAP, natch)
<mok0> I use their imap service so I never see it
<awilkins> His point that the government can technically ask them to cough up their data is fair
<awilkins> His attitude doesn't seem to have the same tone as the story title
<mok0> That is why you should encrypt email that you don't want anyone to see
<awilkins> And funnily enough, the clip is from a company owned in large part by MS
<mok0> ... then if Eric Schmidt thinks you are filthy... I can live with that
<mok0> hehe
<awilkins> They should change the email icon to a postcard instead of an envelope
<mok0> hehe
<mok0> yes
<mok0> That's what email is, anyway
<awilkins> That envelope icon does more to raise peoples expectations of email privacy than anything else
<mok0> "Sending mail in an envelope are for filthy people"
<mok0> s/are/is
<awilkins> The security policy at work... actually suggests LABELLING the envelope you send with a courier as a secure document
<awilkins> Ahaahahahahahahhahaha
<awilkins> "STEAL ME"
<mok0> Now THAT'S funny!!
<awilkins> Not that security by obscurity is a good thing
<mok0> :-)
<awilkins> But damn, labelling things as being more valuable? Before handing them to a guy who earns Â£5 an hour to motorcycle through British weather?
 * mok0 thinks most investigations are done by traffic analysis anyway
<mok0> The (insert favourite TLA) just needs to locate terrorist/criminal/etc. networks
<mok0> they can do that by traffic analysis, and there's nothing you can do about it
<mok0> NOTHING
<J-m-D> We are using svn for versioning. Our useage is a bit "uncommon" - we mainly have binary files, and quite large ones. The central repository is very important for us so we have a central back up aswell as central access to all files. Could bzr bring something to the table that we miss out on in svn?
<J-m-D> btw - we are all on windows
<mok0> J-m-D: the most obvious advantage is the ability to have off-line branches
<mok0> J-m-D: "distributed development"
<J-m-D> something that is not very important for us atm.
<mok0> J-m-D: AFAIK tagging and branching is heavy in subversion. Do you use that a lot?
<rubbs> J-m-D: bzr also allows for easier merges. merging in svn is pretty tough... although I haven't done it in svn in a while admittedly
<awilkins> Bazaar is less adept at coping with large binary files... but there are some advantages, esp. if they are compressible
<awilkins> e.g. - I've got a Bazaar working tree + repo with full history that's 2.5GB... the SVN checkout on it's own is 4.0GB
<J-m-D> Branching and tagging is almost non-existant with us for now.
<mok0> J-m-D: if you only need a "data store" then I honestly don't think it matters what VCS you use
<mok0> J-m-D: if you are planning to revise your workflow, then bzr offers lots of options
<mok0> J-m-D: consider svn a subset of bzr
<J-m-D> svn seems to handle binary files quite good - revisions are made incrementally which is nice. It makes updates and comitts less heavy. How does bzr handle revisions of binary files?
<mok0> J-m-D: ugh. Don't know to be honest. I just know it works
<mok0> J-m-D: personally, I use it quite a lot for PDF files
<J-m-D> What could be interesting is if bzr is more flexible than svn in handling revisions of individual files. If we want to have an older version of something, it is allmost allways just an individual file - we never make a new branch of a project.
<mok0> J-m-D: Don't you use the status of the entire directory tree?
<J-m-D> Nope, very seldom since we mostly work on large graphics files and 3D graphical assets.
<mok0> J-m-D: then I'd suggest to use a separate repo for each component
<mok0> J-m-D: that you can check out in whatever context you need
<J-m-D> ohh, I'm afraid that would be totally impractical - there are quite a few components for every project.
<mok0> bzr can give you a svn-like workflow, but it can also give you other options
<rubbs> J-m-D: I think that you could still get individual files, but it would probably be from a branch.
<mok0> J-m-D: I see
<J-m-D> Renaming is allso quite indflexible in svn since it seems to be made by a delet-and-re-comitt-method or something. Takes quite a while to get it done on a large repository.
<mok0> J-m-D: the best I can suggest is to try out bzr on your project and see how it performs in practice
<J-m-D> mok0: I guess I'll have to do that. Thank you for all the imput - much appreciated.
<litwol> hello
<mok0> J-m-D: good luck! Come back later, perhaps ther are more qualified ppl
<litwol> What command allows me to list available project branches ?
<litwol> and how can i switch between them ?
<J-m-D> mok0 - sure will. And your suggestions were good enough for me at least. Thanx again.
<mok0> litwol: branches are stored in each their directory
<rubbs> J-m-D: renames are supported in bzr as fully versioned.
<litwol> oh ...
<beuno> vila, so we're releasing 1.0?  :)
<mok0> litwol: there are ways of working with stacked branches but I've not tried that
<J-m-D> rubbs: oki. interesting. thnx
<vila> beuno: hehe, not yet, but that doesn't forbid using the milestone :)
<mok0> litwol: in it's basic form, no bzr branch would know about other branches... only the parent
<litwol> i c
<litwol> ty
<J-m-D> thanks for now. See you later guys.
<mok0> litwol: however, if you use Launchpad, it's different
<beuno> vila, we should figure out what we want for 1.0, and target it!
<rubbs> J-m-D: np. see you later
<vila> beuno: I agree, I think the list we did at UDS is a good target, I'm fighting for free time to work on it though :-/
<vila> beuno: may be we should just go for time-based release...
<beuno> vila, we'll pull through, even if it's me hacking up code you you cleaning it up  ;)
<beuno> well, it is stable enough
<beuno> I'll go through the list of bugs and features
<jam> morning vila and beuno
<vila> morning jam
<beuno> hiya jam
 * vila EODing, already late for school meeting :-.
<chx> i just committed with the wrong commit message can i change it?
<chx> ah bzr uncommit
<chx> great.
<maxb> Has anyone performed any sort of trade-off analysis of methods of converting from svn to bzr? There seem to be quite a few of them.
<jelmer> maxb: What sort of tradeoffs do you mean?
<maxb> Any discussion that would assist me in deciding which method I'm better off using
<jelmer> maxb: Can you give some examples of tradeoffs though, I'm not sure exactly what you mean by that.
<maxb> I have lots of projects in a svn repository which I'd like to convert to separate bzr repositories. I see that there are at least two mainstream methods of doing so - bzr-svn and bzr-fastimport -  and a bunch of other ones too. I'm looking for any guidance that will help me choose which I should use.
<jelmer> maxb: as far as I know both should be able to convert subprojects to separate bzr repositories
<jelmer> bzr-fastimport doesn't do deterministic revision ids, so you can't pull from the original svn branch later on unless you have the mapping files
<jelmer> but on the other hand, it might do rename detection, which bzr-svn doesn't do
<maxb> OK, I guess I'll just need to explore the options
<maxb> On another topic, is there any software to facilitate code review via bzr branches that companies can install for internal use - i.e. not Launchpad.
<maxb> I was going to look at BundleBuggy, but the project doesn't seem too healthy now bzr has left it
<awilkins> maxb, Launchpad can be installed locally... it's rather large though... I've just never had the time to finish configuring it
<maxb> awilkins: Yes, but not legally, unless you find a graphics designer to make you a new set of icons
<awilkins> What license are the icons under?
<maxb> Canonical Proprietary
<awilkins> Does "internal code review" count as development or production... but yes, that's slightly troublesome
<jelmer> maxb: reviewboard has bnasupport
<jelmer> maxb: reviewboard has basic support for bzr bundles
<maxb> I will have to investigate that
<jam> maxb: BundleBuggy is probably not actively maintained by abentley anymore, but it is probably a decent starting point.
<jam> I've heard good things about ReviewBoard, though.
<maxb> The most dispiriting thing about BundleBuggy was that it has quickstart documentation that doesn't work :-)
<rindolf> Hi all! I just blogged about how much bzr sucks - http://community.livejournal.com/shlomif_tech/41922.html
<nailuj24> rindolf: well done my dear...
<jpds> rindolf: Which version of bzr are you using?
<rindolf> jpds: 2.0.3
<jpds> Format <RepositoryFormatKnit4> for lp-64863440:///~inkscape.dev/inkscape/trunk/.bzr is deprecated - please use 'bzr upgrade' to get better performance
<jpds> rindolf: Tell the Inkscape guys to do that.
<rindolf> jpds: it's in my bug report.
<rindolf> If it's hosted on LP , why isn't it upgrade automatically?
<rindolf> It takes a second for bzr --version to run.
 * fullermd gets very unhappy with hosting providers screwing with his data...
<maxb> rindolf: Because it would be very stupid for Launchpad to silently force new formats on people when their local bzr versions might not be new enough
<jpds> rindolf: Backwards compatibility with what the developer is using I guess.
<maxb> rindolf: Whilst I agree that bzr's speed is not great, I don't think the attitude of your blog or bug report is anything other than unproductive
 * fullermd notes that the branch of postr takes 26 seconds, and the diff 0.16 from here..
<fullermd> Of course, going over a dumb protocol (http) means that latency is going to kill you flat dead.  And you may be rather farther away from it than I am.
<maxb> rindolf: In fact, why on earth do you comment on the time taken for the error to occur, when it's clearly a network problem
<Tak> originality: 4% accuracy: 6% grammar: 20% emotionality: 30% overall troll: 10%
<pturcotte> Is there a way to prune (remove) a part of the history? Let's say from revision 1 to X while the actual version is at X+50 ?
<james_w> pturcotte: no, that's not really possible
<rindolf> maxb: if it stops in the middle, I should be able to resume it later.
<Flydoire|Taktik> hi everyone
<Flydoire|Taktik> I just tried to install bzr on snow leopard from the pkg. bzr command does not work : bzr: ERROR: Couldn't import bzrlib and dependencies
<Flydoire|Taktik> anyone has an answer ?
<pturcotte> james_w: thanks.
<pturcotte> Then, is there a way to reduce the disk usage of the branch. My branches are around 420Mb, mostly binary files that are not in use anymore.
<james_w> not really, bzr is designed to have immutable history, and it's tough to get around that
<Kinnison> Do we have history horizon yet?
<mwhudson> jelmer: ok, i guess we should file a bug in the mean time?
<awmcclain> Hi all -- I've been looking through help commands but can't find it -- How do I get the last revision that a particular file was changed?
<luks> something scriptable? if not, I'd use bzr qbrowse
<luks> (`bzr qbrowser -r -1` to be more specific)
<luks> otherwise you probably have to mess with bzr log
<luks> which is not going to be very fast
<luks> I don't know of any built-in command that exposes the information, even though bzr has it easily available
<awmcclain> luks: Ok. Sounds great. Thanks!
<Flydoire|Taktik> familiar with this error ? : bzr: ERROR: exceptions.TypeError: Auth providers should be list ?
<lifeless> Flydoire|Taktik: no, but I'd guess at a old plugin or something like that.
<Flydoire|Taktik> hum
<Flydoire|Taktik> what about bzr: ERROR: bzrlib.errors.TooManyConcurrentRequests: The medium 'SmartSSHClientMedium(connected=True, username=u'fl-taktik', host='bazaar.launchpad.net', port=None)' has reached its concurrent request limit. Be sure to finish_writing and finish_reading on the currently open request.
<Flydoire|Taktik> .
<Flydoire|Taktik> ?
<fullermd> That's usually a secondary symptom.  Perhaps of the error you mentioned before.
<Flydoire|Taktik> will the bazaar.launchpad.net server kill my concurent requests so that it will work in a few hours ?
<fullermd> There probably AREN'T any concurrent requests.  It just looks like it when the connection fails.
<fullermd> (that error is from your local bzr, not from LP)
<Flydoire|Taktik> how to I fix it ? Do I have to get the latest trunk version ?
<fullermd> Are you sure there's something to fix?
<fullermd> That's an error that pops up in a single bzr invocation, and usually is just fallout from an earlier error.
<Flydoire|Taktik> I just got the bzr: ERROR: Could not acquire lock "(remote lock)":
<fullermd> It doesn't in itself leave anything hanging around for later runs.
<Flydoire|Taktik> so I break-lock
<Flydoire|Taktik> and I bzr pull again
<Flydoire|Taktik> and boom : bzr: ERROR: bzrlib.errors.TooManyConcurrentRequests
<Flydoire|Taktik> what shoul I do ?
<fullermd> Yes, that's not from the break-lock.  That's from some failure in that specific invocation, probably having to do with the connection either breaking or not being properly established.
<fullermd> Is there any output other than that?
<Flydoire|Taktik> yep
<Flydoire|Taktik> http://pastebin.com/d38355f11
<fullermd> What the error generally boils down to is a generic sort of "Hey, I can't seem to talk across this connection I expect to be there"
<fullermd> So you need to figure out why the connection isn't working out.
<fullermd> There may be something in .bzr.log about it, or you may need some debug flag...   -Dhpss maybe, to get it to tell you more.
<fullermd> (I don't know what would show you useful output)
<fullermd> Start off simple; can you connect to LP with sftp?
<Flydoire|Taktik> trying
<Flydoire|Taktik> yes
<fullermd> 'k...   try pulling over sftp instead of bzr+ssh (just change the protocol on the URL).  'll be a lot slower, but...
<Flydoire|Taktik> where do I change the protocol ? in .bazaar/authetication.conf ?
<fullermd> No, just do it manually.
<fullermd> bzr pull sftp://......
<Flydoire|Taktik> worked :D
<Flydoire|Taktik> thanks fullermd
<fullermd> 'k, so it's just something with bzr+ssh.
<fullermd> Try it with that regular URL again; maybe it was just a transient problem somewhere.
<Flydoire|Taktik> ...trying...
<fullermd> (you definitely don't want to use sftp instead of bzr+ssh in general; lot slower and more resource-consuming on both ends.  Useful diagnostic though, since it tests most of the same infrastructure)
<Flydoire|Taktik> worked fine
<fullermd> If it consistently works with sftp, and consistently fails with bzr+ssh...   well, we've localized it at least.  I don't know where do go from there, if something like -Dhpss doesn't tell any more.
<Flydoire|Taktik> maybe a pb in my repository ?
<fullermd> Hm.  OK.  We'll just chalk it up to Random Internet Schizo Crap   8-}
<Flydoire|Taktik> works : bzr pull bzr+ssh://fl-taktik@bazaar.launchpad.net/~openerp-community/openobject-addons/taktik/
<Flydoire|Taktik> does not work :  bzr pull
<fullermd> Well, that's a very different URL from what you've got there as the parent...
<Flydoire|Taktik> with
<Flydoire|Taktik> $ bzr info
<Flydoire|Taktik> Checkout (format: unnamed)
<Flydoire|Taktik> Location:
<Flydoire|Taktik>        checkout root: .
<Flydoire|Taktik>   checkout of branch: bzr+ssh://bazaar.launchpad.net/~openerp-community/openobject-addons/taktik/
<Flydoire|Taktik> Related branches:
<Flydoire|Taktik>     push branch: bzr+ssh://bazaar.launchpad.net/~openerp-community/openobject-addons/taktik/
<Flydoire|Taktik>   parent branch: bzr+ssh://bazaar.launchpad.net/~openerp/openobject-addons/5.0/
 * fullermd blinks.
<lifeless> ok, you shouldn't be pulling here
<fullermd> OK, well...   I'm not sure what you're asking for makes much sense.
<lifeless> use update instead
<fullermd> pull'ing the branch you're a checkout of is nugatory.
<Flydoire|Taktik> ok : sorry, I'm new to bzr, and it's quite confusing
<fullermd> Now, it may make sense to pull that parent.  I can see how that might legitimately give that error, if bzr is being too dumb or too smart about its connection, though.
<fullermd> So, that might actually be a legitimate case of that error message.
<Flydoire|Taktik> pull is to get changes from other branches, update just updates the current branch, right ?
<fullermd> Update roughly means "update my working tree to match the branch".  Pull roughly means "update my branch to match this other branch".
<fullermd> So when you run 'bzr update', you're saying "Get this working tree at . up to match the branch at bzr+ssh://[...]/taktik/"
<fullermd> 'bzr pull' is saying "Update my branch at bzr+ssh://[...]/taktik/ to match the branch at bzr+ssh://[...]/5.0/"
<fullermd> It's believable that bzr is doing something overly {smart,stupid} about trying to reuse a single connection to LP to do both sides of that.
<fullermd> Which would bring up that error.
 * fullermd passes that one to lifeless.
<jelmer> mwhudson, please do
<Flydoire|Taktik> ok, thank you for your time fullermd
<jelmer> mwhudson: does that branch have any round-tripped revisions?
<mwhudson> jelmer: your guess is as good as mine
<jelmer> mwhudson: svn proplist on the branch root should tell you
<mwhudson> jelmer: it has a svk:merge property, is that enough?
<jelmer> mwhudson: that would suggest at least that the problem is not in the roundtripping
<jelmer> mwhudson: although svk does often create very strange situations
<poolie> hi jam?
<poolie> hi all
<jam> hi poolie
<jam> good morning
<poolie> shall we talk?
<awmcclain> luks: What if I used bzrlib? I'm scripting the rev stuff, but it's from a python script
<awmcclain> luks: Would that be faster?
<luks> awmcclain: should be easy enough to write a plugin that does that
<luks> oh, it's actually a python script
<luks> yes, that should be easy
<luks> not sure if I'm the best person to help though. my bzrlib knowledge is probably mostly obsolete by now :)
<luks> I'd use something like wt.inventory[wt.path2id(filename)].revision
<luks> but there is probably a better way now
<awmcclain> thanks!
<lifeless> awmcclain: bzr ls would be a good place to put that query
<lifeless> awmcclain: in order to make it more easily scriptable
<awmcclain> lifeless: Ah, smart.
<awmcclain> What, you don't like  bzr log  settings.py | sed -n 2p | sed "s/revno: \([0-9]*\).*/\1/"? ;)
<lifeless> awmcclain: not really, no.
<lifeless> awmcclain: :)
<jam> awmcclain: besides, grepping .bzr/checkout/dirstate would be a lot faster :)
<igc> morning
<mr-russ> in bazaar, can I merge a number of commits and push them as a single changeset to a parent tree?  I can't find if you can in the documentation.
<lifeless> mr-russ: bzr branch parent foo; cd foo; bzr merge source_branch; bzr commit; bzr push :parent
<mr-russ> okay, so you merge from a branch which appears then as a single changset and push that.
<mr-russ> so in bugfix lifecycle you branch for bugfix, make 10 commits to get it all fixed propertly.  merge to you parent tree, then commit and push.
<m3ga> hi all, i'm looking for a pre-commit hook that would check all the files in the current commit, check if they have a copyright notice and if they do check if the current year is included in the (c) notice. if its not it would barf.
<mr-russ> okay, now conversely, how would you keep the entire commit history when pushing?  push the child tree directly?
<lifeless> mr-russ: yes
<lifeless> mr-russ: no data is lost either way; its just what is presented
<mr-russ> lifeless: thanks.  I've been unable to find anything on that from google.
 * igc bbl
<poolie> hi igc
<poolie> hi m3ga
<poolie> m3ga, i don't know if there is one like that
<poolie> i think there is a plugin that enforces whitespace rules and similar things at commit time
<poolie> and jml has one that checks for todo comments
<poolie> so you could adapt one of them
<jml> lp:bzr-todo
#bzr 2010-01-08
<poolie> jml, hm, that doesn't seem to exist
<jml> hush, I'm being excellent.
<jml> http://paste.ubuntu.com/353202/
<jml> poolie, :(
<jml> poolie, I can't find it on Launchpad. Maybe I made it all up.
<jml> I distinctly remember blogging about it.
<poolie> i remember you telling me
<spiv> Array['hosted', 'mirrored', NULL, 'remote'])[Branch.branch_type] ?  Surely proper SQL style would involve a table join ;)
<poolie> spiv thanks for flagging the issue with 2.0 in https://code.edge.launchpad.net/~jameinel/bzr/2.0.4-unregister-mem-trans/+merge/16980
<poolie> but i think you should actually have bounced it
<spiv> poolie: hmm, ok
<poolie> to me the benefit is nonzero but small
<poolie> do you agree?
<spiv> poolie: I think either way will be fine, really.  In absolute terms the risks and rewards for 2.0 are both very low.
<poolie> the worst that's likely to happen is test suite breakage i suppose
<spiv> I don't feel strongly, so I went with trusting jam's judgement.
<poolie> it's possible there will be some gc-related effect
<poolie> well, that is a good default
<poolie> :)
<spiv> If you feel more strongly than me, please add a review ;)
<poolie> i did
<poolie> i'm just wondering if we should either discuss or clarify the 2.0 guidelines
<spiv> Yeah.
 * poolie looks
<spiv> It's the sort of thing I'd be more relaxed about at the start of 2.0's life, I think.
<poolie> i think for the stable branch
<poolie> having low risk and low reward is not enough
<poolie> it needs to have a high reward
<poolie> because it's not just the risk, but also that a larger diff is harder to push through an SRU
<spiv> I think as time goes on the rewards for doing things to a stable branch tends to go down (less and less users, and the users that it has are happy or they would have jumped to the next branch), but the risks don't really drop in the same way.
<poolie> true
<spiv> But also it does help us to keep the delta between stable and trunk minimal.
<poolie> if john really wanted to do it in 2.0 i wouldn't necessarily veto it
<poolie> but i would want at least a specific rationale for putting it in
<poolie> that's good too
<poolie> hm
<poolie> though
<poolie> the thing where the delta is most going to matter, i think, is api changes that will limit your ability to merge patches across
<poolie> but of course they're also harder to put into the stable branch
<poolie> i suppose one could do additive-only api changes
<poolie> and then do the deprecation/removal of the old api, if any, in trunk
<spiv> Yeah.  Although reducing superficial conflicts from e.g. changing "MemoryTransport" to "memory.MemoryTransport" is nice too... that's not a big deal if there's just one, but multiple overlapping superficial conflicts can be a significant hassle to fix.
<poolie> true
<poolie> spiv, how about something like http://pastebin.ubuntu.com/353217/
<spiv> poolie: +1
<igc> back
<bendj> Hi.  Is there any particular (dis)advantage to bzr-managing a local dev box + a remote svr using bzr's sftp upload/checkout capabilities, versus mounting the remote server locally via sshfs (fuse over ssh)?
<lifeless> bendj: better to use bzr+ssh/sftp
<igc> thanks jml!
<bendj> lifeless: Why 'better'?  Are there specific features capabilities that are available with one approach, but not the other?  sshfs mounts, in general, are much more handily managed locally ...
<lifeless> sshfs mounts present a very odd picture of the latencies involved
<lifeless> and don't really act like local resources - for instance file locks won't work.
<lifeless> bzr+ssh urls will perform /much/ faster
<jml> igc, np. it was fun to get my sql ninja on.
<jml> igc, I just wish that turning an SQL query into a Launchpad page was less work.
<igc> jml: :-)
<bendj> lifeless: Huh, I was pretty convinced that file locks over ssfs ARE supported.  or do you mean bzr's file locking, in particular?  really surprised to hear bzr+ssh is "much faster" ... i mount all over the web via sshfs, and have never really seen performance issues.  then again, admittedly i have NOT benchmarked.  hmm.  worth investigating & learning more, sounds like ...
<mwhudson> james_w: hello
<mwhudson> james_w: how stable do you regard the BaseRecipeBranch api in bzr-builder to be?
<james_w> mwhudson: hi
<james_w> it can be as stable as you like :-)
<james_w> I can offer guaranteed API stability if that's all you are looking for
<james_w> but that may mean new APIs for new things, so it depends on why you are interested I guess
<mwhudson> james_w: i'm writing code that translates RecipeBranch &c objects into database objects and back
<mwhudson> if new stuff appears in bzr-builder, this code will have to change
<mwhudson> no way around that in any case
<james_w> yeah
<james_w> it sounds like API stability isn't the issue as such
<mwhudson> no, i guess not
<mwhudson> data structure stability
<james_w> is holding off landing things until LP is ready a better solution?
<james_w> we are going to want to make some data structure changes, but they will probably come with recipe format changes, which may give us some flexibility
<jelmer> hi mwhudson, james_w
<james_w> hi jelmer
<mwhudson> james_w: i wouldn't wait on lp for stuff really
<mwhudson> james_w: i can always refuse to have anything to do with formats > 0.2
<mwhudson> which is probably a good idea in any case
<james_w> jelmer: how's your flight looking?
<james_w> mwhudson: that's what formats are there for :-)
<mwhudson> james_w: indeed
<james_w> once I see some of your work next week then I'll have a better grasp on what your needs are, which should help
<james_w> I'm not out to break LP though, so I'll try and make sure that changes that I make are accommodating to you
<mwhudson> thanks
<mwhudson> i guess all i'd like to avoid, or at least know about, are pending fundamental refactorings in how recipes are represented
<james_w> that's easy enough to do
<james_w> nothing pending in that part currently, except talk of inheritance
<mwhudson> james_w: recipe inheritance you mean?
<james_w> yeah
<mwhudson> ok
<mwhudson> well, i'll deal with that when it happens
<mwhudson> at the least, it will be a format bump, right?
<james_w> yeah
<james_w> but now, I must sleep
<james_w> mwhudson: when do you arrive in Wellington?
<james_w> or are you there already now?
<mwhudson> james_w: probably only monday morning, or maybe sunday night
<mwhudson> james_w: sleep well!
<james_w> ok, I'll see you then
<james_w> have a good day
<jelmer> james_w: I'm flying tomorrow at 8 in the evening. What about you?
<jelmer> james_w: g'night
 * jelmer gets some sleep as well
<james_w> jelmer: 9pm for me, fingers crossed
<james_w> night
<jelmer> g'night!
<mwhudson> hee
<mwhudson> where's the bug? http://pastebin.ubuntu.com/353256/
<mwhudson> i guess it's in find_branches
<mwhudson> heh ** 2
 * mwhudson finds https://code.edge.launchpad.net/~ian-clatworthy/bzr-builder/fix-find-branches/+merge/15137
<chromakode> hey #bzr, I would like to uncommit a merge, but restore the subcommits that were merged. is there an easy way to do this?
<mwhudson> chromakode: i'm not sure i understand
<mwhudson> chromakode: what commands did you run and what would you like to have done?
<chromakode> mwhudson, unfortunately, someone on my team pulled from trunk, merged their changes, and pushed back to trunk, without proper review
<mwhudson> note that if you just run "bzr uncommit" you'll get into a situation with pending merges
<chromakode> oh, really!
<mwhudson> chromakode: ah, that old fun
<chromakode> I didn't know that
<chromakode> before the merge, there were 3 commits by a reviewer -- they're now wrapped up in the merge
<mwhudson> append_revisions_only = True ftw
<chromakode> so, I didn't know that factoid... perhaps I can figure it out with that new knowledge
<chromakode> what/where is that?
<mwhudson> in the .bzr/branch/branch.conf file
<mwhudson> let me see if it's documented somewhere
<chromakode> thank you!
<mwhudson> chromakode: hm, i found this https://lists.ubuntu.com/archives/bazaar/2008q3/046797.html
<mwhudson> chromakode: and "bzr help configuration" has some stuff
<mwhudson> but first, you need to recover from the mess
<chromakode> reading :)
<chromakode> yes. so, now I have 3 commits on my merge queue
<chromakode> how do I unmerge them?
<chromakode> note: there's also a commit on head *before* the merge that also needs to go
<chromakode> the log looks like:
<chromakode> * bad merge
<chromakode> * bad commit
<chromakode> I want:
<chromakode> 3 x * old commit from merge
<mwhudson> i think something like this
<mwhudson> bzr log --show-ids -l 4 and copy the revid of "bad commit" somewhere
<chromakode> got it
<mwhudson> then bzr log --include-merges and somewhere near the top you should see the old commits that you want back on the mainline
<chromakode> yep.
<mwhudson> that'll have a revno like 60.1.3
<mwhudson> bzr pull --overwrite -r $revno .
<chromakode> aha!
<mwhudson> will bring that bad to tip
<mwhudson> then i think you can bzr merge -r revid:$bad_commit_revid .
<chromakode> yes!
<mwhudson> and commit that properly
<mwhudson> s/bad/back/
<chromakode> I think that single pull --overwrite did the trick!
<mwhudson> well, it will have obliterated the changes your teammate made
<mwhudson> but looking back, perhaps that's what you wanted
<jml> hi
<jml> if I do a merge that changes a whole heap of files, and then I accidentally edit some files before committing, is there a good way of finding out changes I made that weren't part of the merge?
<mwhudson> jml: do the merge in another copy of the branch, then diff -r branch:
<jml> mwhudson, that's a good idea.
<mwhudson> jml: or perhaps better, do the merge in another copy of the branch, commit it, and then pull from there into the version you made changes in
<jml> mwhudson, ooh, I like that.
<mwhudson> you risk conflicts i guess, but they're probably ones you should know about
<jml> right
<chromakode> mwhudson, back -- yes, that's exactly what I wanted
<chromakode> mwhudson, they pushed it to their own branch before I obliterated them
<chromakode> thanks very much for the help mwhudson. you really saved me a lot of time. :)
<mwhudson> chromakode: cool, np
 * mwhudson wonders if bzr.dev r4943 will break launchpad
<Peng> Wow.
<mwhudson> probably
<Peng> Looks like bzr+http and Loggerhead don't use it, so I should be okay.
 * igc lunch
<Peng> Yeah, they're ok.
<poolie> igc, nice work on the imports!
<lifeless> spiv: I really want to fix the exception handling in     def _run_pre_change_branch_tip_hooks(self, new_revno, new_revid):
<lifeless> spiv: are you still attached to it?
<lifeless> spiv: by fix, I mean delete.
<spiv> lifeless: lemme look again
<lifeless> spiv: please do - and compare to '_run_post_change_branch_tip_hooks' right above it.
<spiv> lifeless: so the main thing I guess I care about is that TipChangeRejected is still passed through in such a way that a server-side hook can cleanly transmit it to the client.
<spiv> lifeless: and I doubt you'll break that
<spiv> lifeless: so sure
<lifeless> spiv: thats a matter of raising that exception :)
<lifeless> spiv: more than anything else, AFAICT.
<spiv> Right.  And there are tests about functionality too.
<spiv> So if you *do* break it somehow, you'll know :)
<lifeless> well, PQM will. But yes :)
<spiv> I think I'm still mildly in favour of having some sort of distinction between core code and plugins in cases like this so that we can better report errors (and attribute them to the right software), but not enough to cling to keeping this inconsistent with the rest of bzr.
<lifeless> spiv: I think we can do that without any formal distinction
<lifeless> stack introspection for instance, will be better done *without* rethrowing.
<igc> poolie: np
<spiv> Don't expect me to consider stack introspection to be cleaner than anything ;)
<lifeless> spiv: I think we'd need that to get solid results always, anyway.
<poolie> igc, i'm going to do the two small bugs i opened against bzr-website
<igc> poolie: I saw the gdesklets one. What's the other?
<poolie> mention gnu
<igc> poolie: cool. could you also change Contribute/Plugins to ...
<igc> the new guide ...
<igc> http://doc.bazaar.canonical.com/plugins/en/plugin-development.html
<poolie> is this in the wiki?
<igc> poolie: the current link points into the Wiki: http://bazaar-vcs.org/WritingPlugins
<igc> poolie: which just redirects to the new guide
<igc> poolie: I just want to cut out the extra click
<igc> poolie: the tutorial is part of the Plugins Guide now
<poolie> ok
<poolie> you're talking about the link in the web page footer?
<poolie> i can do that
<igc> yup
<poolie> ok, it's fixed in trunk but there's a permissions breakage causing it not to update on the live site
<lifeless> spiv: I think we need to use introspection because there are many ways a plugin could taint an action
<lifeless> spiv: hooks are one special case, but not necessarily even the most common source of user experienced errors.
<spiv> Sure.
<lifeless> spiv: https://code.edge.launchpad.net/~lifeless/bzr/hooks/+merge/17005
<lifeless> my yak for the day
<lifeless> spiv: thanks
<spiv> No worries.
<lifeless> are automirror's internals ~= to my sketch ?
<lifeless> spiv: because I bet its a post push hook, not a pre
<spiv> lifeless: oh, post tip change, yeah.  I didn't realise your code used pre.
<lifeless> no worries ;)
<spiv> :)
<spm> damn I am tempted to mis quote you two out of context. all that smiles and no worries; all we need is a "she'll be right mate!"...
<spiv> spm: or a "no wuckas"?
<spm> spiv: ok, I admit they're very low, but I do have *some* standards
<lifeless> spm: Good on ya mate
<spm>  /ignore lifeless
<lifeless> hah
 * spm wipes the tears of laughter from his eyes and tries to recall wtf he was doing....
<poolie> yay
 * poolie closes bugs
<poolie> igc, do i recall correctly that some measurements last year found bzr doing better than git over a dumb http server
<igc> poolie: in bzr 1.x, yes
<igc> poolie: I think we may have gone backwards over dumb http in 2.x but I'm not sure
<poolie> web site is updating again now
<poolie> spiv, hi, still around?
<spiv> poolie: yep
<poolie> in that bug 504102, the problem seems to be that the remotebzrdirformat in the registry is getting its network_name set
<ubottu> Launchpad bug 504102 in bzr "test_format_initialize_find_open has some isolation problems" [High,In progress] https://launchpad.net/bugs/504102
<poolie> this seems wrong
<poolie> would i be right in thinking it should only be set when you're talking about the format of some specific bzrdir?
<spiv> Which registry?  The bzrlib.bzrdir.format_registry?
<poolie> hm, apparently BzrDirFormat._known_formats
<spiv> But yes, that's my understanding too.
<poolie> i'm not sure how that meshes  with the format registry
<spiv> The per_bzrdir load_tests explicitly adds remote bzrdirs to the list of scenarios.
<spiv> So I'm not sure that the registry is involved.
<poolie> ah
<spiv> A remotebzrdirformat instance from that load_tests might still be inappropriately shared or mutated, though.
<poolie> so it's not the registry, but rather the single instance of that format in the scenario list
<poolie> i think all those tests will get a copy of the format
<poolie> we could give them a format_class instead
<spiv> Possibly the solution is simply to specify the default network_name at load_tests time?
<poolie> hm
<poolie> if the format object can be mutated (implicitly by calling other things on it)
<lifeless> Yeah we assumed formats were immutable
<poolie> then it seems like asking for trouble for multiple tests to share an instance of it
<lifeless> I think copying the Remote format in each scenario would make sense here.
<poolie> mm
<poolie> alternatively we could make them actually immutable again
<poolie> that may be harder
<lifeless> poolie: Remote formats are proxies though, so its hard.
<lifeless> mmm
<spiv> (let's go shopping)
<lifeless> couple of other random thoughts:
<poolie> hm
<lifeless>  - its possibly a bug, a test that should dup the format and writes to it: easy answer: fix that one test.
<poolie> they can only actually know this if they're connected to a particular instance of a bzdir
<lifeless>  - generally we get a RemoteFormat* via factory methods, so there isn't a reason for production code to be altering the scenario format object.
<poolie> lifeless: using the format to initialize a branch implicitly mutates it
<lifeless> poolie: oh MEEP
<poolie> mm
<lifeless> poolie: I consider that a bug
<lifeless> sorry for introducing it
<poolie> it looks ugly to me at least
<poolie> easier to reason about these things if they're immutable
<spiv> Perhaps initialising a branch should give that branch a copy of the remote bzrdir format?
<lifeless> immutable I think is hard here, but altering the parameter format should be unnecessary and can cause bugs.
<spiv> What lifeless just said :)
<lifeless> More generally immutable objects in python don't seem to work well: python is not geared for such idioms, with the notable exception of strings (and there too we run into performance and space issues)
<poolie> mm
<poolie> so we may be able to just remove the sideeffect of setting the name when it's created
<poolie> if nothing relies on that we should be ok
<lifeless> We'll want the format the branch uses to have the name set if we know it
<poolie> lifeless: this is the kind of thing i mean about the tension between the Format and the class of the instance
<lifeless> probably its passing in a format it should duplicate
<lifeless> poolie: well, RemoteFormat is a proxy object anyway; I don't see that this adds to that tension
<poolie> well
<poolie> it's kind of half a proxy object
<poolie> obviously it can be a proxy for an actual remote bzrdir
<poolie> it can also be exist in the abstract without one
<lifeless> poolie: I've recently in another project had cause to do format markers on disk again, and I used the split style we do in bzr again - I find it really easy and clear to work with - it made two separate hierarchies with separate concerns.
<poolie> to me that is a reflection of the tension
<poolie> well
<poolie> we have this bug
<lifeless> poolie: RemoteRepository can't exist in abstract; Remote*Format can - but then so can BzrDirMeta1Format
<lifeless> it has state and can be parameterised.
<poolie> i think the bugs we see here show that the code is not clear about what the object represents
<lifeless> doing that (BzrDirMeta1Format parameterisation) in the class would be really unpleasant, I think - it would make what shouldn't be global, global state)
<lifeless> poolie: Have a good weekend :)
<lifeless> poolie: [I'm still sick, can't really make a good case for or against anything atm, and this isn't a shallow discussion.]
<poolie> yeah, thanks
<poolie> no
<poolie> don't worry, i'm not going to pull it out now
<spiv> poolie: which method is mutating the format do you know?  initialise_on_transport?
<lifeless> poolie: oh I know :) You'd have to replace all the things that work well at the moment with something cleaner, to pull it out :)
<poolie> _initialize_on_transport_ex_rpc
<spiv> poolie: huh
<spiv> poolie: that method already goes to the trouble to make a new RemoteBzrDirFormat object
<spiv> poolie: so really it should be mutating that, not self, I think
<lifeless> sometimes a bug is just a bug
<lifeless> spiv: ack
<poolie> line ~3263
<poolie> that's what i changed
<lifeless> spiv: ah, I see. I was stupid.
<spiv> lifeless: it happens :)
<lifeless> spiv: it uses its own state to make the rpc call. It shouldn't.
<spiv> lifeless: right
<poolie> right
<poolie> it's used as both the archetype of the thing you want to create (in which case it can be partly populated)
<poolie> and the actual value of a thing, in which case it should be fully populated
<poolie> there's not necessarily anything wrong with this...
<lifeless> http://pastebin.com/f5b89a4ba
<poolie> but, with object aliasing etc, it seems a bit dangerous
<lifeless> should fix i t
<poolie> yes, thanks, i did that 20 minutes ago
<lifeless> poolie: cool
<poolie> i'm waiting to see if it passes
<poolie> btw, what's the difference between known_formats and format_registry?
<lifeless> offhand: known_formats == svn, hg, bzr, git, cvs
<lifeless> format_registry == bzrmeta1 format logic
<lifeless> nope thats wrong
<poolie> it's something like that but i'm not sure if it really needs to be in a not-quite-a-registry
<lifeless> I think known_formats is perhaps just what we had before format_registry
<poolie> i think the format_registry is the registry of pre-baked combinations
<lifeless> yes
<poolie> as opposed to the list of BzrDirFormats
<lifeless> that bit I'm sure of
<lifeless> there is a commment explaining something about it
<lifeless> it might be a thing to remove / turn into a separate object, but I'd need to page it in, look at what it has in it properly.
<poolie> nm
<poolie> was just wondering
<poolie> i think this is passing so while it runs i will poke at tribunal
<poolie> have a good weekend
<lifeless> Another WAG - it will have BzrMetaDirFormat1, BzrDirFormat4, BzrDirFormat5 etc
<poolie> i can see the different things that are registered
<poolie> i guess i wondered if it really matters
<lifeless> poolie: the comment it has is about performance probing for stuff. No idea if thats still relevant.
<lifeless> igc: I hope you don't land that --bind change - I really didn't see consensus on the list.
<lifeless> oh, ugh. I just replied to a 5 year old mail.
 * lifeless blushes
<poolie> https://code.edge.launchpad.net/~mbp/bzr/504102-test-isolation/+merge/17006 is the patch, still running i think
<lifeless> poolie: approved already :)
<poolie> yoy
<poolie> yay*
<lifeless> jml: ping
<lifeless> jml: I'd like to make your weekend hacking nicer; to that end care to approve my two testresources merges? ;)
<lifeless> you know what I'd love.
<lifeless> implicit per-product PPA's.
<poolie> yes
<poolie> would be great
<lifeless> with product relationships permitted to get product->product dependent PPA's.
<poolie> i'd like a view of all bugs tagged hottest100 across all projects
<lifeless> e.g. ppa:bzr/releases would depend on bzr-git/releases, if bzr-git was a relationship
<vila> hi all
<poolie> hi vila
<lifeless> I think that would be awesome.
<poolie> i was just thinking of you in bug 504640
<ubottu> Launchpad bug 504640 in bzr "selftest hang in test_bzrdir.TestHTTPRedirections_readonly.test_loop" [Low,Confirmed] https://launchpad.net/bugs/504640
<poolie> lifeless: if by 'depend' you mean 'virtually include' that would be even cooler perhaps
 * vila curses vbox for crashing again :-(
<vila> poolie: sounds a lot like the issues I encountered while debugging the leaking tests, say 90%
<poolie> but it's not really important
<vila> poolie: was it a full test run or a partial one ? --parallel involved or not ? (Not that it really matters, but it's always good to know a bit about the context)
<poolie> oh
<poolie> full, nonparallel, with -f
<lifeless> poolie: I do
<poolie> shouldn't 'bazaar-ng' have been a clue? :-)
<lifeless> poolie: figured they had an old list ref
<eLowar> greetings... what's the best way to safely backup a (live) Bazaar repository?
<Peng> eLowar: Using Bazaar itself would probably be best, except for the possibility of corruption.
<spiv> eLowar: http://doc.bazaar.canonical.com/bzr.dev/en/admin-guide/backup.html
<Peng> Oh.
<spiv> Peng: I know, actual documentation addressing things users care about, weird huh? ;)
<Peng> Trying to take all the fun out of figuring out solutions, huh?
<spiv> Peng: not sure, give me a sec to find the docs on that topic ;)
<eLowar> thanks a bunch
<Peng> spiv: Maybe there's a blueprint!
<eLowar_> oh and sorry for running off like this ;) I'm at work and we were trying to find this documentation, so I can't stay and chat right now :)
<eLowar_> cheerio
<spiv> eLowar: that's ok, glad we could help :)
 * igc dinner
<vila> poolie: so, about leaking tests, another way to look at it is to realize that the hang you encountered is one aspect of it. The irony is that the more bugs I fix in this area, the more likely it becomes to trigger hangs. That means all the related bugs should be fixed or we shouldn't touch it at all (and hope we keep being lucky to avoid it on pqm) :-/
<vila> poolie: I was close to fixing them all (famous last words) when I realized that while running full test runs without --parallel (which change the context enough to change the overall behaviour in various ways ...)
<lifeless> vila: that while [...] what ?
<vila> that, while
<lifeless> vila: I still can't parse it
<lifeless> vila: In english, the that that you have before the while implies a clause to which the that will bind
<lifeless> .
<vila> When I stopped working on that, I had the full test passing with --parallel=fork (and 8 threads)
<vila> From there I wanted to run witout --parallel=fork to get data on how tests were still leaking (the report doesn't work with --parallel)
<vila> The runs hang
<vila> that (while ...)
<lifeless> ok
<lifeless> so what report? we could do it in --parallel probably
<vila> yeah, that seems to be our best protection so far
<jszakmeister> Hello all
<bialix> hello all
<vila> lifeless: ghaa, I totally misread you remark, so the report that failed is the one about the leaking tests which presumably is lost into the test reporting (search for leak in tests/__init__.py, that's the first occurrence)
<ChrisMorgan> "Treeless" when creating a branch means that you don't get the working copy, doesn't it?
<bob2> yes
<bialix> hi vila
<vila> hey bialix
<lifeless> vila: can I suggest a refactoring
<lifeless> vila: change the leak implementation to use tags
<lifeless> so the result object accumulates tagged tests as leaking
<lifeless> and the leak detection sets tags. Assuming that that is possible.
<lifeless> that would flow through subunit fine.
<ChrisMorgan> Thanks
<vila> lifeless: ok, pasted in my associated BRANCH.TODO, I'll look into it when I get there
<ChrisMorgan> Also, I've got my own project which has two main chunks; a Python library (which goes in site-packages or somewhere in PYTHONPATH) and the actual Django projects (a sample one and then one for each client I get so I can keep 'em all).  How am I best to initialise my bzr repository?
<ChrisMorgan> subtrees somewhere or something like that?
<ChrisMorgan> I've got half the buzzwords but haven't figured them all out entirely yet
<bob2> a branch for each
<ChrisMorgan> Even though it's all the one project really?
<bob2> sounds like they're not one the project
<ChrisMorgan> I thought maybe the client ones should each be in a branch of their own but I thought I might do the library and sample one in the same or something
<lifeless> ChrisMorgan: sounds to me like the python library is one project; and each django thing is another separate project.
<ChrisMorgan> I'd be able to branch of one repository and then push to a different one... that'd work well with separate branches
<lifeless> ChrisMorgan: s/repository/branch/ there.
<lifeless> ChrisMorgan: repository != branch
<ChrisMorgan> Oh no... I'm confusing my talk :S
<ChrisMorgan> *sigh* :-)
<ChrisMorgan> I know what I meant at least, and so did you :-)
<ChrisMorgan> Could I use a shared /repository/ for these branches though?
<lifeless> of course
<lifeless> there aren't any limits on sharing
<ChrisMorgan> Do I need to do anything special with my bzr init?
<lifeless> no
<ChrisMorgan> Do you think I should use development or 2a?
<lifeless> use the default your bzr has
<lifeless> unless you have specific reason not to
<ChrisMorgan> OK
<ChrisMorgan> Now how do I create separate branches in the repository?
<ChrisMorgan> I've never gone through and created a project in Bazaar... only used the Inkscape one before this.
<ChrisMorgan> And they're using knit :/
<lifeless> ChrisMorgan: bzr init path
<jszakmeister> Is there a way to dump the contents of a pack file (in a semi-readable fashion)?
<lifeless> jszakmeister: with python, yes
<lifeless> bzrlib.pack has the API
<jszakmeister> Thanks!
<ChrisMorgan> lifeless: so, bzr init-repo myproject, bzr init myproject/lib, bzr init myproject/sampleclient, bzr init myproject/[companyname], etc.?
<ChrisMorgan> Could I do bzr init myproject/clients/sample etc. if I just create the clients directory?
<ChrisMorgan> Or would I need to init clients first...
<jszakmeister> Okay... next question: is there an easy to see some sort of formatted output of each record in the pack? :-)
<jszakmeister> I'm trying to understand this ghost revision stuff a little more and I'm not quite understanding how this error is being generated:
<jszakmeister> bzr: ERROR: Revision {StaticTuple('1@7e532cae-f599-4488-b39e-a91bcf8c4cdd:%2Ffile.txt', 'john@szakmeister.net-20100108092733-qdawmc2foo77br14')} not present in "<bzrlib.groupcompress.GroupCompressVersionedFiles object at 0x15cb4f0>".
<jszakmeister> If I cat the revisions, none of them point to john@szakmeister.net-20100108092733-qdawmc2foo77br14
<jszakmeister> But that information is obviously recorded somewhere. :-)
 * ChrisMorgan wonders whether Bazaar or some other version control system could be twisted to version the contents of a database rather than the filesystem
<ChrisMorgan> jszakmeister: I presume no matches for just qdawmc2foo77br14 either?
<jszakmeister> Nope.
<lifeless> ChrisMorgan: mkdir myproject/clients and otherwise, yes.
<ChrisMorgan> OK, thanks lifeless :-)
<ChrisMorgan> Thank you, you and bob2 have been very helpful :-)
<lifeless> jszakmeister: it will be in an inventory
<lifeless> jszakmeister: in the parents graph, I expect
<jszakmeister> Where can I find that?
<lifeless> repository.inventories.get_parent_map
<jszakmeister> Okay, I'll give that a whirl.
<jszakmeister> Before I do, lemme ask another question...
<jszakmeister> currently, bzr-svn is setting the parent on one of the files to point to that revision...
<jszakmeister> in a merge commit... should it be doing that?
<jszakmeister> bzr check seems to dislike it:
<jszakmeister>      1 inconsistent parents
<jszakmeister>       * 1@7e532cae-f599-4488-b39e-a91bcf8c4cdd:%2Ffile.txt version john@szakmeister.net-20100108092741-ei1r6ocf3zfl6e6u has parents ('john@szakmeister.net-20100108092733-qdawmc2foo77br14',) but should have ()
<lifeless> its a revision that you are missing; you should pull it into your repo and it will stop being a ghost
<jszakmeister> Well, it's not that easy.
<jszakmeister> If someone branches svn trunk, does all their work in bzr, and then merges it back to svn trunk... you end up with this problem.
<jszakmeister> IOW, it's quite easy to end up in this state.
<ChrisMorgan> If I want to just straight rename a branch in my shared repository - my product has a current code name but I'm not decided on its final name yet and might like to rename it - what's the command for that? I presume there is some way I can do that short of something like branch company/product, push company/newname.
<bob2> mv
<bob2> real mv not bzr mv
<Peng> Of course, you're still stuck with any branch nicks stored in history.
<ChrisMorgan> And that continues to work even though the branch information is stuck in the repository rather than the branch?  (Or is it?)
<bob2> the revision data is in the repository
<bob2> the branch data is in the branch
<Peng> ChrisMorgan: What are you asking?
<ChrisMorgan> Peng: repository with branch a/b, want to rename the branch to q/b
<ChrisMorgan> OK bob2, I thought with a shared repository the branch info was all stored in the repo rather than the branch?
<Peng> ChrisMorgan: What do you mean by "branch info"?
<Peng> ChrisMorgan: I think you're misunderstanding something.
<ChrisMorgan> all the history etc. of files
<ChrisMorgan> Am I?  :-(
<ChrisMorgan> Please correct me :-)
<Peng> ChrisMorgan: Yeah, revisions are stored in the repo.
<ChrisMorgan> So if I rename the branch ---
<ChrisMorgan> What happens?
<Peng> ChrisMorgan: Bazaar doesn't care about what the name of the directory is. (Except for the default branch nick.) As long as you don't move it outside the shared repository, you can call it whatever you want to.
<ChrisMorgan> Could you for example in Launchpad just 'mv inkscape.dev inkscape.devel' and have it continue on chugging with everything moved across to lp:inkscape/inkscape.devel?
<ChrisMorgan> Default branch?
<ChrisMorgan> Don't think I've heard any mention of that...
<Peng> ChrisMorgan: On-disk, all a branch is is a pointer to the most recent revision ID and some meta data (like the parent location and tags).
<Peng> ChrisMorgan: default (branch nick)
<Peng> ChrisMorgan: Not (default branch) nick
<ChrisMorgan> Oh dear... I'm more confused now :-)
<ChrisMorgan> Never mind, I'll search for it
<ChrisMorgan> I'm off to bed now anyway.
<Peng> Sorry. :<
<ChrisMorgan> I'll continue on asking tomorrow then for anything I still don't understand :-)
<Peng> ChrisMorgan: I just meant the name of the branch that's recorded in history.
<Peng> ChrisMorgan: Which is just a little bit of meta data that doesn't actually matter.
<ChrisMorgan> Peng: OK
<ChrisMorgan> I'll blindly name branches and hope I can rename them later :-)
<ChrisMorgan> Bye now.
<Peng> ChrisMorgan: You can, but you can't change the nicks stored in history.
<Peng> ChrisMorgan: See you. :)
<ChrisMorgan> Where's it stored though?
<Peng> ChrisMorgan: As part of each revision.
<Peng> ChrisMorgan: Look at "bzr log".
<ChrisMorgan> OK, thanks
<ChrisMorgan> Bye now for real ;-)
<Peng> :)
<jszakmeister> lifeless: and it's even more problematic when there is another person on a different team who doesn't have access to our bzr mirror (firewalls, policy, etc)
<marek_> hi, can i upload only specified trunk? i already dowloaded upload plugin
<rubbs> marek_: what do you mean? you only want to upload a specific directory?
<lornajane> I want to start using bzr-svn, but I have two problems.  Firstly, I haven't used bzr much.  Secondly, its an ubuntu 8.04 server.  Can anyone help me begin?
<lornajane> the packaged bzr-svn is 0.4.9-1, which I think is quite out of date
<maxb> lornajane: You'll definitely want to add the ~bzr ppa, where you can get the latest released version of bzr and some associated plugins
<rubbs> lornajane: you could try to use the ppa that the bzr team maintains. https://launchpad.net/~bzr/+archive/ppa
<rubbs> bzr-svn is in it
<rubbs> maxb: you beat me ;)
<lornajane> ah, thanks people
<rubbs> np.
<rubbs> also if you are new to bzr you could also check out the tutorials.
<rubbs> we have a new admin doc too... if it's not in the official it's in the beta release of documentation. It should still work for the current versions too
<rubbs> I'll see if I can dig up a link for you
<lornajane> the tutorials looked good, one reason I thought I could give it a try
<rubbs> http://doc.bazaar.canonical.com/bzr.dev/en/admin-guide/index.html
<rubbs> sorry for the long delay got a phone call
<lornajane> no worries at all, I appreciate your input!
<rubbs> np...
<rubbs> oh, that link is to the "beta" documention, but just about everything (if not everything) will work with the currently supported version. The documentation was added after that lastest release, and they probably won't backport it.
<lornajane> no worries, if something doesn't work I can dig or ask for help.  I'm only doing really really basic stuff, making changes and comitting them to svn, but want some of the offline features as I am on the road alot
<rubbs> you'll probably like bzr and bzr-svn then.
<lornajane> I hope so.  I know a lot of people using git, but I think bzr will suit me better
<rubbs> I'm just starting to learn git (work is finally getting a VCS) and I can say that for many things I like bzr better. but Git is a good one too.
<lornajane> I'm a very confident SVN user, but I will probably only use a few features of either git or bzr ... I'm more confident on getting help with bzr which is what swung it
<rubbs> good to hear. I and others are glad to hear that. we are trying hard to make it easy to get into bzr.
<lornajane> the docs are brilliant, the users I've met are friendly - I can't ask for more than that :)
<LeoNerd> How do I show a diff of a shelved change without actually unshelving it?
<LeoNerd> bzr unshelve --dry-run  only prints the summary, the filenames...
<maxb> LeoNerd: I think first you implement the code to do that :-/
<LeoNerd> Ahhh... hrm
<Kinnison> LeoNerd: then you contribute it upstream because that'd be handy for me
<LeoNerd> Heh.. as if my TODO list wasn't big enough already :P
<LeoNerd> Well, actually it's more of a TODO tree.. and it's both deep and wide.. I'm on a 4th level dependency
<fullermd> It's hard sometimes to see the TODO forest for the TODO trees.
<dobey> i just want to say how happy i am that bzr is designed the way it is
<dobey> thanks
<ezod> hello, quick question
<ezod> if i have a branch, bound to a remote branch, and i do a commit --local
<ezod> is there a better way to subsequently push that commit to the (bound) remote branch than bzr push <url>?
<ezod> i.e. without respecifying the url that it is already bound to in branch.conf?
<ezod> coming from git, i would have thought bzr push with no argument would do the trick
<beuno> ezod, once you push, it will remember the location from then on
<ezod> yes, it does (url lives in branch.conf), but just "bzr push" still says "bzr: ERROR: No push location known or specified."
<ezod> oh
<ezod> i see what you mean
<ezod> the "saved push location"
<beuno> yes
<beuno> I agree that not having a good default sucks a bit
<ezod> would it not make sense for that to be populated with the current bound location?
<beuno> well, yes
<beuno> I think so
<beuno> but other devs tend to disagree (for good reasons as well)
<ezod> at least, if it's not already been populated otherwise
<ezod> ah
<beuno> bring it up on the mailing list, we can take another stab at the subjectx!
<ezod> wilco, thanks :)
<ezod> even like, bzr push --bound or something would be nice
<ezod> as my current workflow involves digging in branch.conf for the url
<beuno> I think you can do something with revisionspec
 * beuno looks it up
<fullermd> bzr push :bound
<beuno> that's it
<ezod> oh, well that's excellent
<ezod> thanks
<fullermd> There are aliases for all the saved locations.  :bound, :push, :parent, etc.
<ezod> very convenient
<ezod> so :X for X_location in branch.conf i suppose
<ezod> great
<vila> ezod: I generally use bzr bind :push, but that's just to contradict fullermd  ;-D
<orattue> is it possible to update a checkout to a specific revision number? e.g. checkout is on revno 10, latest revision of trunk is 20. Can I update my checkout to say revno 15?
<beuno> orattue, I think update doesn't take a revision
<orattue> so I would have to branch
<orattue> hmm
<beuno> on a branch, sure
<beuno> bzr pull -r REVNO
<fullermd> It will in 2.1.  But prior to that, yeah, you're down to creating a new branch to fling around with pull.
<maxb> Hi. Does anyone know why bzr reconfigure has --with-trees and --with-no-trees instead of just --trees and --no-trees?
<maxb> Is it because the option parser would construe the latter as a single boolean, and reconfigure needs tri-state logic?
<jam> maxb: My guess is that whoever wrote the option wanted "--with-trees" to indicate an action
<jam> as "--trees" doesn't really say that you are adding anything
 * maxb was wondering about adding options to control append_revisions_only
<Lostinspace_46> I am running Karmic.  I have tried every permutation of this command...[cp src/bzr-2.0.0-0ubuntu1 public_html/my-repository/binary/] that is bzr2.0.0 and bzr_2.0.0.  I keep getting this msg...cp: cannot stat `src/bzr-2.0.0-0ubuntu1'.  I am brand new to this, and have no idea what is wrong. Can someone help?
<jam> Lostinspace_46: let's start by finding out what you are trying to do with this copy
<jam> are you trying to publish a deb file?
<jam> are you trying to install a ppa?
<Lostinspace_46> jam not quite, I am trying to create a repository as per http://mediakey.dk/~cc/howto-create-your-own-debian-or-ubuntu-package-repository/
<jam> Lostinspace_46: I think you are starting pretty far down the road
<jam> that guide assumes you've already created 'deb' files
<jam> and are just publishing them
<jam> as a debian repo
<jam> You need to go look for a guide as to how to create a deb package first
<Lostinspace_46> jam well in a way I am.  I am tired of fighting dependencies, so I decided it would be easier to repack "from site" as debs and put them in a repository so I can use deb installer.
<Lostinspace_46> "from site" pkgs that is
<jam> Lostinspace_46: Do you have a bzr deb that you are trying to set up this way?
<jam> At a minimum, I would expect it to end in ".deb"
<jam> (this also is a bit off-topic for #bzr, but we can try to help)
<Lostinspace_46> jam Why is it off topic? That's not an arguement, I just don't understand. And if you know a better place to ask, I will.
<jam> #bzr is a place to ask questions about the Bazaar Version Control System
<jam> not really debian packaging and repositories
<jam> (or ubuntu using debs, etc)
<jam> #ubuntu might be better
<Lostinspace_46> jam Hmm, I think I follow. I'll try #ubuntu.  Thanks for the help.
<rubbs> my job just decided to finally get a VCS (I've been fighting for this since I got here) and they chose git. (decision made without me really) I'm very used to bzr. how feasible is it to do development with bzr-git? is there a git tutorial for bzr users? I've tried asking on #git, but no-one's answering. I"m not expecting anyone to know this stuff off the top of their heads, but I thought I'd ask.
<ronny> bzr-git mostly works, it cant yet do normal push tho, as git lacks metadata support, so you'll have to use dpush+rebasing
<rubbs> is there any tutorial on how that works? coming from bzr I've never rebased (or needed to).
<jam> rubbs: I believe jelmer uses bzr-git to develop dulwich (the python git bindings)
<jam> rubbs: it amounts to using "dpush $UPSTREAM" rather than "push"
<rubbs> jam: ok, cool thanks.
<jam> which, IIRC, will rewrite your local branch to be based on the new git commits
<jam> It does mean there is some headaches if you do a lot of merging on the bzr side
<rubbs> mmm... well maybe I'll try some trial stuff on a test repo or two to see if I can get my work flow to work. If not I'll just learn git. It couldn't hurt to know them both.
<mtaylor> hey ho...
<mtaylor> bzr: ERROR: CHKInventoryRepository('http://bazaar.launchpad.net/~drizzle-developers/drizzle/development/.bzr/repository/')
<mtaylor> is not compatible with
<mtaylor> KnitPackRepository('http://bazaar.launchpad.net/~elambert/drizzle/gearman_replication_applier/.bzr/repository/')
<mtaylor> elambert:drizzle elambert$ bzr upgrade --2a lp:~elambert/drizzle/gearman_replication_applier
<mtaylor> bzr: ERROR: The branch format Meta directory format 1 is already at the most recent format.
<bjesus> anyone knows how the see the current revision in my working tree?
<bob2> bzr revno
<bob2> or do you want the revid?
<bjesus> nope, i've got a lightweight checkout which isn't always updated. revno gives me the latest revision on the master branch
<bjesus> what's the revid?
<bob2> a globally unique identifier
<bob2> revnos are only useful within a particular branch
<bjesus> well no, i guess that i want the revno, but i want to know the latest current revno, not the latest available. when running bzr revno from my lightweight checkout it connects to the server and tells gives me the latest revision
<fullermd> revno --tree
<bjesus> says there's not such option... is it new or something?
<fullermd> Not terribly.  1.17, NEWS says.
<bjesus> um... centos latest is 1.7.1... i'll try to update, thanks.
<fullermd> Guh.
<bjesus> thanks fullermd. i compiled 2.0.3 from source and it worked. but, now i still asks me for password, even though it shouldn't connect to the remote server at all. why is that? is there a way to skip it?
<m3ga> having some trouble writing a bzr pre-commit hook plugin. can someone please have a look at this : http://paste.lisp.org/display/93159
<m3ga> and explain whats wrong?
<m3ga> i have written any python since 2003. most use C, C++, ocaml and haskell
<fullermd> bjesus: Well, it has to have a branch context to give you a revno.
<bjesus> fullermd: why? I mean, last time i did 'bzr update' it wrote the revision it updated to, so why can't i see it again?
<bjesus> fullermd: anyway, i need to see that revision without a password. would writing a hook be good?
<fullermd> Because a revno only has meaning in the context of a particular branch (technically, a particular head), because it's related to the position in the branch.
<maxb> bjesus: It wrote the revision id ( a string like launchpad@pqm.canonical.com-20081022214747-h2sphj9zcuh1c1cq ) but to look that up to get the number, it needs to talk to the branch
<fullermd> You could get the revid without connecting probably, with revision-info
<fullermd> And the revno may be different now than it was when you update'd.
<lifeless> m3ga: findall doesn't take a regex, it takes a string for the regex
<lifeless> m3ga: if you have a regex, you call regex.match, or whatever.
<m3ga> re.search gives the same error
<bjesus> fullermd: nope, revision-info also askes for the password. can i write a hook that creates a text file with the revno each time i do 'bzr update'?
<lifeless> you are doing
<bjesus> just checked, seems like there's only post_pull but no post_update... :(
<lifeless> re [the module].findall [the convenience function] (copyright_re [the regex object], ...)
<fullermd> Oh, it shows the revno too.  Mmm.
<lifeless> m3ga: thats wrong - use the object directly!
<lifeless> copyright_re.findall(...
<lifeless> m3ga: or
<lifeless> m3ga: do re.findall(thestringyouwantcompiletoaregex,...)
<fullermd> I've got an alias for revid that uses 'version-info', but I'm not sure whether that checks tree or branch.
<fullermd> (and probably isn't smart enough to pre-optimize what info it looks up anyway)
<fullermd> bjesus: The problem is, that revno from then may not be of any use to you.
<m3ga> copyright_re.findall (content) -> bzr: ERROR: exceptions.TypeError: expected string or buffer
<lifeless> m3ga: ok, so what is content
<m3ga> content = future_tree.get_file_lines (file_id)
<lifeless> that will be a list of lines
<lifeless> content = ''.join(future_tree.get_file_lines (file_id))
<lifeless> actually,there is a helper in osutils somewhere, but the above will get you going
<bjesus> fullermd: revno is of use for me. why do you think it isn't? you are right though, version-info does gives me the current revno. but, it also asks for my password...
<m3ga> yay! compile time types would have been nice :-)
<m3ga> thanks lifeless
<fullermd> bjesus: Because the revno of that revision in that branch at the time you updated may not be its revno now.
<bjesus> why not? how can it be changed?
<fullermd> It can potentially change any time the head of the branch moves.
<lifeless> m3ga: np
<fullermd> It may happen all the time, or it may hardly ever happen, depending on the workflows you're using.
<lifeless> unless you set append_only
<lifeless> which you can if you want revnos to be stable
<fullermd> It may be that caching it would "usually" tell you something useful, in your setup, but there's no way to be sure other than checking.
<fullermd> Well, that would be one permutation of 'workflow'   :p
<bjesus> i don't get it. I've got A and B doing bzr commit and bzr update to C. both A and B a are lightweight checkouts, and C is just a server, no work being done there. When doing bzr commit', bzr tells me "commited revision xxxx". and it never changes...
<m3ga> lifeless: quite honestly, coming back to python after not using it for over 5 years is just as confusing as using haskell for the first time
<lifeless> m3ga: If you want to write bzr-haskell [bindings], that would be fine with me :)
<bjesus> what's append_only?
<fullermd> If two lightweight checkouts are the only way revs ever get into it, it would probably be pretty difficult for the numbers to change.
<fullermd> bjesus: http://wiki.bazaar.canonical.com/MatthewFuller/AboutMainline is a moderate-length discussion of the numbering.
<m3ga> lifeless: NO!
<lifeless> bjesus: its a setting which prevents revnos that are allocated ever changing [in a given branch]
<lifeless> bjesus: for instance, if you want to see a revno change in your setup, the 'uncommit' comand will do that:
<lifeless> it will pop the most recent commit off your branch, and then when you commit again you'll 'reuse' the revno.
<bjesus> and do think that if i'd set append_only on, it wouldn't ask me for the password?
<lifeless> fullermd: ^ simplest explanation I know of: its clear, selfcontained, doesn't need discussion of merges mainlines etc
 * fullermd files that away for reuse.
<lifeless> bjesus: its asking for the password because you're doing operations over the network.
<fullermd> No, that setting just makes it take extraordinary effort to cause the revnos to change.  It doesn't change bzr needing the branch context to figure them out.
<bjesus> okay... and if i'll do with the revid, which as i far as i can understand is unique and never changes - would then there would be an option to see the current revid without networking?
<fullermd> Not through the UI, I don't think.  You could get it by manually poking under the covers.
<lifeless> bjesus: if you're using lightweight checkouts, every operation that inspects the tree will connect to the network.
<lifeless> bjesus: with no exceptions.
<fullermd> Either with a little bzrlib usage in python, or by writing a stupid parser that knows just enough of the dirstate format to yank it out in your Language Of Choice.
<lifeless> fullermd: bzrlib won't permit it either, not while using any of the support abstractions
<fullermd> Oh?  You can't just open the tree without it looking for the branch?
<lifeless> fullermd: correct
<fullermd> That sounds bogus.
<bjesus> so there's no way to know when the checkout was last updated without network if using lightweight checkouts?
<lifeless> fullermd: it wants a branch object, that could be a thunk.
<lifeless> bjesus: thats correct
<bjesus> yeah, tried bzr lib before. it asked me for the password too...
<lifeless> bjesus: in fact, there's no way to know at all, because we don't store 'when an update was done', only 'revision parents' - which is a totally different thing.
<lifeless> so you can figure out what the parents are, and they can be used to get a lower bound on the time of the last commit
<fullermd> Well, you could guess "when" from timestamps.  But you presumably don't really want to know "when", you want some pointer to "what revision".
<lifeless> or at least on the time on the machine that did the last commit which has been pulled into the tree
<bjesus> well yeah but i don't care much. be it either when or what revision, i just need to know something about what files i have on my lightweight checkout, whichout connecting... 
<fullermd> Of course, you couldn't even figure the dates of the commits without talking across the network on a light co.
<lifeless> bjesus: I missed your initial problem statement. What are you trying to achieve?
<m3ga> is there a neater way of failing out of a pre-commit hook than raising a ValueError?
<bjesus> simple. i've got a web application in a bzr branch on server A. it isn't being used there, it isn't even running. just the code is there. Server B and C are running the application, and sometimes i change something in the code in one of them. I can do a lot of commits on server C, and before upgrading server B, i want to know it's state. So i want my web application to be able to tell the current revision, so i can just go to myapp.com/revision and it would y
<bjesus> the revision it's running. but i can't find any way to get that revision without entering the password, and i don't want to use ssh keys here.
<lifeless> m3ga: raising an exception is correct
<lifeless> m3ga: ValueError is ok, BzrError with a format string might print nicer on the console
<lifeless> bjesus: it cut off at 'would y
<lifeless> '
<bjesus> would yank the revision it's running. but i can't find any way to get that revision without entering the password, and i don't want to use ssh keys here
<m3ga> where do i import BzrError from?
<fullermd> So, you could cache the revid (or suck it out of dirstate) somehow, and it would always be right.  You could cache the revno somehow, and it would maybe be right.
<fullermd> It sounds like you're running out of the branch directly, rather than having the files installed by some sort of build process you kick off, so you couldn't jam something in there.
<fullermd> If keyword support was more mature, you could use that.
<bjesus> yeah, i'm running out of branch directly since it's an application which is constantly changing. from what i've checked, seems like keyword support isn't there it and mostly works with bzr export. what do you mean "cache the revid"? how? got any pointers?
<fullermd> Not really.  If I had to ugly-do it today, I'd bung up a few lines of code to scrape it out of dirstate.
<bjesus> umm... seems like getting the revid from dirstate isn't hard - it's quite a the top. i can't find revid there but maybe i'll go this way..
<bjesus> *can't find revno there
<fullermd> It isn't.
<fullermd> (AFAIK, and I'd be surprised)
<bjesus> yup, it isn't. thanks a lot anyway, i'll see what i can do from here :)
<lifeless> m3ga: bzrlib.errors
<lifeless> bjesus: I can suggest two things for you
<bjesus> i'd be glad to hear
<lifeless> bjesus: one, a post pull/update hook to stash the info for you
<lifeless> bjesus: e.g. it would invoke bzr version-info for you
<lifeless> bjesus: alternatively, when you update do that manually
<bjesus> well, i can do it manually but i've got some other users which would create a mess. as for the hook - that sound's good, but by looking at the hooks list it seems like there's a post_pull but not a post_update hook.
<bjesus> actually, what would happen if i'll start doing 'bzr pull' instead of 'bzr update'? is there a difference? can a lightweight checkout do that?
<lifeless> bjesus: you need a branch to be using pul
<lifeless> bjesus: we can add a hook for post_update quite easily. Its, oh, 15 lines of code-and-docs or so, plus a test or two.
<bjesus> well, isn't my main server a branch? i'm doing bzr update from there, isn't it a branch?
<lifeless> bjesus: the object you are updating is not a separate branch
<lifeless> bjesus: if you pull, you'd be altering the main server as well because thats where your branch is
<bjesus> oh, got it.
<bjesus> so you say i should fill a RFE for post_update?
<lifeless> WorkingTree.post_parents_change
<lifeless> yes
<bjesus> okay, last question - what's WorkingTree.post_parents_change ? :p
<lifeless> the name of the hook you should ask for
<bjesus> why not post_update?
<lifeless> I prefer to make the most useful hook I can when adding a new hook
<bjesus> but what does post_parents_change means? how is it different?
<lifeless> commit, push, pull, uncommit will trigger it as well
<maxb> and merge?
<lifeless> yes
<bjesus> oh, okay
<lifeless> up-thread, down-thread, pump too
<bjesus> https://blueprints.launchpad.net/bzr/+spec/post-parents-change-hook/
<lifeless> bjesus: oh, just file a bug
<lifeless> bjesus: blueprints are generally massive overkill
<bjesus> you sure? it's not really a bug, isn't it? i mean, it's not like there's something wrong about bazaar... :s
<lifeless> bjesus: I'm sure
<lifeless> bjesus: bugs are not exclusively 'a defect in what we thought was working correctly'
<lifeless> bjesus: more generally, we don't manage work via blueprints: most of our work is bug centric, so blueprints tend to get ignored, and launchpad doesn't provide an integrated view.
<lifeless> I wish blueprints and bugs were merged in launchpad in fact; it would be a lot simpler to work with.
<lifeless> if they were,for example, a slightly different UI on the same underlying concept
<bjesus> okay, i'm filling a bug report.
<NfNitLoop> Hrmm.  I thought I read that bzr-svn would populate svn:merge properties.  Does it not read them as well?  this branch's history looks very linear when it's mostly merges from another.
<lifeless> NfNitLoop: I don't know if it reads them yet, jelmer would know but hes on a plane
<NfNitLoop> how inconvenient for *me*!  ;)
<NfNitLoop> I s'pose I could read some docs.
 * NfNitLoop does.
 * fullermd . o ( irssi connect --bind... )
<NfNitLoop> aah:  Other features currently held back by Bazaars feature set:  Showing SVN merges as merges in Bazaar
<bjesus> @ https://bugs.launchpad.net/bzr/+bug/504997
<NfNitLoop> that's OK then. :)
<ubottu> Launchpad bug 504997 in bzr "post_parents_change hook" [Undecided,New]
<bjesus> oops :) didn't know it would happend automagically
<lifeless> bjesus: it doesn't, you referenced it
<maxb> NfNitLoop: What do you mean by svn:merge? That's not a normal property
<maxb> You probably mean one of svnmerge-integrated, svk:merge, or svn:mergeinfo
<NfNitLoop> ah, svn:mergeinfo. Whatever it's called. ;)
<maxb> Yeah. I kinda need support for that too :-)
<NfNitLoop> I can see why it's not there.  in svn you can merge in any revision (cherrypick).  You can't quite do that in bzr.
<fullermd> Well, you can also merge in random files or subparts of a branch (or superparts of a branch, come to that)
<NfNitLoop> oh, good point.
<NfNitLoop> yeah, SVN's data model is...  special. :p
<ronny> it woultn be that much of an issue is svn had propper tools to work with that, but it doesnt
<fullermd> Mmm.  "superparts" is an interesting etymological construction...  I'll have to try using it sometime it can really mess people up.
<NfNitLoop> ronny: what would propertools to work with that look like?
<ronny> NfNitLoop: something that helps figuring the relations between subtrees
<NfNitLoop> aah. yeah.
<fullermd> Seems tough to do, since the relation among subtrees is entirely transitory.
<NfNitLoop> well, you can sortof do that.  Just "svn log" till you see the branch copy, then you know those two things are branches of each other.
<ronny> fullermd: thats why svn's history model is a complete engineering fail
<NfNitLoop> or, at least, were at one time.
<ronny> if one needs seriously smart tools to figure what the history is like, something is wrong
<ronny> hg/git/bzr do better there
<fullermd> Well, by restricting the meaningful actions.  That's an easy way to make existing models capable of holding your results   8-}
<ronny> well, filtering out all the stuff that is insanely hard to support
<NfNitLoop> and/or nonsensical.
<fullermd> Eye of the beholder.
<ronny> the kiss principle is powerfull
<fullermd> SVN lets you "branch" a file within a branch, and merge changes.  It's not overly hard to dream up cases where that's useful.
<fullermd> Branch subparts of a branch has its uses too.
<ronny> fullermd: working with strict subtrees can actually be simple
<ronny> but svn doesnt restrict it
<fullermd> Well, there are a lot of bits&pieces of these things that aren't conceptually hard to do in a DVCS, except for the 'D' part.
<ronny> D part ?
<fullermd> I mean, if your repository is all in one place, who cares that you have to [internally] copy 200 gigs of history to copy the 180k of history for the subtree you're branching?
<fullermd> Whereas if you're distributed, you care a whole lot.
<ronny> fullermd: thats where partial history support starts to matter
<ronny> bzr has, hg will have, no idea about git
<fullermd> Well, but there's two types of partial history support involved.
<lifeless> git has alternates, functionally equivalent to stacking
<fullermd> One is simple horizons, which any of the above can do.
<lifeless> hg has punching, which is a bit different
<fullermd> The other is slicing subsets of the tree, which is a LOT harder.
<ronny> lifeless: punching?
<fullermd> hg might have the easiest time; I think their lower levels are a lot more file-oriented than bzr/git.
<lifeless> ronny: history punching, its what hg calls it
<fullermd> (certainly their storage is, but I have vague memories of discussions suggesting that it leaks up higher too)
<lifeless> they keep the index, but discard the content
<ronny> lifeless: thats not what i meant
<ronny> lifeless: there was some work on something comparable to bzr ghost revisions
<ronny> lifeless: i dont think punching is in the actual official hg, seems more like a external patch
#bzr 2010-01-09
<ronny> lifeless: is git alternates networking-cappable?
<ChrisMorgan> I have another something which occurred to me; Inkscape has a devlibs SVN repository which has lots of binaries and things in it such as are used to compile Inkscape for Windows (Python, GTK, everything except MinGW).  This could be migrated to Bazaar now without it becoming enormous with lightweight branches, couldn't it?
<ChrisMorgan> Historically it wasn't feasible but I /think/ lightweight branches should do it.
<rpcesar> hello. the server I am trying to make a checkout using sftp, but its not published publicly via http://. In addition, the server uses a private key (works with putty and scpftp just fine). when I attempt to set the url to sftp://username:password@mycheckout.mydomain.com/ it fails with unable to authenticate host. then says something about supported auth types and public key. I am trying to figure out how to connect using my private key.
<Peng> Bazaar should find it automagically.
<Peng> Specifying the password in the URL is weird -- it's probably making bzr decide to use password auth or somethin'.
<Peng> I don't know any of the details on how to get SSH keys working with bzr on Windows... It's easier on *nix. :P
<Peng> Probably something in the docs, though.
<Peng> rpcesar: http://wiki.bazaar.canonical.com/Bzr_and_SSH maybe?
<rpcesar> i removed the password and username, it still doesent work right. and yes, this is on windows
<rpcesar> im aware of placing keys in certain directories on unix, cant seem to find an equiv here
<rpcesar> putty logs in fine, but I cannot seem to find the settings for sftp
<Peng> There's nothing SFTP-specific here... It's just SSH.
<ChrisMorgan> rpcesar: have you used Pageant?
<Peng> rpcesar: Did you try that link?
<ChrisMorgan> You should start Pageant and load the key in it
<rpcesar> ok, im in it
<Peng> In fact, that link discusses Pageant.
<rpcesar> yep, that worked
<Peng> Good. :)
<rpcesar> I need to keep pageant open correct?
<rpcesar> (as it provides the keys I assume)?
<rpcesar> now, im still getting a different (probably unrelated) error stating that it is "not a branch"
<rpcesar> the folder I am browsing to contains the .bzr folder
<rpcesar> but its still saying "Not a branch"
<Peng> rpcesar: Note that paths are relative from the root.
<Peng> rpcesar: sftp://example.com/home/you/...
<Peng> rpcesar: Or, equivalently, sftp://example.com/~/
<rpcesar> hmm.. ok well I am actually working with a subdomain
<rpcesar> mybranch.website.com
<rpcesar> which points to the folder that contains the .bzr file (the beginning of the branch)
<rpcesar> if I log in via scp it takes me to the right folder
<Peng> Welll...bzr wants the path from the root of the server.
<AfC> [I hate that]
<rpcesar> sftp://myusername@name.website.com/~/web/website.com/name
<rpcesar> I just tried this, it navigates to the the web home directory, etc, right to the file semi absolutely
<rpcesar> its saying not a branch aswell
<rpcesar> (~ moves it back to home)
<rpcesar> I also used a symbolic link of the server to link to it, and no dice
<Peng> Maybe it really isn't a branch. :D
<Peng> On the server, what does "bzr info" say there?
<Peng> You might have the path wrong. Or even a typo1
<Peng> Nice. I typod the first character after "typo".
<Peng> typoed? typod?
<rpcesar> nevermind, i got it. had to actually type in sftp://username@branch.website.com/home/.....
<rpcesar> I dont quite understand though how it does not automatically take it to the proper path
<fullermd> Peng: The future tense is obviously "You know beforehand, just don't do it"
<rpcesar> load branch.website.com into any sftp program and it goes right to the folder.
<rpcesar> but thank you so much for your help guys
<rpcesar> today is my first time using bzr, come rom an svn background, that just seemed so much easier :)
<ChrisMorgan> rpcesar: you'll need to have the key loaded in Pageant whenever you want an SSH connection
<ChrisMorgan> Don't worry, I had trouble with it a month or two ago when I started with Bazaar on Windows too.
<ChrisMorgan> The people in here helped me to understand it though :-)
<ChrisMorgan> Since then, just this week I've moved to Ubuntu as my main OS and it really is a lot simpler.
<rpcesar> yes, i love ubunto. unfortunately, when dealing with clients, unfortunately this is for work and not allowed :)
<rpcesar> ok, ran into another issue. I get ERROR: Cannot lock LockDir([path]/.bzr/branch/lock/gobbledegook.tmp) Permission Denied. when I attempt to commit
<lifeless> rpcesar: sounds like you don't have permissions to do the commit
<lifeless> rpcesar: as for what /~/ wasn't working - I dunno, it works for other users. Perhaps its a special sftp server?
<EdWyse_Office> could someone familiar with setup.py take a look at http://paste2.org/p/600644 and tell me if that's the correct way of including the include file in MANIFEST?
<lifeless> MANIFEST.in is the normal way
<EdWyse_Office> Except MANIFEST.in isn't in the dev tree.
<EdWyse_Office> My intention is to create a patch that will allow bdist_rpm to be made.
<lifeless> EdWyse_Office: do add MANIFEST.in
<lifeless> EdWyse_Office: didn't jam paste a patch for you the other day
<EdWyse_Office> Yeah, and it didn't work.
<aidalgol> My clone operation just failed with a 110 error.  How can I tell bzr to pick up where it left off?
<EdWyse_Office> So I grabbed the source repo and I'm looking at how the devs designed it to work.
<EdWyse_Office> Since I have more time now...
<GPHemsley> How do I get $Id$ to expand again?
<aidalgol> xb
<aidalgol> Oops!  Ignore that.
<spiv> GPHemsley: the bzr-keywords plugin
<GPHemsley> spiv: Remind me how to activate that? :/
<spiv> GPHemsley: it should come with docs
<spiv> GPHemsley: (I'd have to go read them too)
<fullermd> It's not really usable in practice.
<GPHemsley> where are they? `bzr help keywords` didn't work
<fullermd> It does once you install the plugin  8-}
<GPHemsley> oh, I thought it said it comes with Bzr... I hate Launchpad.... *grumble grumble*
<GPHemsley> so, uh, how do I install it?
<lifeless> EdWyse_Office: We haven't tried to make bdist_rpm work :)
<lifeless> EdWyse_Office: so don't limit yourself to what we do at the moment
<fullermd> GPHemsley: Something like `bzr branch lp:bzr-keywords ~/.bazaar/plugins/keywords/`
<EdWyse_Office> lifeless: I found the right way to do it using distutils.extension now, so unless you /really/ don't want me to do it in setup.py...
<GPHemsley> $Id$ isn't in the list of supported keywords now output by `bzr help keywords` :/
<lifeless> EdWyse_Office: I don't particularly care; the reason I say MANIFEST.in is because thats what is usually used for increasing the manifest
<EdWyse_Office> ok
<spiv> GPHemsley: yeah.  It should probably be added, although it is a bit of an odd fit because bzr versions trees, whereas cvs versions individual files.
<GPHemsley> well, SVN has it, too...
<lifeless> GPHemsley: svn also versions individual files
<fullermd> Well.  All the existing keywords all refer to just the file too anyway.
<GPHemsley> lifeless: Not insofar as assigning an ID number
<lifeless> While I think we're too tree orientated, we're the same as git/hg/monotone/codeville/etc
<spiv> fullermd: yeah
<fullermd> It just misses the aggregation of $Id$
<spiv> fullermd: like I say I think it probably ought to be added
<lifeless> GPHemsley: Last I checked the internals, it did.
<GPHemsley> lifeless: a revision ID refers to a whole collection of files
<GPHemsley> lifeless: How it stores it internally may be another story
<lifeless> GPHemsley: thats precisely what I mean, ids refer to things changed in svn, not to the state of a whole tree
<GPHemsley> oh
<lifeless> you can infer the state of a whole tree, but if compare with bzr/git/etc the whole tree /changes/ to record a commit
<lifeless> which is a fundamental difference
<GPHemsley> well, I'm not interested in the rev ID for $Id$ so much as all the rest of the data
<lifeless> what data is that
<fullermd> ...  well, I use $CVSHeader$ rather than $Id$, but it's the same aside from the path...    Path, version, date, committer, state.
<lifeless> GPHemsley: you probably want a pre commit start hook then
<lifeless> GPHemsley: or something like that
<GPHemsley> lifeless: Here's an example from SVN: $Id: LICENSE 50 2009-06-24 22:12:19Z gphemsley $
<lifeless> GPHemsley: and that adds lines on each commit?
<lifeless> or just the one line
<GPHemsley> just the one
<lifeless> ok keywords probably does it then
<fullermd> It has the individual pieces of information; it doesn't have a keyword that aggregates 'em all.
<fullermd> So you could just put a /* $Path$ $Revision-Id$ $Date$ $Committer$ */ sorta thing together.
<GPHemsley> yeah, but that's a bit much
<fullermd> I doubt it'll be too hard to add $Id$; it'll probably show up eventually.
<fullermd> 'minds me, I need to file a bug about the collapsing...
<EdWyse_Office> Ok, lifeless, I apologize. I was wrong about distutils (though I still consider it a bug not to include dependencies in the manifest). I'll make the MANIFEST.in file
<lifeless> EdWyse_Office: if it works for you, thats all that matters; the rest is detail
<EdWyse_Office> Yeah, it didn't, but now I know why at least.
<lifeless> why didn't it work?
<EdWyse_Office> It's just not designed to include .h files, regardless of the Extension declaration. Making my rpm now, let's see if it works...
<EdWyse_Office> Same problem as last time... bdist_rpm fails to build the package because rpm is expecting to find the manpage bzr.1 and instead finds bzr.1.gz. It turns out to actually be a distutils bug: http://bugs.python.org/issue644744
<Kamping_Kaiser> is there any reason in particular why bzr log -r -3.. acts differently to bzr diff -r -3..? (the former displays the last 3 log entries, the later does nothing)
<Kamping_Kaiser> hm, perhaps i ran it wrong
<fullermd> Well, if there aren't any differences between the files in -3 and -1...
<Kamping_Kaiser> looks like thats the case - commit -1 is nothing but a commit entry
<Kamping_Kaiser> joys of rebasing *heh*
<Kamping_Kaiser> thanks for the quick responce too
<HFSPLUS> !ops
<ubottu> Help! Channel emergency! (ONLY use this trigger in emergencies) -  elky, Madpilot, tritium, Nalioth, tonyyarusso, PriceChild, Amaranth, jrib, Myrtti, mneptok, Pici, Jack_Sparrow, jpds, bazhang, jussi01, Flannel or ikonia!
<poolie> HFSPLUS: ?
<RAOF> Again?
<HFSPLUS> !ops
<ubottu> Help! Channel emergency! (ONLY use this trigger in emergencies) -  elky, Madpilot, tritium, Nalioth, tonyyarusso, PriceChild, Amaranth, jrib, Myrtti, mneptok, Pici, Jack_Sparrow, jpds, bazhang, jussi01, Flannel or ikonia!
<RAOF> poolie: They come on to Ubuntu-related channels and call the ops untill they get kicked.  Don't ask me why.
<fullermd> Some filesystems are weird like that.
<RAOF> Heh.  I've seen a number of people complaining about hfs+ recently :)
<lifeless> EdWyse_Office: sounds like you need to fix distutils :(
<ruki> i am getting this error: http://pastebin.com/m3965372f while pushing to my branch
<lifeless> ruki: give break lock the same url you pushed too
<lifeless> the error is misleading about the url to use
<ruki> lifeless: http://pastebin.com/d6fd1ce8a
<Peng> ruki: Follow what it says. :P
<ruki> Peng: ok
<Peng> ...
<lifeless> poolie: #subunit exists btw, if you like
<lifeless> poolie: I wish lp bugs mail was a little friskier
<Adys> wasn't there a way to avoid committing files unless specified in bzr ci, without adding them to bzrignore?
<Kamping_Kaiser> --strict?
<Adys> no, more like; i have some local.py file; i run bzr something local.py; bzr ci; it doesn't commit local.py but commits the rest
<Adys> until I bind it again to the branch
<Adys> a local bzrignore basically
<Kamping_Kaiser> hm. bzr shelve?
<Adys> looks right, thanks!
<Kamping_Kaiser> np :)
<spiv> There's a --exclude option for bzr ci, too.
<Adys> spiv: yeah but that involves typing it every time
<spiv> Well, not really any worse than bzr shelve.
<spiv> You could make an alias for it, though, if it's always the same file(s).
<Adys> bzr shelve is only typed one until unshelve
<spiv> Oh, I see.
<spiv> I was thinking that you'd still want it in the workingtree after the commit.
<Adys> well the files themselves stay in the working tree, its just ignored by bzr commit
<Adys> from what I understand, anyway
<spiv> 'bzr shelve' will move uncommitted changes from your working copy onto a "shelf"
<spiv> So if you did e.g. "bzr shelve --all", then "bzr st" would show no changes.
<Adys> well yeah
<spiv> And if you opened the files in an editor, you wouldn't see the changes either.
<Adys> uh
<Adys> oh
<Adys> hmm yeah thats not it
<spiv> (Until you unshelved them, of course)
<spiv> It would be fairly easy to write a plugin to do what you want, I think.
<Adys> hmmm I was sure it was in bzr
<spiv> Perhaps add a 'bzr hold-file FILE ...' command that adds file-ids to a list in .bzr/checkout/held-files, and a corresponding 'unhold-file' command.
<spiv> And it would wrap 'bzr commit' to automatically pass those files to commit's --exclude.
<Adys> yep
<spiv> (Possibly add an --override-holds option too)
<spiv> If it wasn't getting late here I might try doing it now :)
<Adys> I'll try doing it
<spiv> Cool.
<Adys> reading up on bzr plugin doc
<spiv> Ask here or on the list if you get stuck.
<Adys> kay :)
<spiv> As far as your original question, as you've probably gathered I don't know of an existing solution for that.
<spiv> Well...
<spiv> You could perhaps use looms like this, sort of, but that would be overkill and clumsy.
<Adys> spiv: how do you pass multiple arguments to --exclude?
<Adys> --exclude "foo.py bar.py" ?
<Adys> also good to note --exclude / -x isn't in bzr help ci
<spiv> Adys: Hmm, I see it in that help
<spiv> Adys: I would expect you can pass multipe -x options
<Adys> http://dpaste.com/142859/
<spiv> Adys: i.e. -x foo.py -x bar.py
<Adys> ill try
<spiv> Adys: it's there on line 20 of that paste?
<Adys> I'm blind :/
<Adys> and yes, multiple -x works
<Adys> thanks :)
<spiv> It doesn't help that there's no obvious ordering to the list of options.
<lifeless> spiv: BTW,  have I pointed you at lp:testrepository ?
<spiv> lifeless: not until just then ;
<spiv> ;)
<spiv> Gar, the "Subscribe to mailing list" link fails to take to me a page from which I could actually subscribe to the mailing list.
<lifeless> spiv: which link? I can fixness
<spiv> lifeless: the one on https://edge.launchpad.net/~testrepository-dev, I'm not sure if you can actually fix that.
<lifeless> oh, maybe not as easily ;)
<spiv> lifeless: (it was where the "Unsubscribe" button now is for me)
<lifeless> spiv: did you file a bug for barry?
<spiv> It took my to my +editemails page, which isn't particularly useful.
<lifeless> oh right, yes.
<spiv> No, but only because it's much too late at night to be filing coherent bugs.
<spiv> Especially in this heat.
<lifeless> bugs aren't lasers :). speaking of the time... gnight.
<ruk> do i have to add, commit everytime i have to update my branch ?
<ruk> or do i just have to bzr push?
<luks> can you reformulate the question?
<luks> what do you want to do?
<Colonel-Rosa> morning, does bzr have commit globbing?
<Colonel-Rosa> bzr ci *index.php
<Colonel-Rosa> commits all index files
<luks> your shell does that
<Colonel-Rosa> nvm, got it
<bendj> Hi.  With scheme=ssh in my ~/.bazaar/authentication.conf, how/where do I specify a *different* ssh config file?  atm, i get: "Bad owner or permissions on /root/.ssh/config" if I, e.g., try to exec 'bzr branch lp:pressflow pressflow6-core'.  Not surprising, since my ssh config is at a different, non-default file path...
<bendj> Reading @ http://doc.bazaar.canonical.com/latest/developers/authentication-ring.html, I don't see (?) any way to spec the ssh config path :-/
<Peng> ...You're running bzr as root...?
<Peng> Oh, you're gone too.
<EdWyse_Mobile> Any idea how to fix this segfault, http://paste2.org/p/601692 , in the 2.0 branch? ( or at least where to start looking )
<poolie> hi EdWyse_Mobile
<poolie> wow
<poolie> please file a bug for it
<poolie> basically i'd look at why that pointer could get to be null
<Supertanker> Would it be appropriate to use bazaar to keep track of versions and revisions of my novella document files? Or am I looking for some other sort of backup/revision solution?
<gutworth> Supertanker: do you write them?
<ronny> anyone got an idea where jelmer is, i got a pair of trivial subvertpy patches for him
<Supertanker> gutworth, yep
<Supertanker> My current system is tons of .odt files in a directory with different names :P
<gutworth> then that would be reasonable
<Supertanker> Huh, okay.
<gutworth> ah, bzr doesn't do great with binary files
<Supertanker> I was just wondering if there was another way to do it.
<Supertanker> I thought .odt was a sort of .xmlish format?
<Supertanker> (Probably not :P)
<gutworth> it's a compressed directory of xml files I believe
<gutworth> so binary
<Supertanker> O.o
<Supertanker> Nope, it's not text
<gutworth> /compressed/
<Supertanker> Yeah, that makes sense
<Supertanker> What about .abw files?
<Supertanker> I believe those are plaintext.
<Supertanker> Unless specifically saved as .abwz or .abwbz
<Supertanker> Oh, there we go
<Supertanker> I could save it as Open Document Text (Flat XML)
<bendj> I'm setting up a bzr-based development/staging/production workflow.  Seems there are countless ways to do this.   It's just for me -- no other devs -- and I'm wondering (1) with atomic commits @dev, do I really need a standalone staging step? (2) should production be a branch, checkout, or rsync of a 'working' dev/staging branch? What do folks here do for 'best practice'?
<spiv> bendj: it depends on what you want from your production rollouts
<spiv> bendj: but keep in mind for example that neither 'bzr co' or 'rsync' will atomically update a tree on disk.  So if this a website, a client might hit the site while only half the files are updated.
<bendj> spiv In my case, the production site is my live drupal (actually, pressflow) site.  and, no, i haven't figured out yet how i'll stage the databases .... ;-)
<spiv> bendj: so you might want to checkout or rsync to a separate directory, then do a rename or update a config file to point at the new location, if that scenario concerns you.
<spiv> bendj: but basically any of a checkout, rsync, or say the bzr-upload plugin will do an decent job of actually getting onto disk on your production server.
<bendj> spiv Hm.. Hadn't considered the rename/update options.  Was thinking that I *need* to drive everything via bzr.
<spiv> s/actually getting/actually getting files/
<spiv> Well, a checkout that you update would have an advantage that it's easy to see which version has been rolled out compared to the current development version.
<bendj> spiv except that rsync would leave the production site itself NOT under revision control, tight?
<spiv> But depending on how tightly you control your rollout process, perhaps you'd already know that anyway.
<bendj> Oh, ... didn't look up
<spiv> bendj: right, but you're not going to be editing files on production are you? :)
<bendj> Who me? Never! UhUh! Nope! No Sir!  That would be nuts! ;-p
<spiv> :)
<bendj> Well, to be technically correct -- I'll not be editing the production site's files.  I will be editing (occassionally0 ON the production box, but in dev/staging checkouts; I'm thinking about a bzr-server centralized repo scenario, and checkouts,etc to numerous locations as required (e.g., home, laptop, remote, etc etc)
<bendj> Unrelated (mostly) question.  Can bzr be KDE (or would it be @filesystem) -integrated, so that the last N (say 10 ...) saved versions of a file are available?  E.g., doing image editing in a directory using GIMP, I could certainly do that if I checked out the file/directory first using bzr, then commit after edit.  But anything integrated as of yet?  I've seem such capabilities @ a Solaris demo once, but I think that was embodied in the ZFS file system.
<bendj> s/seem/seen/
<spiv> bendj: nothing integrated as yet, sadly
<spiv> bendj: it would be lovely to have, of course!
<spiv> bendj: I think it really would need to work at the app level rather than filesystem to work well, the filesystem just isn't given enough information to know reliably when a change has been fully written or if a replaced file is a new version of the old one or not.
<bendj> spiv found it! -> http://www.serverwatch.com/tutorials/article.php/3831881/Say-Cheese-OpenSolaris-Time-Slider.htm
<bendj> iirc, it's file-level restoration across numerous prior versions
<bendj> using ZFS' capabilities.  i.e. @ the filesystem level
<RAOF> Yeah; something similar will be possible with brtfs.
#bzr 2010-01-10
<RAOF> And there was that awesome GNOME Storage mockup + some code, which never went very far but would have been cool.
<bendj> So many options, so little time ...
<piotrekm> hi
<piotrekm> is it possible to make a bunlde revision only with selected files from the branch? I want to make a package of only the necessary things, ignoring the debug ones
<piotrekm> oh, i have misunderstood something. What I would like to know is whether it's possible to push the repository to a place where only selected files would be uploaded
<bob2> not really
<piotrekm> so it's not possible in any way to, say, automatically select files that will go to a package?
<fullermd> You conceptually could, but it wouldn't do you any good at the far end.  Bundles are just another way of moving revs from one place to another, they don't let you do anything you couldn't do with a branch.
<piotrekm> fullermd: i think what i need is something like a new branch with selected files, without even the ability of merging back or commiting new changes. What does that "conceptually" look in practice;> ?
<fullermd> To do that, you have to create new sets of revisions in some way.
<fullermd> Manually is one option.  There may be some capability in the 'rewrite' plugin that covers what you need.
<fullermd> Or you can bung up scripting around the CLI to recreate the bits you need, etc.
<piotrekm> thanks
<LpSolit> Can someone help me with unified_diff()?
<LpSolit> I don't get where fromfiledate and tofiledate are defined
<LpSolit> in diff.py, internal_diff() doesn't pass this information to unified_diff(), but the output has them anyway
<lifeless> I wonder if piotrem wanted 'export'
<Supertanker> Awww crap
<Supertanker> I just looked at git's manpage ofr fun
<Supertanker> And after working with bazaar, it actually made sense to me
<Supertanker> So now I don't know what to do :/
<Supertanker> My snobby sense of superioirty is gone.
<fullermd> Didn't you ever watch _Wheel of Fortune_?  bzr users are richer; you have to buy a vowel to spell 'git'.
<lifeless> fullermd: :P
<fullermd> I drew a blank; it was the best I could come up with on short notice   :p
<Supertanker> Hahahahaha
 * fullermd cries at having to type command lines that start with 'cvs'...
<Supertanker> Now now....
 * Supertanker comforts fullermd
<Supertanker> It'll all be over soon...
<Supertanker> WHEN BAZAAR TAKES OVER THE WOOOOOOORLD!@
<Supertanker> I mean, uh
 * Supertanker hides
<ronny> it wont
<Supertanker> Drat.
<fullermd> It doesn't have to take over the WHOLE world.  Just the bits that lead to me using CVS.
<ronny> cvs is best defeated with rcs+rsync
<spiv> fullermd: we give a better score in scrabble, too.
<lifeless> spiv: heh, nice.
<ronny> anyone here experiencd with subvertpy? i might end up with some weird questions in the next few hours
<piotrekm> hello
<piotrekm> can I init a repository in a directory that includes  already created branches?
<cyberix> All places talk about bzr-hg
<cyberix> how on earth is I supposed to know that means Mercurial
<cyberix> I had to dig all way to here
<cyberix> http://bazaar.launchpad.net/~bzr/bzr-hg/trunk/annotate/head:/README
<cyberix> before I found that out
<cyberix> :-P
<cyberix> I started at https://dev.launchpad.net/RoadMap
<EdWyse_Mobile> Because every geek is supposed to know that Hg is the periodic element Mercury. :D
<cyberix> shouldn't it be hgial then?
<cyberix> You know, if I was a native English speaker I would probably have figured that out
<cyberix> but I didn't even bother start thinking that the name might be related to some element
<cyberix> also this might have worked, if I had actually started with the revision control system
<cyberix> and tried to find bzr plugin for it
<cyberix> although I don't I would have googled with bzr-hg
<cyberix> googling with bzr mercurial probably would have worked
<Kr0ntab> Hey there, folks.  Have a question on bzr.  I find I am working on a local copy of a branch, make a change, commit to local, and submit a diff to an approver... then continue working on other docs in the branch...
<Kr0ntab> if I commit locally again... and create a diff... it conatins my previous changes as well...
<Kr0ntab> how do I handle these asynchronous changes/approvals?
<Kr0ntab> should I check out the same branch in different directories... make changes on each, so I can keep each major revision separate until the others are approved upstream?
<lifeless> Kr0ntab: you could use bzr-pipes, or bzr-loom, or multiple branches, if you're going to be making edits to each thing that the reviewer is looking at.
<lifeless> Kr0ntab: if you just want to be able to show the older revision, use diff -c -3 (or whatever)
<lifeless> and if you want a diff of just your latest commit, diff -c -1
<Kr0ntab> oh okay...
<Kr0ntab> lifeless, thanks...
<mwhudson> lifeless: is there a ppa with testtools in it?
<lifeless> yes
<lifeless> the subunit one and the bzr beta ppa
<lifeless> and the losa ppa
<lifeless> https://edge.launchpad.net/ubuntu/+source/python-testtools
<lifeless> lists them in fact
<lifeless> https://edge.launchpad.net/ubuntu/+ppas?name_filter=python-testtools
<lifeless> shame that the subunit ppa is below the fold
<lifeless> beuno: ^
<lifeless> mwhudson: ^
<mwhudson> lifeless: ah, thanks
<beuno> lifeless, hi. The Ubuntu Core Devs wanted to hide PPAs a bit so it wouldn't compete with the official packages
<lifeless> beuno: yes, I know that. I'm pointing out that the best PPA for testtools isn't listed unless you click the 'search others' link
<beuno> ah!
<beuno> interesting
<lifeless> beuno: compare the two pages.
<lifeless> gotta take lynne to the doc.. sms me if needed
<spiv> Morning.
<poolie> hello all
#bzr 2011-01-03
<daveb_> hey
<daveb_> has anyone done anything with inotify and bzr to have an automatic push system?
<glyph> daveb_: bzr already has automatic pushing, I think you mean automatic committing?
<thorwil> hi! i have one development branch and a packaging branch on lp. for the first rev of the packaging branch, the reference to the devel branch is clear.
<thorwil> but now, several devel revs later, easiest would be to copy the files i need to the packaging branch. but is there a way to associate the packaging rev with a devel rev, then?
<daveb_> glyph: yes, thats what i mean
<daveb_> has anyone done anything with inotify and bzr to have automatic commiting?
<mgedmin> I wonder if you could use SparkleShare for that (if you convinced it to use bzr as a backed instead of git)
<jam1> morning #bzr
* jam changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: jam | | 2.3b4 is officially out ! (rm vila)
<jam> hey vila, are you still around? Just wanted to say happy new year
<vila> jam: yeah ! Happy new year to you too !
<daveb_> mgedmin: would there be an advantage to using git?
<mgedmin> well, you could use unmodified sparkleshare, if you used git, I suppose
<mgedmin> but I don't know if it fits your usecase
<mgedmin> or if it's sufficiently functional in its current beta incarnation
<daveb_> well, i want the some of the advantages of a VCS, but I really want something that is so simple that people dont have to think about using it, maybe implemented in a filesystem or something... high availability (offline access) is importaint.   I was thinking of using some sort of wrapper for bzr, so that when ever anyone change something on their checkout, it would automatically commit it so it would be available...
<mgedmin> sounds like you're looking for something like Dropbox (or Ubuntu One)
<daveb_> mgedmin: we like dropbox, we just want to be able to host it
<daveb_> and, well, versioning would be nice
 * mgedmin nods
<mgedmin> sounds like SparkleShare is exactly that then
<mgedmin> if you're not allergic to c#/mono/git
<mgedmin> or software that's in beta
<daveb_> yea, thanks for pointing me to it
 * mgedmin is keeping an eye on it, but hasn't tried it yet
<daveb_> it looks promising
<daveb_> they say windows support is comming soon
<chx> i am running 2.3b4 and i tried bzr resolve --take-other modules/comment/comment.test but it says  Text conflict in modules/comment/comment.test
<vila> chx: I think it's part of the upcoming 2.3b5, let me check
<vila> chx: yup, 2.3b5
<vila> chx: I don't remember the details, but the behaviour in b4 is... blurry...
<vila> chx: but you can achieve the same effect with: cp c.t.OTHER c.t ; bzr resolve c.t
<chx> sure
<zyga> hi
<zyga> should bzr be installable via pip on win32?
<zyga> I installed visual studio express 2008
<zyga> but the install script fails on ValueError in distuitls msvc9compiler.py
<phil`> Anyone willing and able to help fix a messed-up install of bzr on debian?
<zyga> phil`, how did you install?
<phil`> sudo apt-get install bzr bzrtools
<phil`> Here's the output:
<phil`> The following packages have unmet dependencies:
<phil`>  bzr : Depends: python (< 2.6) but 2.6.6-3+squeeze4 is to be installed
<phil`>  
<phil`> Had it installed and working for years
<phil`> A while back, started getting 'packages held back' when doing apt-get update
<phil`> Decided today to uninstall and re-install, but no go, same 'unmet deps' msg
<phil`> AFAICT I have up-to-date python2.6 and python2.5 installed
<maxb> phil`: This would tend to suggest the bzr package being seen is not the correct one for your distribution
<maxb> Please pastebin your /etc/apt/sources.list
<maxb> also the output of 'apt-cache policy bzr'
<maxb> also say whether you have any files in /etc/apt/sources.list.d/
<phil`> newb: ?pastebin? (sorry)
<maxb> A website for sharing text more conveniently than long pastes directly in the channel
<maxb> e.g. http://paste.ubuntu.com
<phil`> Gotcha
<phil`> apt-cache policy: http://paste.ubuntu.com/549918/
<phil`> sources.list: http://paste.ubuntu.com/549921/
<phil`> sources.list.d is empty
<maxb> ah
<maxb> You seem to be using Ubuntu hardy packages on your Debian system
<phil`> D'oh
<maxb> For a Debian squeeze machine, I'd say you have a better chance using Ubuntu lucid packages thatn Ubuntu hardy
<phil`> Installing now! Thank you maxb, you're a hero.
<maxb> It's a shame we don't have a better solution for Debian, but setting up a buildd system isn't easy
<phil`> I hear that
<phil`> All good now!
<notmyname> now that I've been working on a project for a while, I've got lots of directories (including "trunk") in my parent directory (the one where I ran bzr init-repo). how can I tell which ones have been merged into trunk?
<beuno> notmyname, bzr missing ..//otherbranch
<beuno> that;s ../otherbranch
<beuno> or the path to it
<notmyname> so I go to "trunk", run "bzr missing /path/to/otherbranch" and what do I see if it's been merged (or hasn't been merged)? a nice message? nothing?
<beuno> if nothin is missing, then you get nothing
<beuno> id something is, it tells you which revisions
<maxb> You probably want 'bzr missing --mine-only ../trunk' or 'bzr missing --theirs-only ../otherbranch'
<notmyname> maxb: thanks. I was getting lots of output without those switches
<notmyname> beuno: maxb: thanks for the help
<glyph> so I'm reading the DaggyFixes page
<glyph> and I think I finally managed to understand it
<glyph> but there is a use-case it doesn't cover: what if I want to use a testing feature that was introduced some time after the bug was introduced in order to test the fix?
<jam> glyph: then you use a later version of the branch
<jam> the point of doing it early, is so it is easier to apply the fix in lots of scenarios
<jam> if you need new test infrastructure, then that no longer applies
<jam>   but it also clearly means that you won't be able to easily apply the new bugfix to old releases
<glyph> I guess the gist of daggyfixes is actually just 'fix it in the old branch first'
<jam> glyph: that is the basic idea
<jam> if that isn't practical
<jam> then do whatever makes the most sense
<jam> you also can layer the fix
<jam> using looms/etc
<jam> so you have a branch where you fix it
<jam> which then you merge into a newer branch that has the tests.
<jam> though that runs into "is it really fixed in the original branch? I don't have a test for it"
<glyph> jam: In this case, the question was really about test infrastructure introduced on the older branch, but after the fix
<glyph> so the answer is really 'okay, just start after the test infrastructure was introduced then'
<glyph> there's another class of question though, which is 'what if the project policy is always "fix on the new branch first, then backport fixes"'
<glyph> and there are a bunch of different formulations of that, but from what I can tell it's 'do a merge with a -r argument and then don't forget that you did that because if you do it again it will look awful and have tons of conflicts'
#bzr 2011-01-04
 * spiv winds up for the day
<poolie> hi there vila?
<vila> poolie: Hey !
<poolie> happy new year
<vila> hehe
<vila> Happy new year to all bzrastas (-ristas ?) :)
<jelmer> hi vila, poolie
<jelmer> happy new year :-)
<poolie> hi jelmer, happy new yera
<vila> heya jelmer !
<vila> jelmer: happy new year ! And a bzr-ish one for that matter ;D
<jelmer> thanks!
<poolie> jelmer, oh, i guess you're now officially on the bzr team? or from monday?
<jelmer> poolie: from Monday as far as I know
<poolie> k
<poolie> see you then
<poolie> ok i should really go
<poolie> good night
<jelmer> poolie: yep, see you in Dallas :-)
<jelmer> g'night
<hsn> how many memory bzr needs? entire repo in memory?
<hsn> i have 1G repo and bzr needs 1.3GB RAM
<hsn> 70k revisions
<voidspace> when will the RandomPool_DeprecationWarning be fixed in a released version of bzr?
<voidspace> can't you do an emergency release that silences the warning?
<voidspace> :-)
<vila> voidspace: afaik, it's silenced in stable releases, what os/bzr versions are you using ?
<voidspace> Mac OS X
<voidspace> bzr 2.3b4 installed with pip
<voidspace> Python 2.6
 * maxb points to the beta nature of that release
<vila> right, so neither a stable version nor an installer where we carry the relevant fix :)
<voidspace> maxb: and beta means using deprecated pycrypto code is ok
<voidspace> vila: what version is the fix in?
<voidspace> I upgrade using "pip install -U bzr"
<maxb> s/fix/suppression of warnings when running a production release/
<vila> voidspace: so to answer your initial question: we do release installers for stable bzr without this warning
<voidspace> vila: what version is the fix in?
<maxb> There is no fix
<voidspace> I will install that specific version with pip
<maxb> There is a suppression of warnings when running a production release
<vila> voidspace: the problem is not in bzr, it's in pycrypto iirc that is used by paramiko
<voidspace> what version should I use to not get the deprecation warning
<vila> none have been released
<maxb> Any actual (non-beta) release
<vila> hmm
<voidspace> hah...
<jelmer> voidspace: we submitted a fix for paramiko but it hasn't been merged yet
<voidspace> you could silence the warning from within bzr in the meantime
<voidspace> using the warnings module
<vila> jelmer: I think we aren't talking about the same issue and maxb is right ;)
<vila> voidspace: really ? care to submit a patch ?
<maxb> voidspace: We could and do, in *released* versions of bzr. But not in development versions.
<vila> voidspace: make sure we don't already do that for *released* versions though
<jelmer> vila: https://github.com/robey/paramiko/pull/8
<jelmer> is that a different one?
<vila> jelmer: oh no, you're damn right, I was thinking about *another* one you proposed upstream
<voidspace> ok, so I downgraded to 2.2.2 and don't see the warning - thanks very much
<voidspace> you still interested in a patch to silence the warning for the development version, or not needed?
<vila> voidspace: no, I was joking :) We want the warning while running dev and beta versions
<vila> voidspace: but what is pip ?
<voidspace> pip is pretty much the standard Python package installation tool within the Python community
<maxb> Why did pip install 2.3b4 when our PyPI record says 2.2.2?
<voidspace> it installs packages from PyPI
<voidspace> and "pip install -U package" gets you the latest released version of any package
 * vila bangs head
<vila> why did it pick 2.3b4 dang it !
<voidspace> I'm just checking what happens if I install bzr into a virtualenv with pip
<voidspace> seeing what version it gets
<voidspace> if I go to the PyPI page I see 2.2.2 as the latest version
<vila> ha, we had ronny running into troubles with virtualenv last time,
<voidspace> but you don't have a package for download on PyPI itself - so it maybe scraping download pages to find the latest version
<vila> which prompted me to update the pypi page in a way that I thought address his problems
<voidspace> right - so if I create a virtualenv and then just do a straight "pip install bzr" it gets 2.3b4
<vila> bummer
<voidspace> hosting python packages on pypi may be the best way to solve it
<voidspace> python setup.py sdist upload
<voidspace> maybe...
<vila> I did try that iirc but there was some trouble with generated C files (we require pyrex but don't support all versions)
<voidspace> ah, right
<voidspace> ouch
<voidspace> it maybe worth complaining to the pip guys
<vila> if you know a way to fix that... then a patch will be welcome :)
<voidspace> the pyrex issue? I've never worked with pyrex I'm afraid
<voidspace> although using distribute / setuptools will allow you to optionally express build dependencies (including versions) in the setup.py
<voidspace> I believe
<voidspace> by optionally I mean you can make the use of distribute / setuptools optional within your setup.py
<vila> yeah, it may well be a bug in our setup.py
<vila> out of curiosity, why didn't you use the osx installers ? And do you get the extensions built correctly with pip ?
<voidspace> vila: sorry - had issues with my irc client
<voidspace> vila: I use pip to manage my Python packages on OS X
<voidspace> vila: it seems to work fine, so it never occurred to me to *look* for OS X installers
<vila> make sense
<voidspace> easy_install *also* installs 2.3b4
<vila> voidspace: no warnings about extensions then ?
<voidspace> they scrape html to find the most recent release (if packages aren't available for download from pypi): http://paste.pocoo.org/show/314715/
<vila> probably the same root cause
<voidspace> vila: it seems to compile them, I can show you the output
<voidspace> vila: full output of pip install bzr
<voidspace> http://paste.pocoo.org/show/314716/
<vila> voidspace: a better test would be to run 'bzr selftest', be aware it can take some time though (and may be start with 'bzr selftest --no-plugins', just in case)
<jelmer> voidspace: btw, while you're here..
<voidspace> ok, I'll need to install the test dependencies then
<voidspace> jelmer: yes
<jelmer> voidspace: I noticed "python2.7 -m unittest" works while "python2.6 -m unittest2" doesn't (it seems I need python2.6 -m unittest.__main__). Is that intentional?
<jelmer> ehm, unittest2.__main__ that is
<voidspace> jelmer: the ability to execute a *package* with "-m" is new in 2.7
<voidspace> jelmer: so yes, you could say it is intentional
<voidspace> jelmer: that is why there is a unit2 script
<jelmer> voidspace: ah, previously it was only possible to execute modules ?
<voidspace> jelmer: correct
<jelmer> voidspace: ok, just checking. Thanks!
<vila> voidspace: no pyrex trying cython... wow, this should work ok and dodge the pyrex compat issue
<voidspace> vila: running selftest without plugins, 1 failure so far - I'll provide output on completion
<vila> voidspace: thanks !
<vila> voidspace: and what osx version ?
<voidspace> vila: 10.6
<vila> ok, cool
<voidspace> Python 2.6
<voidspace> I can try with alternative versions of Python too if it is useful
<vila> yup, I saw 2.6 mentioned earlier
<vila> voidspace: not yet, we're ironing out the last problems in 2.7 on natty for now
<voidspace> ok
<vila> so, apart from picking the "wrong" version pip output seems perfect to me
<voidspace> right
<vila> I had a patch for for the MIN/MAX warning but it get lost
<voidspace> using 2.3b4 was working fine for me apart from the damn DeprecationWarning :-)
<vila> now, for the "wrong" version, *our* intent (as in the bzr project) is to guide people to the stable releases first
<voidspace> I do most of my work with bzr from inside Ubuntu though
<voidspace> vila: yeah - understood
<vila> but let them try the betas at will
<voidspace> vila: it is because pip and easy_install scrape your download pages
<vila> that's why the pypi page mention both links... errr wait
<vila> they scrape which page exactly ?
<voidspace> vila: yeah, I wonder if your release package is "badly" named
<vila> on pypi ?
<voidspace> vila: the url - yeah
<voidspace> vila: you may be able to put a hint in the url (a # fragment) that informs pip / easy_install that is the version it should use
<voidspace> vila: let me see if carljm in #pip has an idea about this
<vila> voidspace: that would be awesome !
<voidspace> vila: ok, so the following for easy_install and *may* work for pip too
<voidspace> vila: from: http://peak.telecommunity.com/DevCenter/setuptools#making-your-package-available-for-easyinstall
<voidspace> vila: in pypi add #egg=bzr to the download url
<voidspace> vila: worth a try anyway :-)
<vila> I've updated the pypi page with #egg=bzr, can you re-try ?
<voidspace> yep
<vila> voidspace: that is, I didn't upload a tarball, only modified the url
<voidspace> vila: understood, that's what I was suggesting
<vila> ok, no cache to care about for pip ?
<vila> . o O (If it works *that* would be quite an easter egg...)
<voidspace> vila: nah, looks like easy_install *still* scrapes the html in preference to using the download url
<voidspace> vila: *sigh*
<voidspace> vila: that # fragment trick is only for when your download urls don't point to a standard project-version.tgz format, which yours do already
<voidspace> vila: so my mistake, sorry
<vila> voidspace: no problem, was worth a try
<voidspace> vila: just for your info, the page that pip & easy_install are scraping and looking for "the most recent version" on is: https://launchpad.net/bzr/+download
<voidspace> vila: not sure there is anything you can do about that
<voidspace> now we have pep 386 defining version schemes it should be possible for pip to switch to most recent *stable* version unless you explicitly tell it you want betas
<voidspace> which would be nice
<voidspace> but hasn't happened yet
<vila> hmm, interesting
<vila> but where did it get this page...
<voidspace> 17000 / 24000 tests run...
<voidspace> from this one: http://wiki.bazaar.canonical.com/SourceDownloads#Source%20Downloads
<voidspace> which it got from this one: http://wiki.bazaar.canonical.com/Download/
<vila> shudder
<voidspace> and that one is the one you link to...
<vila> yup
<vila> but there is a download url right in the pypi page....
<vila> probably they do that to catch up with people not updating the page ?
<voidspace> not sure
<voidspace> they don't pay any special attention to the download_url at all it seems
<vila> bah, and all of that is from 'setup.py register' so even modifying the page will be good only for small tests like we did
<vila> but good nough to understand, thanks for the hints voidspace
<vila> enough, ha, first typo of the year :)
<vila> 4 days !
<voidspace> that's pretty good
<voidspace> I usually make several a day
<voidspace> heck, several an hour
<vila> voidspace: if the download_url is a "primary url" then pip should give it some preference or ... nah, won't fly, may not be the most recent one
<vila> voidspace: so, we're back to square one for your annoying warning :)
<vila> voidspace: knowing that we won't change our policy for betas, what is acceptable as workarounds for you ?
<voidspace> bzr selftest output ready
<voidspace> from inside a Python 2.6 virtualenv
<voidspace> http://paste.pocoo.org/show/314738/
<vila> voidspace: the relevant code is in bzrlib/library_state.py line 73
<voidspace> spoiler alert: FAILED (failures=10, known_failure_count=74)
<voidspace> vila: well, I've solved my particular problem by switching back to stable
<voidspace> vila: although given that you *intend* for betas to be *tried* by end users (is this the case?) I would expect them to be free of DeprecationWarnings
<voidspace> vila: but solving the general case, so that "ordinary users" get the latest stable from pip / easy_install rather than the beta seems to be harder
<voidspace> vila: but I'm sure not insolvable
<voidspace> vila: I will ruminate 'pon the topic
<vila> voidspace: well, we expect them to understand they can encounter rough edges while running betas, yes
<voidspace> vila: hmm... according to carljm pip *is* trying the download_url first but gets a 404 and then resorts to scraping
<voidspace> vila: see http://paste.pocoo.org/show/314737/
<vila> voidspace: for the selftest result, only 10 failures is pretty good, knowing that I never heard about running the tests under virtualenv
<voidspace> vila: but obviously the download url *isn't* a 404
<voidspace> vila: hah, cool
<voidspace> vila: so something weird is going on
<vila> voidspace: a 404 or a 30x (redirect) ?
<voidspace> vila: pip seems convinced it is getting a 404
<voidspace> it's possible it "casts" all non-200 codes to 404, but most python web client libraries follow redirects transparently, so it shouldn't even see the redirect
<vila> not from here, but it's a redirect
<vila> hmm
<vila> could be a launchpad bug
<voidspace> well - I can fetch that url from urllib2 or wget fine
<voidspace> so I don't think so
<vila> that's worth investigating, but try for yourself with a browser
<voidspace> I have :-)
<vila> sorry, msgs cross on the wire :)
<voidspace> haha
<voidspace> brb
<vila> voidspace: well, if you can with urllib2 and pip can't...
<vila> voidspace: ok, you're smarter than pip, but still :)
<voidspace> yeah, it may just be reporting the redirect as a 404 rather than following the damn redirect
<voidspace> which would be unreasonably dumb
<vila> but now that you mentioned it, I think ronny was having the same problem... pip not following the redirects
<vila> or was it easy_install, or a shared "feature" ;)
<voidspace> vila: do you want me to run `bzr selftest` outside of a virtualenv by the way?
<voidspace> vila: to see if any of the failures are caused by the virtualenv or are general to Mac OS X
<vila> voidspace: there is http://babune.ladeuil.net:24842/, so I know the status on osx for 10.5 and 10.6 so far
<voidspace> ok
<voidspace> I could try it under virtualenv on ubuntu
<voidspace> that may just be creating work for you though... :-)
<vila> hehe, fixing failing tests is the true path to avoid bugs :)
<vila> voidspace: re-reading the test failures, I'd say, some of them I've already seen, so probably fixed in 2.3b*5*, some others are weird (no nodename, blah blah) and may be due to virtualenv doing strange things with the network stack ?
<voidspace> virtualenv shouldn't affect the network stack in any way
<voidspace> trying on ubuntu
<vila> voidspace: in any case, you've already been very helpful, but if you can reproduce the same failures on Ubuntu and virtualenv, filing a bug may help us track the issue
<voidspace> ok - selftest is now running on Ubuntu under virtualenv
<vila> voidspace: I haven't used virtualenv myself and won't be able to try in the coming weeks but I'll subscribe to such a bug
<voidspace> ok
<voidspace> for python development virtualenv is awesome :-)
<vila> voidspace: python itself you mean ?
 * mgedmin grumbles about '/tmp/sandbox/bin/pip install bzr' finding a ./bzr directory -- where I keep my repos -- and deciding it should use that instead of looking up a 'bzr' package on pypi
<voidspace> vila: no, I mean for developing *with* python
<voidspace> vila: buildout is good too, but more work to use
<voidspace> vila: but buildout recipes are more powerful
<voidspace> vila: virtualenv allows you to create isolated (repeatable) sandboxed installs of Python and sets of dependencies
<voidspace> vila: which you can blow away by just deleting
<voidspace> vila: so you can work on stuff without installing system wide - and can easily install different (incompatible) sets of dependencies into different virtualenvs
<vila> oh right, well, I use virtual machines for that :) But I also need to test verious OSes so, different problem ;) But yeah, even if I don't have such need today, I see the point
<voidspace> right
<voidspace> vila: many less failures on ubuntu under virtualenv, so it looks like the other failures are OS X related
<voidspace> vila: or specific to my system...
<voidspace> vila: http://paste.pocoo.org/show/314762/
<voidspace> vila: do you want me to report a bug here?
<vila> hmm, these are totally different failures, and probably fixed too
<vila> if you want to report a bug, do it for the osx failures instead
<voidspace> ok
<voidspace> I'll do that  - at least they are on launchpad then
<vila> yup, we could de-dupe them if needed
<vila> voidspace: if there is a simple recipe to use virtualenv and reproduce the problem, you'll get bonus points ;D
<voidspace> haha
<voidspace> they'll have to be OS X instructions - running under Ubuntu doesn't reproduce the bugs
<voidspace> so not sure how useful they would be to you anyway...
<Buttons840> i would like to see only what files have changed instead of a full diff?
<voidspace> bzr st
<Buttons840> sorry, i wasn't clear; i want to see all the files that have changed since revision 1 and i'm on revision 22
<Buttons840> perhaps status can still be used?  i'm looking at the breif option of diff right now though
<Buttons840> status -r1    no so difficult i guess; thanks
<mathrick> hey, bzr-svn doesn't build in daily ppa, fails some tests
<mathrick> that does bad things to the deps, since stable bzr-svn hates the idea of having bzr >2.2
<maxb> Interesting. And weird.
<maxb> Might be something as simple as the tests never having been run in a non-UTF8 locale :-/
<mathrick> quite possible
<mathrick> non-UTF-8 locales are an abomination unto Lord and man alike
<abadger1999> No jam :-(
 * abadger1999 replies via email even though it's just for clarification now.
<poolie> hi abadger1999
<abadger1999> poolie: Hi
<poolie> this is about using 2.5 or 2.6?
<abadger1999> poolie: 2.4 actually -- I care about 2.4, 2.6, and 2.7 atm.
<abadger1999> (RHEL5, RHEL6, and Fedora)
<poolie> rhel5 is python2.4
<poolie> ?
<abadger1999> Correct
<poolie> for how long do you think that will remain relevant?
<poolie> years more?
<abadger1999> 3 years, 3 months to go until EOL :-(
<abadger1999> relevancy is hard to guage -- RHEL6 only just came out.
<abadger1999> It usually takes several years before a new release makes it so that we can tell people "Can't you just upgrade that server/computer lab/etc to a newer version"
<abadger1999> and have them sheepsihly say, yeah, I need to do that.
<poolie> right
<abadger1999> Note: I'm not the maintainer of bzr in RHEL6 (bzr made it into RHEL6 itself!  Yay!) , I'm just maintaining it in EPEL for RHEL5  and comaintaining it in EPEL.
<abadger1999> Err Fedora
<poolie> great
#bzr 2011-01-05
<mkanat> poolie: Guessing based on RHEL4 -> RHEL5, I'd guess that RHEL5 will stay relevant for about a year and a half.
<poolie> hi there
<poolie> ok
<poolie> iow roughly the same timeline, or perhaps a bit later than we may need to support 3.x
<mkanat> poolie: Yeah, and RHEL6 has 2.6.5.
<mkanat> poolie: So, I imagine you're still catching up from vacation and all. Will you be able to take a look at the loggerhead work at any point?
<poolie> oh, hi
<poolie> wow, nine reviews
<poolie> mkanat, you should ask jam too, as he's patch pilot this week
<mkanat> poolie: Okay.
<poolie> hi spiv!
<spiv> Hi :)
<poolie> welcome back
<mkanat> poolie: The specific review that I'm waiting on is https://code.launchpad.net/~mkanat/loggerhead/raw-prefix/+merge/44682
<poolie> yeah, just reading it
<mkanat> poolie: Okay. :-)
<poolie> to be precise, i'm just asking for a second review from someone who's handled this issue elsewhere
<poolie> it looks good to me
<mkanat> poolie: Okay.
<mkanat> poolie: I've also handle this issue elsewhere, FWIW.
<mkanat> *handled
<mkanat> poolie: How does authentication work for loggerhead for private branches on launchpad, do you know?
<mkanat> poolie: The LP version of this may need some special magic.
<poolie> i know you're familiar with it
<poolie> s/it/xss elsewhere
<poolie> i don't know much about how it works in detail
<mkanat> Not just XSS, but almost this specific issue, of serving untrusted content.
<poolie> we had a big internal thread about xss in general, so i just thought i'd let those people comment if they want to
<mkanat> Okay. :-)
<poolie> you're right it may need to be updated if this is deployed
<poolie> mkanat, i replied
<poolie> can i help with anything else?
<mkanat> poolie: Awesome, thanks. That should be it for now.
<lifeless> mkanat: private branches have oauth triggered
<mkanat> lifeless: All right. And how is that persisted?
<lifeless> mkanat: well, not oauth, but auth in general
<mkanat> lifeless: Like HTTP Auth?
<lifeless> mkanat: cookies. It seems to be pretty bustified just now.
<mkanat> lifeless: Okay.
<mkanat> We'll have to do something special for that, then.
<lifeless> I'd just use the timelimitedtoken table
<lifeless> its meant to be pretty generic
<mkanat> Is that in LP?
<lifeless> yes
<mkanat> Okay. Yeah, that's what I'd use. I don't think codebrowse has access to that, though, no? Or I'd just get one via the API?
<lifeless> the way it works is this:
<lifeless>  - we advertise a url on the appservers
<lifeless>  - requests to said url:
<lifeless>     - add a token
<poolie> lifeless, do you mean you give a positive or a negative value to the manual "feed to pqm" step?
<lifeless>     - generate a redirect to the content-domain with the token as a query parameter
<lifeless> poolie: manually feeding allows user control and approval-before-landing.
<poolie> because you can say status=approved, comment='approved conditional on fixing X'?
<lifeless> mkanat: the 'content-domain' is a wild-card domain so that no user supplied content can attack each other or lp cookies.
<lifeless> poolie: yes
<poolie> is that any better than saying status=needreview, vote=approved, comment='ok to land when you do x'?
<lifeless> poolie: yes, in several ways
<lifeless> poolie: firstly the approver is the reviewer not the lander; secondly the mp gets out of the to-review queue.
<mkanat> lifeless: But loggerhead is not a part of launchpad, so I'm not quite sure what you're advising me to do.
<lifeless> mkanat: the one deployed at bazaar.launchpad.net is
<lifeless> mkanat: its an appserver in the general sense
<mkanat> lifeless: Okay.
<mkanat> lifeless: And so it can use the LP APIs and so forth and generate a token?
<lifeless> we may need more api glue etc to let loggerhead issue a token, but thats doable.
<mkanat> lifeless: Okay. I've already got the domain system in place in loggerhead itself.
<mkanat> lifeless: I just need to check and validate a token for private branches.
<lifeless> mkanat: so each branch gets its own domain ?
<mkanat> lifeless: Yeah.
<lifeless> kk
<poolie> so, getting it out of the queue, if you want, is equally well accomplished by setting it to wip
<poolie> i don't see how the identity of the approver makes the process less blocking
<lifeless> you asked how it was better
<poolie> is this better?
<poolie> on the one hand you have
<poolie> A says "I'm marking the approved (but not really approved)"
<lifeless> thats not what I'm saying
<poolie> and in the other case, B says "I'm marking this approved because A said it was ok when I did X and I've now done it"
<lifeless> I'm saying 'approved but consider X or Y'
<lifeless> which is approved
<lifeless> but maybe not time to land it
<poolie> ah, so not conditionally approved, but
<poolie> approved, with comments
<mkanat> lifeless: Where in the API would I look to generate myself a token?
<lifeless> mkanat: tokens aren't exposed in the API yet
<lifeless> mkanat: this is the glue needed that I mentioned
<mkanat> lifeless: Ahh, okay.
<lifeless> would you care to file a bug requesting the ability to hand out tokens ?
<spiv> poolie: marking as vote: approve, status: WIP also tends to hide a branch, whereas currently +activereviews gives a fairly good indication of branches that are close to landing.
<mkanat> lifeless: Sure.
<lifeless> mkanat: thanks!
<poolie> spiv, true, but...
<spiv> I think that's more an issue with Launchpad than PQM vs. Tarmac though.
<poolie> i think the ui is just lacking a bucket for "needs piloting, not review per se"
<poolie> right
<lifeless> I think it would be nice for a reviewer to be able to land something trivially
<lifeless> I don't like the idea of being unable to clearly say 'this is ok now' without causing it to land.
<poolie> agree on both points
<lifeless> landing, like deploying, is something I think human action on adds value
<poolie> and vote=approve, status=unchanged doesn't quite feel like it captures the second
<mkanat> lifeless: https://bugs.launchpad.net/launchpad/+bug/697485
<poolie> it's close, but there's a distinction between "my opinion is this is ok" and "i'm concluding the discussion: this is ok"
<poolie> istm the real fix for that is either adding a 'queued' state, or a 'merge' button
<poolie> and/or perhaps revisiting the relation between votes and states
<lifeless> the queued state has been ripped out
<lifeless> a new implementation is ticking along slowly AIUI
<poolie> right
<poolie> i think going to tarmac is a step towards this?
<poolie> for example, it would make it more rewarding for me, or spiv, or whoever, to add a queue db and ui to launchpad
<lifeless> I think putting the new implementation in is a step torwards having tarmac
<lifeless> anyhow, I was simply expressing an opinion
<lifeless> I doubt I'll be landing anything in bzr in the short term
<poolie> i'm glad you read it
<poolie> and i appreciate your opinion
<spiv> Is it easy to teach tarmac to look for a comment saying "tarmac: ok" or something, not just checking the status?  That might work around the conflation of status==approved and "robot should merge it" that lifeless is talking about.
<lifeless> there are plugins to do that AIUI
<lifeless> that sort of thing anyhow
<lifeless> mkanat: I've triaged it to high
<mkanat> lifeless: Awesome, thank you.
<lifeless> mkanat: in the new work structure we'll have two teams working on high bugs, it will get got to within a year :(
<mkanat> lifeless: Hahaha, wow, okay.
<lifeless> we have a massive backlog we're trying to sort out
<mkanat> poolie: That will limit the rollout of /raw/ on LP ^^^^^^^^^^^^^^
<lifeless> there are a few options
<mkanat> I could just deny access to /raw/ on private branches until it's ready.
<lifeless> if there are stakeholder requests for this, we can make it semi-first-among-equals
<lifeless> mkanat could do the patch to lp
<lifeless> we can let the teams know its there and see if anyone cherry picks it as an interesting thing within the high bucket.
<mkanat> lifeless: I'd be happy to write the patch, but that would revolve around contracting emails.
<mkanat> *details
<mkanat> (Not emails.)
<lifeless> yeah
<lifeless> I realise that
<lifeless> what I've done is all I can sensibly within our current constraints
<mkanat> lifeless: Yeah, I know. :-) I appreciate it. :-)
<mathrick> btw, has anyone in position to fix it noticed the saily PPA build failures with bzr-svn?
<mathrick> *daily
<poolie> mkanat, i guess if you just merge all your stuff to one branch suitable for use on lp that would be good for now
<mkanat> poolie: Okay.
<vila> hi all !
 * fullermd waves at vila.
<vila> _o/
<fullermd> Seems like a year has passed since last I saw you around   ;p
<poolie> hi vila
<poolie> i'm going now though
<vila> poolie: take care !
<vila> fullermd: same here, on the other hand, that's one less before we can just relax and enjoy the show :D
<vila> . o O (Nothing beats black humor to start the day... )
<fullermd> Wait.  There's going to be a time when we can relax?
<vila> hmm, I hope "black humor" has the same meaning in English than in French...
<vila> Oh yes we can ! Bugs can't affect ghosts :)
<fullermd> I'm saddened at your lack of imagination   :(
<fullermd> I KNOW my clients would never let a little thing like my death stop them from hounding me.
<fullermd> Or their death, for that matter.  I took out a good half dozen before I realized how futile it was...
<vila> nah, you got it all wrong, ghosts CAN trigger bugs, it only works one way... Think about the potential for fun..
<fullermd> Oh, I know; we already have a bunch of those files I think  :p
<fullermd> And filed, too.
<vila> see ?
<vila> :D
<vila> Now think about looking at those poor souls running in circles searching for a way to reproduce these oh-so-funny bugs :)
<vila> decades of fun !
<vila> not mentioning leaks (of all kinds :)
<fullermd> But you can't even let anybody know.  Launchpad logins don't work from the afterlife.  You'll have to file a bug about tha.... crud.
<vila> really ? I thought 'ether' in ethernet was afterlife related...
<vila> Otherwise, I'm sure that with all these new wireless protocols...
<fullermd> I think it means that trying to debug problems in ethernet makes you drowsy.
<vila> right, this just means the latency increases, shouldn't be too hard to address
<fullermd> Heaven has too many dropped packets, and hell has hellacious latency.
<vila> tsk, heaven, you're sooo optimisitic...
<fullermd> What, with this angelic face?  Where else would I end up?
<vila> ;)
<fullermd> Alrighty, I just blew an hour sorting video clips.  Must be time for bed.
<vila> bed ?
<fullermd> Yeah, it's this thing that's sorta like sitting in front of the computer, except with less fans and more horizontality.
<xanalogica> sleep is a poor substitute for caffeine.
<matkor> Hi ! How can I resolve this:   Conflict adding file foo.OTHER.  Moved existing file to foo.OTHER.moved.
<matkor> I just want current version of foo to be commited.
<matkor> bzr resolve foo gives: foo is not conflicted
<matkor> argh
<quicksilver> bzr rm foo.OTHER.moved
<quicksilver> bzr resolve foo.OTHER.moved
<quicksilver> but having .OTHER files hanging around sounds broken to me
<quicksilver> sounds like someone accidentally added some conflict files
<vila> matkor: quicksilver is right, you were already in trouble with foo.OTHER already present (that's the one in conflict now by the way, not foo, foo *was* in conflict somehow in the past)
<matkor> quicksilver, vila. Ah great thanks.
<bialix> heya
 * bialix looking for jam
<bialix> who can help me with lp:bzr-merge-into plugin?
<bialix> it refuses to work for me
<maxb> Isn't that the one which was never updated to work with 2a?
<bialix> I'm using pre-2a formats
<bialix> but maybe it does not work with new bzr
<bialix> maxb: thanks
<bialix> it's not big deal to do everything manually
<catphish> g'day
<psusi> one thing that annoys me about bzr is that when you look at a merge commit, it shows a bunch of modifications as if you did them, instead of them coming in because of the merge.  Is there a way to fix that?
<maxb> It's not clear what you mean. To me, the fact that the commit is a merge commit fully explains that the changes it introduced involved a merge
<rjek> It documents who did the merge, and no information about the constituant changes is lost.  I see no problem.
<glyph> psusi: Yeah, I can't see what you mean by that either.  It definitely does not look like "you did them"; there are fields in the metadata for each revision describing the author and committer, and you can look to see who did the changes.
<psusi> glyph: see http://bazaar.launchpad.net/~psusi/ubuntu/natty/e2fsprogs/merge/revision/45
<psusi> it shows files added, removed, and modified
<psusi> but I didn't touch them
<psusi> the only file I touched was debian/changelog
<maxb> psusi: But, you performed a merge which caused all those files to be modified in that branch
<psusi> sure, but I did not modify them in that commit
<maxb> That's a very fine semantic difference, which starts to break down as soon as any amount of intra-file merging occurs
<psusi> git understands the difference and the diff only shows parts you had to modify to complete the merge... the fact that the upstream branch modified a bunch of files is covered by the commits in the upstream branch history, not by the merge commit
<maxb> How do you ask git for such a diff?
<psusi> git log -p or --stat
<psusi> only any parts YOU actually changed are shown... changes pulled in by the merge are not... which makes sense since they are already documented in other commits
<glyph> There's something to be said for that
<glyph> my understanding is that git immediately commits the merge, conflict markers and all
<glyph> and then you effectively have to merge again once you've sorted out the mess
<psusi> no... you commit once you have sorted out any conflicts
<jamey_uk> My boss is thinking of switching us from svn to git, but I think git looks overly-complex (no experience with it yet). I like bzr; would git be a pain and is bzr a lot less hassle?
<glyph> jamey_uk: _I_ think so :)
<psusi> but if there were no conflicts, then the log shows no files modified, and the diff is empty
<glyph> jamey_uk: #git might have a different idea
<jamey_uk> yeah, going to have to ask in there in a second :)
<glyph> psusi: sounds like an interesting feature.  bzr could probably have a logging mode where it did that by examining diffs.
<psusi> jamey_uk: bzr seems to aim more at being user friendly/easier to understand... I've been using both lately and for the most part, find them equivalent... but there's a few things, like this issue, that I prefer about git
<jamey_uk> why is it better that it commits immediately in this case?
<psusi> the other day I was very thrilled with git because I found a commit in linus's kernel tree and was describing to an ubuntu developer that it obsoletes a patch they had been carrying.  Within seconds I was able to point him to the commit so he could review it, and ask git to verify what upstream release it made it into, and that it was present in the Ubuntu tree
<psusi> jamey_uk: it doesn't... what I like better about merges in git is that it doesn't make all of the ( possibly hundreds ) of changes you are merging appear to be one massive patch applied by the merge
<jamey_uk> well, merging is a new concept for me to be honest... so this is going slightly above my head
<jamey_uk> so when you do a large merge with bzr it does it all as one patch, and git does lots of small patches?
<mgz> no.
<mgz> what psusi is on about sounds like a ui nitpick to me, unless what glyph said is right (which it may be)
<mgz> merging in any dvcs is a way of preserving the individual changes in another branch without flattening them into one big patch
<jamey_uk> I'm trying to join #git to get opinion from the other side but FreeNode is telling me: "#git :Cannot join channel (+r) - you need to be identified with services". Yet I registered recently and I am identified :/
<mgz> jamey_uk: any luck yet? try #freenode if not.
<jamey_uk> mgz, yeah no luck, going to ask in #freenode now, thanks
<maxb> psusi: I don't suppose you know *how* git calculates what to display in that case? I'm having trouble thinking of any way it can separate the two concepts without an intermediate commit.
<mgz> well, I guess that's at least one thing bzr has going for it. "Can join IRC channel"
<jamey_uk> :D
<mgz> jamey_uk: quite a few people actually use bzr clients against svn servers at their work, so there's a fair bit on experience on the mailing list about that.
<mgz> it's a way to get your feet wet without doing a big switch.
<mgz> but starting with a new little project is probably better for actually learning stuff like developing in feature branches and more distributed workflows.
<jamey_uk> yeah I'm thinking of converting our repo to bzr, playing around with making a new feature and such. Although, #git just pointed me to http://whygitisbetterthanx.com/ and the 'cheap local branching' does look good, I'm trying to thoroughly understand the difference. Seems to me just to be bzr branches into a new directory, which is a clone of the original branch, whereas git keeps it as one directory. Is this correct?
<maxb> bzr-svn is pretty amazing, but can get awfully slow if used against one-repository-for-the-entire-company's-code svn repositories.
<maxb> Also, bzr-svn's representation of files being moved or renamed in svn is rather suboptimal
<maxb> By which I mean if you try to merge such changes, it's pain and mess
<jamey_uk> why would one use bzr-svn? to get used to bzr's commands whilst still using the same svn repos?
<maxb> To get some of the benefits of bzr before the entire team will switch
<maxb> Also to actually do a conversion
<jamey_uk> ah right
<glyph> jamey_uk: bzr can do cheap local branching too
<maxb> The thing about git's "Cheap local branching" is that git makes it particularly easy to manage multiple branches within a single repository and working tree
<jamey_uk> ah really? I was just told it's a lot more painful when doing lots of branching
<maxb> bzr can do much the same, but it's not quite as elegant
<glyph> jamey_uk: it's just that bzr starts with a default model which is easy to understand and lets you optimize it once you understand what's going on, whereas git starts with a model that's a mess and hard to understand but super fast
<jamey_uk> ah, akin to *nix versus osx
<jamey_uk> in a sense
<glyph> jamey_uk: 'bzr init-repo --no-trees .'
<glyph> then bzr will put all of the revisions into a bucket in '.'
<maxb> "Cheap local branching" workflows are possible with bzr, either by setting up a bzr repository, branches, and checkout manually, or by using the bzr-colo plugin for helpful UI additions
<glyph> and you can make hundreds of little branches, which are all directories, without copying the whole history
<jamey_uk> ahh, when I fired up bzr-explorer the main thing I didn't understand was when I was creating a new repo, I couldn't get my head around what the different types of repo actually meant
<mgz> I still prefer the shared repo approach, which performs well and is hard to screw up with, it's only when you get something the size of the kernel you can't use that any more.
<jamey_uk> I guess I just don't fully understand the concepts for bzr repos
<mgz> actually having a seperate dir for each branch means it's clear what a branch is and where you're working.
<jamey_uk> yeah I quite like that aspect
<glyph> mgz: why doesn't that work?
<jamey_uk> if I convince my boss for us to try-and-then-switch to bzr, do you think there'll be things he'd complain about that git does better?
<glyph> mgz: with somethign the size of the kernel, I mean
<maxb> One day, bzr will have true git-like branching. It's been hypothesized for a long time
<jamey_uk> some context: small web dev team, main repo has ~5000 commit history, 3 people working and frequently need to branch the code but currently don't bother (too much of a headache)
<maxb> jamey_uk: The one thing that git has that bzr can't touch is speed. git is blazingly fast. bzr is "usually fast enough"
<maxb> Of course, git is also heinously confusing unless you study its philosophy, whereas bzr is quite friendly :-)
<jamey_uk> ah, that might be what sways my boss. what about web-based tools for browsing bzr vs git repos? it's not that important, but something we're interested in having
<mgz> glyph: mostly because having more than one working tree blows the cache, though also people like not having to do full recompiles when switching branches in the same dir.
<maxb> That's the main trade-off as I see it
<jamey_uk> yeah, it's the 'heinously confusing' aspect of git that makes me want to shove it away with at ten-foot pole and run into the loving arms of bzr
<mgz> glyph: there's precisely one project I have on my dir where any of that actually applies, but people make choices based on what the big boys do.
<maxb> jamey_uk: http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/changes <-- this is the Bazaar web viewer. It's called Loggerhead
<mgz> for something the size jamey is talking about, none of this really matters, git or a single on-disk tree wouldn't be a useful speed increase.
<jamey_uk> so I wouldn't really notice a difference in speed between the two doing regular commit, push, pull stuff? the repo's probably less than a few hundred meg
<maxb> I reckon you could notice the difference, but it wouldn't be sufficiently great to cause concern
<jamey_uk> what are the equivalents to gitorious for bzr?
<maxb> uh, remind me what gitorious is?
<maxb> :-)
<mgz> having some big binary things versioned might make a difference on spinning rust, having to create megabytes of jpegs can take a little time.
<jamey_uk> it looks like a nice hosting/backup solution for git repos
<jamey_uk> mgz, spinning rust?
<mgz> disk, sorry.
<jamey_uk> heh
<mgz> generally, you can just push a bzr repo to your server, and use whatever normal file backup mechanism you have.
<maxb> I would have to say that Bazaar lacks anything similar to Gitorious
<maxb> These questions are ones I'm confronting trying to introduce Bazaar at my organization too
<mgz> if you want third party hosted things, there are some options but fancy bzr access (or fancy git access) for commercial will generally mean paying someone.
<maxb> I specifically don't want a hosted solution.
<mgz> launchpad provides a similar offer to git hosting sites.
<maxb> Unfortunately it fails to provide a self-deployable offering
<mgz> can you download the github infra?
<mathrick> jamey_uk: spinning rust is magnetic, rotating media (ie. HD), with all their poor access time characteristics, as opposed to SSD and other truly random access solutions
<maxb> To be an ideal solution for me, Bazaar really needs what would essentially be the Launchpad Code feature extracted into a standalone deployable
<jamey_uk> yeah, that would be very useful
<jamey_uk> thanks very much for your help, I'm still undecided so might just try out both
<mgz> is that mostly the web front end?
<mgz> or does it include other things maxb?
<mathrick> psusi: try bzr log -n0 to see sub-commits in bzr merges
<mgz> matherick, I don't know an easy way to see what changed during the merge itself, unless it happened to be from the last rev anyway
<maxb> mgz: Key other things are the ability to rename and delete branches, manage branch statuses, etc.
<mgz> then diff -r 6.1.1..7 works
<mathrick> mgz: good question, doesn't comparing the merge revision with the last revision merged in do what you want?
<mgz> not if it's from a few revisions back, because the common parent isn't the rev you care about
<mathrick> I don't get what you mean/
<mgz> I think maxb actually has a better grasp on this than I do, but basically...
<mathrick> if what's from a few revs back?
<mathrick> also, what psusi says makes sense, and it'd probably be possible to introduce a new revision specifier, something like mergerev:1234, to ask for that
<mgz> the same command would be diff -r3.24.1..19 or whatever, which would give you the difference between rev 3 and rev 19, where you actually want the (unrelated to merge branch) 18 as one parent.
<mathrick> although the exact UI implications need to be thought out
<mgz> I agree some ui to do this would be useful.
<mathrick> mgz: I still don't think I understand what you mean about rev 18
<mathrick> why'd you want r18 if it's unrelated?
<mgz> well, what changed between rev 3 (which the feature branch is from) and rev 19 includes all the changes from 4..18 - which you don't want in your diff right?
<mathrick> mgz: but that's not what psusi wanted. He was asking (AIUI) to be able to see what conflict resolution changes he made in order to be able to merge fully
<mgz> so we have three parents. 3, common to both, 3.24.1 from the feature branch, and 18, from trunk.
<mathrick> which should be bzr diff -r 123..<last rev merged in with 123>, assuming 123 is the merge rev
<mgz> well, that's backwards, but yes... *only* if the feature branch originated at r 122
<mgz> otherwise you get all the other changes since then, because those are also differences between the branches.
<mathrick> no, I don't think you get what I mean
<mathrick> I have a branch here
<mgz> try it and see.
<mathrick> revno: 15 [merge]
<mathrick> which merges in revno: 12.1.1
<mathrick> bzr diff -r 15..12.1.1 gives me a diff of what I did to resolve conflicts
<mathrick> actually, it should be the opposite order
<mathrick> but you get what I mean
<mgz> does that branch have non-reverted changes at 13 and 14?
<mathrick> yes
<mathrick> hmm
<mgz> because if I do `bzr diff -r93.2.1..103 lp:testtools` that includes the trunk changes since branching.
<mathrick> I see, it lists the changes from 13 and 14 too, you're right
<mathrick> that's indeed a problem
<mathrick> what's really needed is -n for diff, the way it already works for log
<mathrick> psusi: that deserves to be put in a bug on launchpad
<mathrick> btw, for all the people discussing git-vs-bzr, there's https://launchpad.net/bzr-colo
<mathrick> which is basically in-place branches git-style, just built on top of today's bzr
<mgz> which I'd claim it git's usability with bzr's speed, but... that's not entirely fair.
<glyph> mgz: yeah, that's kinda how I feel about it :)
<mgz> git's hard to use in lots of other ways too, apart from its branch layout.
<mkanat> Srsly.
<glyph> colocated branches do have one nice usability feature which bzr lacks though
<mgz> and bzr doesn't need plugins to be slow!
<glyph> which is a way to synchronize a big pile of unrelated development all at once
<mathrick> howso?
<mgz> yeah, there are certainly circumstances where you plain just need them.
<mathrick> but once _you actually understand the concept and benefits of colocated branches_, bzr-colo works just fine
<mgz> people with super-fancy editors also seem to require one working tree for all branches as well.
<mathrick> I'd argue that bzr's approach is about 100x easier for people to grasp at the beginning
<mathrick> mgz: you mean like eclipse? Why? Because it gets confused about "workspaces" and "projects" or something?
<mathrick> but wouldn't replacing files behinds its back confuse it even more?
<mgz> I think it had problems yeah, there were threads on the list about it at any rate.
<mathrick> the eclipse / MSVC way of writing code is annoying as hell
<mathrick> because you can't just have files, you need projects and what not
<mathrick> and it's supremely useless for browsing code you're not working on
<mathrick> anyway, bzr-colo gives you in-place branches and works well
<mathrick> which is something to keep in mind next time git people come in asking
<psusi> mgz: actually, jamey pretty much nailed it... bzr does squash all of the merged commits into one big patch
<psusi> it tells you that they came from another merge, but the diff makes it look like one big patch
<mgz> psusi: no, that's not actually what it *does*, but it may well be how it gets presented to you
<psusi> mgz: right
<mgz> anyway, as mathrick suggested: <https://bugs.launchpad.net/bzr/+filebug>
<mgz> including examples of what the git command does vs. where you had the problem with bzr would be helpful I'm sure
<mgz> eg, you linked a loggerhead page, so it could probably also be targetted to loggerhead as well.
<psusi> maxb: no, I don't know how git does it, but I would imagine it does the auto merge and then the diff is taken against that... at least that is what the output looks like
<psusi> hrm... ok
<maxb> psusi: in which case... bzr squashes no more than git does. git just has a pretty rendering mode
<psusi> I suppose
<mathrick> psusi: you don't need to give technical details of what git does
<mathrick> just explain what it gives _you_ as the user
<mathrick> thinking how best to do it is something for later
 * mathrick wishes people would learn to give good bug reports, which specifically does NOT include guessing what the receiver might want to hear or do. Just give the relevant information and describe the problem / shortcoming accurately as it affects you
<psusi> aye
<psusi> https://bugs.launchpad.net/bzr/+bug/697810
<mathrick> psusi: good, could you also add a comment with an example output of git vs. what bzr says in the same situation? That will make it slightly clearer what you mean
<psusi> mathrick: ok
<psusi> mathrick: how's that?
<mathrick> psusi: the best way of presenting command output is to paste it verbatim instead of paraphrasing, but yeah, that's good enough
<mathrick> now there's a record in the bug tracker, someone has a chance of looking at it properly
<mathrick> though, hmm, actually bzr log -p seems to do exactly what you want I think
<psusi> in the example I listed, log -p shows +bar in b... if you add --include-merges, it is shown in both r2 and r1.1.1
<psusi> because of this, reviewing the merge commit for non trivial marges is impossible since the diff is the sum of all changes on the other branch, plus any local changes you had to make during the merge, if any.
<psusi> this might be a more concrete example.  say you have a variable that is used in several places, and on another branch, they add another reference to that variable.  In the mean time, you rename the variable.  When you do the merge, it will add the new refernece to the old variable name, which you will then need to rename to the new name to get the code to compile.
<psusi> with git the diff for your merge will only show the one line change where you rename the reference added in the other branch
<psusi> with bzr, you see ALL changes done on the remote branch
<mathrick> I know, I was just trying to see if log -p didn't do that already, since it seems to for _some_ situations, but not all, oddly
<psusi> hrm... where is a situation where it does do that?
<mathrick> psusi: my local branch here which has a rather simple conflict-resolving merge
<psusi> I wonder what the difference is between that and http://bazaar.launchpad.net/~psusi/ubuntu/natty/e2fsprogs/merge/revision/45, which was a simple merge with the only conflict being debian/changelog
<mathrick> it's rather odd, I get exactly what I'd expect to in that conflict-resolving merge, but in a simple merge with _no_ changes, I get a bunch of junk from the merged revisions output
<mathrick> *no conflicts
<psusi> hrm...
<zyga-efika> Should the lp: alias work out of the box with bzrlib.branch.Branch.open() ?
<zyga-efika> in other words: how do I get  Branch for lp:foo ?
<mgz> enable plugins?
<mgz> bzrlib.plugin.load_plugins()
<zyga-efika> oh
<zyga-efika> let me see
<zyga-efika> do I need bzrlib.initialize() around this?
<mgz> nope.
<zyga-efika> thanks
<mgz> (that may change, but is currently true)
<zyga-efika> .hmm, I got NotBranchError
<zyga-efika> oh sorr
<zyga-efika> it's sensitive to trailing slash
<zyga-efika> nice
<zyga-efika> thanks
<zyga-efika> still odd
<mgz> a, what exactly failed for you there?
<spiv> open_containing() rather than open() will probably make it work with trailing slashes.  It returns a tuple of (branch, rest_of_path) rather than just the branch though.
 * mgz bows to spiv
 * spiv waves back
<zyga-efika> how can I get a Revision instance from a branch given a revno?
<zyga-efika> I need to inspect something for a particular revision, it's likely embedde in the properties
<zyga-efika> the time of commit
<spiv> revid = branch.get_rev_id(revno)
<spiv> rev = branch.repository.get_revision(revid)
<zyga-efika> oh
<zyga-efika> it's on the repository object
<zyga-efika> thanks
<spiv> (Or branch.dotted_revno_to_revision_id if you have a dotted revno)
<zyga-efika> thanks, let me check this out now
<zyga-efika> spiv: is the revision.timestamp the time of commit?
<poolie> zyga-efika, yes
<poolie> hi all
<zyga-efika> poolie: thanks
<spiv> Hi poolie
<poolie> hi spiv
<poolie> spiv, i was thinking about topics for the sprint
<poolie> i'm keen to just let people hack together, especially with jelmer full time from monday
<poolie> was thinking of either finishing named branches, or finishing novfs
<maxb> named branches == colocated branches?
<poolie> right
<poolie> other options are to say that finishing work already in progress, or finishing high bugs, is best
<maxb> colocated branches would remove one of the bzr-points from http://whygitisbetterthanx.com/ :-)
#bzr 2011-01-06
<mgz> which one?
<mgz> I don't understand the top branch, it seems hg and bzr do all his bullet points there anyway.
<mgz> *top item
<mgz> branches on the brain.
<lifeless> mgz: those pages are not rational
<maxb> bzr does not make it as cheap to branch as git, unless you've preconfigured yourself into a repo + treeless branches + checkout structure, or are using the colo plugin
<poolie> i think bzr-colo does that, but
<poolie> right, it's not the easy default
<poolie> and in particular it's not part of the framework where it can be reached by bzr-git etc
<lifeless> spiv: very nice post
<mgz> if even "not creating new working tree" is what he means by fast, it's seldom actually slow.
<poolie> so i'd like to see that finished off
<poolie> lifeless, about 2.4?
<lifeless> about 3
<lifeless> and 3to2 etc
<spiv> poolie: jelmer said to me yesterday(?) that we should talk about bug 485601; there's been some off-list (and off-bug :/) mails about what precisely bzr's model constrains (i.e. is it valid for bzr-svn to change ie.revision in existing inventories when filling ghosts).
<ubot5> Launchpad bug 485601 in Bazaar "missing chk node(s) for id_to_entry maps" [Medium,Incomplete] https://launchpad.net/bugs/485601
<spiv> poolie: otherwise hacking sounds great :)
<spiv> lifeless: thanks!
<poolie> i'll add that to the wiki
<poolie> how did we even get onto the topic of 2.4?
<mkanat> poolie: Hey hey.
<mkanat> poolie: Since I have Approve on the XSS fix, can I also merge https://code.launchpad.net/~mkanat/loggerhead/raw-controller/+merge/42675 ?
 * poolie looks
<poolie> yes, i'll reply
<mkanat> poolie: Great, thanks. :-)
<poolie> just for curiousity
<mkanat> poolie: That means I can get on to other work!
<mkanat> poolie: That will start tomorrow.
<poolie> how does this work in bugzilla
<mkanat> poolie: Ah, very similarly, but with more complexity.
<poolie> what stops me uploading an attachment that does xss?
<mkanat> poolie: The long answer is: https://bugzilla.mozilla.org/show_bug.cgi?id=38862
<mkanat> poolie: We do something very similar--if you access attachment.cgi with a request to serve a file, you get redirected to a separate domain.
<mkanat> If the admin hasn't specified a separate domain, Bugzilla defaults to downloading the file instead of displaying it (although admins have an option to override that).
<poolie> hm
<mkanat> poolie: We offer the option to put %bugid% into the attachment domain, so that you can have one attachment per bug.
<mkanat> poolie: There are also various security situations:
<poolie> so that second case is similar to what i was asking for with loggerhead downloads?
<mkanat> poolie: * Bugs that normal users cannot see, but only special users can see
<poolie> ie that if you don't have a separate domain, by default it only downloads?
<mkanat> poolie: * Attachments that normal users cannot see, but only an even MORE special group of users can see.
<poolie> however, perhaps it's different because the normal deployment of loggerhead is readonly
<mkanat> poolie: Yeah, and doesn't involve auth.
<mkanat> poolie: Bugzilla involves not only auth, but a lot of high-security stuff.
<mkanat> poolie: For the secure bugs and the secure attachments, we do tokens, much like lifeless described.
<mwhudson> loggerhead does support --allow-writes :-)
<mwhudson> but without any auth indeed, so don't do that
<mkanat> poolie: We generate a one-use token, redirect to the URL with that token, and then delete it as soon as the page is viewed.
<mkanat> poolie: Because the attachment domain can't ever get any cookies--otherwise that would partially defeat the XSS protection that we're going for.
<mkanat> (Although our auth cookies are already httponly.)
<mkanat> mwhudson: Yeah, that's like "bzr serve --allow-writes". Bad idea. :-)
<poolie> mm
<poolie> ok
<mkanat> poolie: We also have extra complexity involved because there are a lot of other automatic redirects that can happen in Bugzilla, mostly around forcing SSL.
<poolie> so, i think you should just mention the feature in readme or whatever
<poolie> right
<poolie> otherwise it's fine, let's land it
<mkanat> poolie: Okay, thanks. :-)
<mkanat> All right, I'm out. Later!
<poolie> lifeless, oh you meant the prisoner's dilemma mail?
<poolie> i agree
<vila> hi all !
 * fullermd waves vila around a bit.
<voidspace> which versions of Python does bzr support?
<bob2> all the way back to 2.4 currently
<voidspace> bob2: thanks
<CaMason> hi guys. Any thoughts on what would cause this? NameError: global name 'readline' is not defined
<CaMason> just started happening after my system crashed
<maxb> ouch. Was there filesystem corruption? Sounds like a python module has disappeared from disk
<CaMason> well I did an fsck and everything was OK
<maxb> What is your OS?
<CaMason> Ubuntu 10.10 running inside of a VM on Windows 7
<maxb> CaMason: Does the file /usr/lib/python2.6/lib-dynload/readline.so exist?
<maxb> erm, nevermind, I misread your initial error message
<CaMason> it does
<maxb> Please re-execute the bzr command that gave you trouble with -Derror, and pastebin the output
<CaMason> http://pastebin.com/2bZSnnxC
<maxb> What is your bzr version? (dpkg -l bzr)
<CaMason> 2.1.1-1
<maxb> It appears to be a bug which is masking the real error
<maxb> Please open /usr/lib/python2.6/dist-packages/bzrlib/pack.py in an editor, go to line 206, and change % (readline, )) to % (result, ))
<CaMason> done
<CaMason> bzr: ERROR: short readline in the readvfile hunk: '\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00'
<CaMason> something to do with my repo?
<CaMason> interestingly, `bzr log` works fine on another repo (no error). This error is occuring in `bzr log` (and branch) at a particular commit
<CaMason> I've opened the repo with qlog, and when I scroll down to r104, I then get the error popping up
<CaMason> I was working on this branch when the crash happened. I do have a copy of it elsewhere. Should I do a pull?
<maxb> CaMason: OK, so it looks like the crash has caused one or more files within a bzr repository to be corrupted by filling it with lots of zero bytes
<CaMason> oh fie
<maxb> Is the problem branch using a shared or standalone repository?
<CaMason> standalone
<maxb> (bzr info if you're not sure)
<maxb> OK, if you have a copy elsewhere, fetching that would be the simplest option
<CaMason> yes I do.
<maxb> If you have new revisions locally that are not in the remote, it may work to pull the broken branch into a fresh copy of the remote
<CaMason> no, fortunately I pushed not so long ago
<CaMason> shall I just put this down to an epic BSOD failure?
<maxb> CaMason: Are you running ext4 on this filesystem?
<maxb> Even if you are, this really ought not to happen :-/
<maxb> Is the branch data private?
<CaMason> it is :(
<maxb> It would be necessary to study in exactly which files the corruption was present to try to determine what component was at fault
<glyph> is 'bzr branches' ridiculously slow all the time?
<glyph> I'm running it against a local repository with maybe 500 branches in it, and it's taken 15 minutes already
<maxb> glyph: It's ridiculously slow if you have bzr-{hg,git,svn} installed
<jelmer> maxb: huh? They should only add a single extra stat each, unless you actually have hg, git or svn checkouts
<jelmer> single stat per dir that is
<lifeless> mkanat: hi
<lifeless> https://bugs.launchpad.net/loggerhead/+bug/698305
<mgz> ...whatever that ext4 option that makes it sucks less should be up as a bzr faq
<mgz> nearly every time someone reports repo corruption on launchpad or the list, they're running on ext4
<poolie> indeed
<poolie> perhaps we should flush by default too
<poolie> bye all!
<mkanat> lifeless: Okay. If that's a high-priority item, you can talk to poolie to have it put on my todo list. It looks pretty minor to me, though.
<lifeless> mkanat: in LP we have a policy that OOPSes are always high/critical (we're polishing the label atm)
<lifeless> mkanat: poolie is flying atm
<mkanat> lifeless: Ah.
<mkanat> lifeless: I wouldn't say that that's practically critical in this case.
<mkanat> lifeless: I used to have a similar policy for Bugzilla, but we scrapped it as impractical.
<lifeless> mkanat: we're seeing 6000 error reports a day
<mkanat> lifeless: From just that?
<lifeless> mkanat: possibly, due to some config issues our group-and-analyser isn't running on them at the moment
<lifeless> sorry, 12K a day - two servers.
<mkanat> lifeless: From loggerhead alone?
<lifeless> yes
<mkanat> Jeez. Okay.
<lifeless> data is useful :)
<mkanat> So I can see why it would be at least important to reduce the noise.
<lifeless> its also important in presenting a pleasant UI to users
<mkanat> And yeah, that should be a 404.
<mkanat> lifeless: Yes, although if you hack the URL, presenting a pleasant UI to you is not a high-priority item.
<mkanat> However, reducing the noise does seem important.
<mkanat> lifeless: Anyhow, my work list is very very limited right now, I can't add anything without poolie's authorization.
<lifeless> thats fine
<lifeless> when you see him next, can you ask him aboot it?
<mkanat> lifeless: Sure. If you don't hear from me on that bug tomorrow, then feel free to remind me, also.
<mars> Hi everyone, I have a bug with our code that uses bzrlib that I am trying to work through, and I could use a hand figuring out what is happening
<lifeless> shoot
<mars> lifeless, thanks.  Our code does a branch checkout, runs the suite, then a branch push
<mars> lifeless, the push happens ~4 hours after the checkout.  I get this error (starts around line 25): http://pastebin.ubuntu.com/551269/
<mars> lifeless, if I remove the test suite run, then the branch push happens perfectly, as expected
<lifeless> probably tcp timeout
<lifeless> establish a new branch object rather than using the same one
<lifeless> possibly idle ssh session timeout on the codehosting service
<mars> yes, we suspected that too
<mars> I was wondering if there was a way to close out the connection, or copy the Branch object, but I can create a new one too (more invasive to the existing code though)
<mars> thanks lifeless
<lifeless> b = bzrlib.branch.Branch.open(oldbranch.base)
<lifeless> will open fresh with no reuse of session/transport
<mars> cool, thank you
#bzr 2011-01-07
<d3jake> I've encountered this error while trying to commit my project to a bzr repository hosted by sourceforge.net. http://pastebin.com/ahW8U8Ve This leads me to think that my bzr version is too new to work properly, is this a correct analysis?
<AfC> d3jake: no, it means that for whatever reason the data on the server is in a *really* old format. If you can upgrade the server branches you'll fix the problem
<d3jake> AfC, Unless a change was made to bzr's format breaking backwards compatibility within the last three-four months, I don't see why this error would be happening. I was able to make commits without issues using a not-too-distantly-old version of bzr to the same repository.
<AfC> It's not the Bazaar version. I can't tell you what the error is, but it is doing a conversion to something (WAY) older than 2a, and so you're exposing yourself to trouble. Upgrade the server branch & repository if it's yours. And if it's not yours, ask them to. There's no reason, none, to not be using 2a
<d3jake> Ohh, okay. So the problem is likely on sourceforge.net's end as they are the one's hosting the repository?
<AfC> "hosting" is just disk space
<AfC> whose project is it?
<AfC> yours or !yours?
<AfC> and,
<AfC> do you have SSH access to the server?
<d3jake> The project is mine. And no.
<AfC> hm.
<AfC> Well, others can correct me if I'm wrong, but all you need to do is `bzr upgrade` the (branch and the) repository
<AfC> I can't recall if you can do that over bzr+ssh. You might be able to, actually.
<AfC> failing that,
<AfC> you can bzr upgrade locally to 2a
<AfC> (actually, it sounds like you have already)
<AfC> and just overwrite completely what's up there.
<d3jake> So, open a console, go into the root directory of my project, and type "bzr upgrade", and then some sort of command to force the changes onto the server somehow?
<AfC> I'll let others take it from here; there are a few web pages out there on the topic I'm sure
<AfC> but short answer, yes
<d3jake> Okay, cool
<d3jake> Thank you for your help :)
<AfC> bzr info
<AfC> will guide you on your way
<AfC> and read the help for upgrade
<d3jake> Does it mean anything if bzr info tells me that my project is a standalone tree, and in format 2a? Does this mean that I need to upgrade the repo?
<AfC> d3jake: your local tree?
<AfC> If it says that, then you're fine locally (and is the case as evidenced by the strange error you got)
<AfC> d3jake: if it says that for the remote tree, you are finished
<d3jake> AfC: Yes, it is my local tree.
<d3jake> I'm wading through trying to see if I can et the remote tree fixed, but I'm nearing the time when I should shove off for the evening...
<AfC> so just do
<AfC> $ bzr upgrade bzr+ssh://path/to/remote/tree
<AfC> that'll work, or not
<AfC> failing that, just remove it and upload a new one
<d3jake> Remove it? As in delete the remote tree, and then reupload?
<d3jake> Wouldn't I loose all of my revision history?
<d3jake> Ah well, I need to bail. Thank you for your help.
<AfC> If you've got conflicts, can you use `meld` to sort it out?
<AfC> (ie, "yes", but what's a good idiom?)
<spiv> AfC: not sure, but I'd be interested to hear if you find one!
<AfC> spiv: ie, `bzr diff --using=meld` is vaguely a step in the right direction;
<AfC> it seems like
<AfC> $ meld path/to/file.OTHER path/to/file.THIS
<AfC> is about right, but still, it's a bit fidgety
<TimMiao> hello everyone, could anyone please tell me where can I set the proxy for bzr? to add a new line "http_proxy = http://some.proxy.address:port/" in bazaar.conf file doesn't work for me. Thanks!
<vila> hi all !
<fullermd> Eh?  Again?  Didn't you just say that yesterday?
<spiv> fullermd: it's like the days just keep coming and ocming!
<spiv> TimMiao: set it as an environment variable
<fullermd> spiv: I know!  I'm _sure_ I never authorized that!
<vila> . o O (Did I just saw this groundhog *again* ?)
<Peng> Groundhog? Does that mean I get six more weeks of insomnia? :D
<spiv> Peng: you could always transform that into six weeks of late-night Bill Murray movie watching!
<vila> I love this movie but... six weeks... wow :)
<quicksilver> my daughter was born on groundhog day.
<fullermd> Did she see her shadow on the way out?
<svaksha> hi, while checking out code I get  "bzr: ERROR: extra argument to command checkout". How do I solve it? TIA.
<beuno> svaksha, what command are you running
<svaksha> beuno: http://www.gnuenterprise.org/developers/bzr.php <-- trying to get the source
<svaksha> bzr co bzr branch http://bzr.savannah.gnu.org/srv/bzr/gnue
<beuno> right
<beuno> so you don't need the first part, "bzr co"
<beuno> just:  bzr branch http://bzr.savannah.gnu.org/srv/bzr/gnue
<svaksha> beuno: still throws this error, bzr: ERROR: Not a branch: "http://bzr.savannah.gnu.org/srv/bzr/gnue/".
 * svaksha tried it with sudo too
<beuno> svaksha, FWIW, that page has it wrong
<beuno> not sure if it can be reported
<beuno> http://bzr.savannah.gnu.org/srv/bzr/gnue 404s
<svaksha> beuno: yes, but i dont know how else to get the source
<beuno> and bzr co bzr branch is from
<beuno> svaksha, try: bzr branch http://bzr.savannah.gnu.org/r/gnue/
 * svaksha has been trying different brz permutations with no luck
<svaksha> s/brz/bzr
<beuno> no, the url in that page is wrong
<svaksha> beuno: that worked, thanks :)
<beuno> cool, np
<svaksha> beuno: fwiw, I reported the error in their irc channel. So thanks!
<vila> jelmer: ping
<jelmer> vila: hi
<vila> jelmer: hi there
<vila> jelmer: saw my pm ?
<jelmer> vila: no, thanks for the reminder
<frathgeber> ?nested
<vila> jelmer: did you get failure reports from pqm ?
<vila> jelmer: if yes, can you try feed-pqm my submission about 321320-isolate-doc-tests ?
<jelmer> vila: yep, I did get (strange) failure emails
<vila> jelmer: don't resubmit mine ! Just got mails
<vila> jelmer: what kind of strangeness ?
<jelmer> vila: I don't remember actually, I'll retry.
<vila> jelmer: already failed right  ?
<vila> jelmer: meh, misread the page.. again...
<vila> jelmer: or not ?
<vila> jelmer: you sent 2 requests ?
<jelmer> yeah
<vila> jelmer: got mail for the first one ?
<jelmer> Yeah - PQM test failure.
<jelmer> Ran 0 tests in 0.000s
<jelmer> And empty output files attached
<jelmer> merge http://bazaar.launchpad.net/~jelmer/bzr/daily-ppa http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev
<vila> ha, I feel less alone :-/
<mgz> ...committing is broken again?
<mgz> that's not good, last thing to land was by me,,,
<vila> mgz: don't be so paranoid :)
<vila> . o O (Or how would we get you...)
<vila> mgz: I looked at it, but saw nothing wrong
<vila> mgz: my pqmlike setup is fine with my patch too :-(
<mgz> maybe it's not my fault and the pqm box just ate too much over xmas and hasn't recovered
<vila> well, nothing has landed since... unless you count failed submissions, pqm is on diet :)
<vila> mgz, jelmer: sounds like the pqm *host* have been upgraded to lucid while we still run in a hardy chroot and there are.... unknown issues :(
<fullermd> See what happens when you use adjectives instead of version numbers?   :p
<jelmer> vila: ah
<vila> jelmer: and stop queuing (s) my submissions, email (e) them instead when using feed-pqm:D
<Phoenixz> A co-worker committed a change, pushed it, and I pulled it.. the commit is rubbish and should NOT be committed... How can I remove or revert this entire commit, and redistribute it?
<knighthawk> I'm confused I just tried to commit to my central repo and it gave me a message saying that "No WorkingTree exists" I thought I didn't need a working tree for a central repo
<jelmer> Phoenixz: you can commit the revert of that commit, e.g. "bzr revert -r -2 && bzr ci -m 'revert broken commit'"
<knighthawk> Phoenixz, can you just revert your copy then commit it?
<jelmer> knighthawk: you shouldn't need a workingtree indeed - how are you committing to the central repo?
<knighthawk> jelmer, 'bzr commit -m "update repo" sftp://path to repo'
<jelmer> knighthawk: That will try to do a commit in that location
<jelmer> knighthawk: You probably want to commit in your local branch.
<jelmer> if your local branch is bound to the central branch the changes will automatically be pushed to the central branch. alternatively they can be pushed manually
<jelmer> so you probably want:
<jelmer> "bzr bind sftp://path to repo; bzr commit -m 'update repo'"
<jelmer> bzr ci -m 'update repo' && bzr push sftp://path-to-repo
<knighthawk> if I run bzr info It has the central branch set up for push branch and submit branch
<jelmer> knighthawk: in that case you wouldn't need an argument for "bzr push", but you'd still need to run it if the branch is not bound
<knighthawk> but I would like to commit on my local as well. Right now I'm more concerned about getting my team up to speed on BZR so we can all use it.
<jelmer> knighthawk: if you run "bzr ci -m 'foo'" without any other arguments it will commit to your local branch
<jelmer> knighthawk: if you've bound the branch to another branch it will automatically push the new commit there as well (hence the "bzr bind" command I mentioned earlier)
<jelmer> knighthawk: you don't have a bound branch from what I can tell, so you'll need to bind it manually.
<knighthawk> jelmer thanks. I'll try the bound then see if that works.
<knighthawk> bzr: ERROR: sftp://repos.grdev.com/opt/bzr-repos/grws/.bzr/ is not a local path.
<knighthawk> when I try to commit after the bind.
<knighthawk> bzr: ERROR: Permission denied: "/opt/bzr-repos.grws": [Errno 13] Permission denied
<knighthawk> when I try to push
<knighthawk> I want to remove a file from my working tree but don't want to remove it from my file system. I *should* have set up bzr ignore before it got picked up by my working tree but I didn't.
<knighthawk> now how do I remove it without using bzr remove. or is there a way to tell bzr remove to leave the file on my filesystem?
<knighthawk> just found the --keep option. Thanks
<jelmer> knighthawk: when you commit you shouldn't specify the remote repository
<achiang> hello, is there a way to completely revert a commit, the same way you would say, "git reset --hard HEAD^" ? the git command erases the -1 commit from history, forever as if it never existed
<achiang> bzr merge . --revision -1..-2 kinda gets me close
<achiang> but i still see the -1 commit in my log
<james_w> achiang, bzr uncommit
<achiang> ah!
 * achiang goes to read the man page
<achiang> james_w: perfect, thank you
<knighthawk> jelmer, thanks I think that's what I was doing wrong.
<james_w> achiang, you'll want a bzr revert as well to match reset --hard
<achiang> james_w: yeah, i just discovered that
<mgz> bug 700000!
<ubot5> Launchpad bug 700000 in software-center (Ubuntu) "software-center crashed with IndexError in _build_view(): list index out of range (dup-of: 631415)" [Undecided,New] https://launchpad.net/bugs/700000
<ubot5> Launchpad bug 631415 in software-center (Ubuntu) "software-center crashed with IndexError in _build_view()" [Undecided,New] https://launchpad.net/bugs/631415
<mgz> ...is a dupe.
<Peng> Well, better luck with 800000.
<jelmer> hehe
<jelmer> mgz: I managed to get 600000 IIRC :-)
<jelmer> bug 600000
<ubot5> Launchpad bug 600000 in hitchhiker (Ubuntu) "missing dependency on Bazaar" [Low,Fix released] https://launchpad.net/bugs/600000
<jelmer> yup :)
<mgz> go jelmer :)
<jelmer> my greatest accomplishment of 2009 :-P
<mgz> had a look at apache-bzr source.
<mgz> nice idea.
<jelmer> mgz: the code does indeed need some more work :-)
<mgz> ...that... wasn't the implication >_<
<jelmer> :)
<jelmer> There was a reason the announcement said it was a PoC :-)
<mgz> avoids the wsgi mess and confusion neatly at any rate.
<knighthawk> I'm trying to remember the syntax to include the user name and password in the URL.
<knighthawk> something like sftp://username:passwd@example.com
<knighthawk> only that doesn't seem to be working, and I can't think of anything else.
<bob2> don't do that for sftp
<bob2> sftp://user@example.com/ does work, though
<bob2> er "don't put passwords in there for sftp"
<knighthawk> I've got members of my team using Windows. and I have no idea how to tell eclipse what password to use without putting it in the path.
<bob2> nah, use ssh keys
<knighthawk> perhaps in bzr I can tell it the passwd then eclipse wouldn't have to know but again. Don't know how to do that in windows.
<knighthawk> hmmm that sounds like a good solution actually.
<Phoenixz> A coworker of mine added, comitted, and pushed files into a repo that should not be there.. I pulled those files, and now I'm stuck with them. I want these files not only out of the WT, I want them out of the repo, I want that commit gone (the files are copyrighted, the repo is open source).. How can I undo / revert / remove this commit?
<maxb> bzr uncommit
<knighthawk> okay I'm confused again. I just did a commit to a central repos of revision 7. However whenever other members of my team try to update they just get revision 6 what am I doing wrong.
<maxb> thats not much info to go on but the logical assumption would be that you've only committed locally
<bob2> Phoenixz: exporting and importing are your only options afaik
<Phoenixz> bob2: ok.. On a non-copyright issue then, is it possible to "uncommit" or unmerge those things away?
<Phoenixz> bob2: like, remove commit 34... 34 will still be there in the repo, but at least won't affect files.. ?
<bob2> yes, 'bzr rm' :)
<Phoenixz> bob2: bzr rm is on file level.. there isn't anything like that on commit level?
<bob2> kinda
<Phoenixz> bob2: kinda... ? as in?
<bob2> as in I'm not sure what the point is - bzr rm leaves stuff in the rev history the same way as bzr revert would
<maxb> Phoenixz: the important question is: is the problem commit the last commit in the branch?
#bzr 2011-01-08
<Phoenixz> maxb: nope... and its committed, pusehd,  and then pulled by me
<kgoetz> has anyone seen a bzr-monotone plugin? i've not found anything, but asking incase
<kgoetz> i could probably do it via git, but that sounds scary ;)
<kgoetz> ah, lp:bzr-mtn - will investigate
<kgoetz> wonder if i can get lp to email me if it gets updated
<kgoetz> (aka, starts to exist)
<jelmer> kgoetz: you can subscribe to the branch :-)
<kgoetz> jelmer: i hadn't noticed it had one - cheers :)
<catphish> does bazaar store branches git-style (link to the tip revision) of like hg (all commits are marked with the branch name)
<edakiri> To compress and archive a repository: are there expendable indexes which can be erased or a more compact repository format that can be used for a repository which will be archived and compressed?
 * catphish has used way to many VCSs this week
<edakiri> Hmmmm. Maybe I can save space my removing the working tree.
<kgoetz> catphish: just use bzr, and plugins for other vcs' ;)
<catphish> lol
<catphish> personally i'm afraid i will always use git, but i'm supporting a few others
<fullermd> catphish: Pointers to tips.
<fullermd> edakiri: Conceptually?  Probably.  But there's no implementation support AFAIK.
<catphish> gdgd :)
<fullermd> Actually, I thought hg did too.
<fullermd> I thought mtn with its certs was the only major system that defined branches by marking revs.
<fullermd> Well, and darcs, but that's another story wholesale.
<maxb> hg basically has something like bzr's "branch nicknames", except hg actually uses them to define what branch a revision is on
<maxb> and there's no explicit tip pointer - just the last revision with a particular nick
<catphish> i just got 2 completely opposite answers
<maxb> huh?
<maxb> catphish: bzr's branches are the pointer to tip revision model. bzr also has a concept called branch nick, where a string is embedded in each revision, but it's just informational (shown in log messages)
<catphish> oh ok
<catphish> that makes more sense, thanks
<maxb> It's not quite clear to me why branch nick exists, but it is occasionally useful *if* people have been populating it suitably
<edakiri> I'm having trouble finding (in the documentation) how to change the parent
<catphish> why would you want to change the parent of a commit?
<catphish> i'm new to bazaar, but that sounds unwise
<AfC> Evening
<edakiri> catphish: not of a commit. of a repository
<catphish> ah
<catphish> :
<catphish> )
<maxb> edakiri: I'm afraid I still don't understand the question - repositories do not have parents
<edakiri> maxb: yes, i mean branch.  The current case is a standalone repo.
<edakiri> removing the working tree in this case reduced the size by 1/5
<mgedmin> launchpad ate my bazaar branch :(
<mgedmin> bzr branch lp:~mgedmin/gtimelog/app-indicator -> bzr: ERROR: RemoteRepository() is not compatible with RemoteRepository() different serializers
<mgedmin> I _think_ what happened was I created a branch off trunk, pushed it to launchpad (which made it a stacked branch)
<mgedmin> and then later I upgraded the trunk branch
<mgedmin> and now this one is broken
<mgedmin> http://bazaar.launchpad.net/~mgedmin/gtimelog/app-indicator/revision/148 gives me an Oops!
<mgedmin> maybe I should talk in #launchpad and not here
<vadi2> Would anyone know how to create a diff of a file between it's current and the latest tagged (with any tag) version in bzr?
<Meths> bzr help diff and bzr help revisions  will probably help with that.
<vadi2> nothing on revisions
<vadi2> Guess I got it, though. bzr tags
<mgedmin> bzr diff -r tag:TAGNAME filename.txt ?
<vadi2> yeah, I don't know the tagname - have to find it out
<vadi2> bzr tags shows them, so that works for me. thank you
<psusi> is there a bzr equivalent of git describe?  Meaning give me the name of the most recent tag?
<LeoNerd> bzr tags | head -1  ?
<LeoNerd> Er.. tail perhaps
<LeoNerd> Oh..  bzr tags --sort=time | tail -1
<LeoNerd> That's getting awkward
<LeoNerd> Damnit, can we please have shell aliases in bazaar.conf now?
<LeoNerd> lasttag = tags --sort=time | tail -1    would be nice
<jelmer> psusi: there is an open bug about it, I plan on implementing a command like that
<vadi2> LeoNerd: cool, thanks
<LeoNerd> I have an ever-growing list of things I'd like ot put in aliases but I can't because they're full shell pipelines
<LeoNerd> bzr di | view "+setf diff" -
<jelmer> LeoNerd: why not put that in your shell aliases?
<LeoNerd> Because I want to type  bzr viewdiff   and not   bzr-viewdiff
<LeoNerd> I played that game with CVS
<LeoNerd> I had a  bin/cvs  that simply tested if  cvs-$1 was available, exec'ed that, or real cvs
<jelmer> LeoNerd: alternatively, perhaps a trivial bzr plugin that provides that command?
<LeoNerd> It's 2011, not 1970. I shouldn't have to resort to such hackery
<psusi> there we go...
<lifeless> LeoNerd: so the tension is that we need bzr configs to work on windows too and its severely lacking in the shell dept
 * jelmer waves to lifeless 
<LeoNerd> I wouldn't mind a plugin tat didn't work on Window
<LeoNerd> A plugin that provides more flexible aliases
<jelmer> LeoNerd: The question is how much shell-like behaviour would you like to support? And which shell would you want to be compatible with?
<LeoNerd> Something I can easily play Lego^W unix with it
<LeoNerd> bzr di -rtag:`bzr latesttag`..    would be nice
<LeoNerd> bzr di -rafter:tag:`bzr latesttag`..    would be nicer still, but I don't believe  after   works yet
<psusi> what the hell... I seem to have some broken tags... bzr tags shows ? for the revision
<jelmer> LeoNerd: we already have one extension language for bazaar, I would be wary of adding another, especially if it's a custom language.
<jelmer> psusi: those would be tags of revisions that are not in your currnet branch
<jelmer> they're not necessarily broken
<psusi> well shoot.... how can I ignore those?  it's putting a damper on my attempt to diff the wc against the last tag ;)
<psusi> wth?  bzr tags --sort=time is not putting them in a sane order either... I'm testing this on a copy of lp:ubuntu/e2fsprogs I had around and it's showing the tags all out of order
<jelmer> it sorts by the time of the revision that was tagged IIRC
<lifeless> thats correct
<lifeless> you probably want a debversion sort
<psusi> actually I guess they are mostly in order... but for some reason it messes up at the end... goes from upstream-1.41.14 to 1.41.14-1, then back to 1.35-8ubuntu2, then up to 1.37-2sarge1, and finally ends with upstream-1.37, which it shows as ?
<lifeless> perhaps you could file a bug on bugs.launchpad.net/udd
<mgedmin> thank you for bzr push :parent
<mgedmin> bzr branch lp:~gtimelog-dev/gtimelog/packaging gtimelog-packaging
<mgedmin> KeyError: 'Bazaar-NG Loom branch format 7\n'
<mgedmin> my guess would be I'm missing some plugin (loom)?
#bzr 2011-01-09
<jelmer> mgedmin: yep
<aroman> Which is faster, bzr or git?
<Toksyuryel> aroman: define "faster"
<Toksyuryel> git takes forever to learn and understand, and is therefore slower than bzr for me
#bzr 2012-01-02
<vila> hi all, happy new year !
<lifeless> vi hila
<vila> :)
<AuroraBorealis> why can i not bind a colocated branch to a remote branch?
<AuroraBorealis> it keeps binding it to itself
<AuroraBorealis> it doesn't seem colocated branches are very stable :<
<AuroraBorealis> anyone?
<soren> This doesn't look right: http://paste.ubuntu.com/790403/
<soren> Oh, this is probably a #launchpad thing. Sorry.
<jelmer> vila: are you here today?
<vila> jelmer: yup ;)
<vila> jelmer: happy new year !
<jelmer> vila: hey!
<jelmer> vila: Thanks, happy new year to you too!
<jelmer> vila: How were your holidays?
<vila> pretty good, except for resting ;)
<vila> we met a lot of friends so... lots of parties ;)
<jelmer> :-)
<jelmer> hmm, looks like we have some reviews to catch up to :)
<vila> jelmer: oh, hmm, yeah
<vila> jelmer: do you know if poolie and mgz are still in vacations ?
<jelmer> vila: not sure about poolie, but I think the UK has a holiday because the 1st was on a sunday
<vila> lol
<vila> I thought only *French* were doing such things ;)
<jelmer> hehe
<mgz> yup, still holiday today, should have posted noting that, sorry
<jelmer> mgz: no worries :)
<jelmer> mgz: oh, and happy 2012
<mgz> thanks! and to you and vila (and everyone else here) too
<mgz> will be driving back home later today
<jelmer> where did you spend your holidays?
<mgz> with one sister then the other, so a lot of baby holding the last few days
<vila> mgz: hey !
<mgz> what did you get up to jelmer?
<jelmer> I spent christmas at my parents and then went to Berlin for 28C3 and NYE with some friends
<mgz> ah, various of my friends were following that online, don't think any of them actually went though
<AuroraBorealis> continued from last night, does anyone know why i can't bind a colocated branch to a remote branch? it keeps binding 'to itself' which obviously doesnt work
<jelmer> AuroraBorealis: hi
<AuroraBorealis> heya
<jelmer> AuroraBorealis: can you expand a bit on what you're trying to do exactly?
<AuroraBorealis> i'm trying out colocated branches cause i like how things are laid out
<AuroraBorealis> so i have a 'trunk' branch inside of it, and thats the working tree and all that
<jelmer> ?
<AuroraBorealis> i created a new "colocated branches workspace" in bazaar explorer
<jelmer> AuroraBorealis: is this colocated branches in bzr 2.5, or the bzr-colo plugin?
<AuroraBorealis> it appears to work in bzr 4.2
<AuroraBorealis> as thats what i have
<AuroraBorealis> err
<jelmer> AuroraBorealis: that would be the bzr-colo plugin then
<AuroraBorealis> 2.4.2
<fullermd> Wow, can you send me a copy?   8-}
<jelmer> AuroraBorealis: no idea about that, sorry
<AuroraBorealis> so...if i upgrade to 2.5 then will it not be a plugin and work better? =/
<fullermd> Actually, doesn't Explorer have some thing it calls 'colocated', but is actually just the only single-switched-wt thing, not actually anything strictly colo?
 * fullermd has vague memories of reading something about that.
<AuroraBorealis> it seems to be a light checkout
<jelmer> AuroraBorealis: the 2.5 colo support has other issues
<AuroraBorealis> pointing to .bzr/branches/whatever
<jelmer> AuroraBorealis: it's not finished yet
<jelmer> AuroraBorealis: that sounds like bzr-colo
<AuroraBorealis> well it was in bazaar explorer so i thought it was semi official
<jelmer> AuroraBorealis: I mean the colocated branch support in bzr 2.5 is not finished yet
<AuroraBorealis> is that using the plugin (or code based off the plugin) or is it brand new
<jelmer> AuroraBorealis: it's completely independent of the plugin
<AuroraBorealis> ok.
<AuroraBorealis> i shall wait then
<jelmer> though I think Neil has done some work in bzr-colo to make it work with bzr 2.5's colocated branch support
<AuroraBorealis> i just like the layout of colocated branches and wanted to try it out :<
<Wellark> hi! I remember reading it somewhere but can't find the info on help.launchpad.net.. how can I change which branch lp:<project> actually points to?
<jelmer> Wellark: hi
<jelmer> Wellark: #launchpad is usually more appropriate for Launchpad-specific questions
<jelmer> Wellark: there should be a edit button next to the branch name on your project home page
<Wellark> jelmer: oh, sorry. but anyway, thanks! I'll follow up at #launchpad
#bzr 2012-01-03
<poolie> hi all
<jelmer> g'morning poolie!
<jelmer> how were your holidays?
<poolie> hi
<poolie> pretty nice
<poolie> wgz, hi?
<wgz> hey poolie
<poolie> hi
<poolie> happy new year
<poolie> i was just going to reply to terry from leo-editor
<wgz> yeah, that was also on my todo for tomorrow
<poolie> if he has a working branch i think he can just call that 'trunk
<wgz> however he created the previous one still results in it being broken, apparently
<wgz> I need somone who understands launchpad stacking to walk me through the relationship between the branches
<AfC> Is there an environment variable (or?) that indicates to bzr which SSH key to use when connecting to a remote server?
<poolie> afc, not in bzr, but you can configure that in .ssh/config
<AfC> poolie: no, it's per command [ie bzr] not per target server that I need to change it
<poolie> if you want to use a different one for bzr vs other access, create a different virtual host, with the HostName pointing to the real name
<AfC> hm
<poolie> hm
<AfC> let me look, might work
<poolie> i think you can set the ssh client command name and you could point to a script that adds that parameter
<AfC> oh,
 * AfC dummy
<AfC> I changed the name of they key file
<AfC> already had an entry in .ssh/config
<AfC> bah
<AfC> humbug
<AfC> sorry for noise.
<AfC> poolie: thanks for help
<AfC> [that was hard to debug!]
<jelmer> moin
<poolie> hi jelmer
<poolie> welcome back
<vila> hi all,
<vila> happy new year poolie
<poolie> hi there, thanks vila, hi mgz
<mgz> morning all!
<poolie> hey
<jam> hi all, welcome back from the holidays
<wgz> ....it's a random place in the UK
<wgz> not even where my ISP is based
<wgz> okay, enough battling with plusness
<jelmer> it's probably just the closest thing to the cneter of the UK?
<jelmer> I just got disconnected too
<wgz> I'd expect more midlandsy for that, is suspiciously close to scotland
<mgz> ha, again I'd plugged this laptop in without actually switching on the power
<mgz> vila: so windows babune is still bust, I think this is still my fault and I've made a circular import despite trying not to
<vila> dang it, almost forgot
<vila> mgz: there are at least 2 issues
<mgz> can you give me the traceback from the win32utils import?
<mgz> if I can get away without completely restructuing the platform code to make it more sane, that would probably be best
<vila> that one is trivial, just removing the line 2087 in osutils
<vila> http://babune.ladeuil.net:24842/view/debug/job/debug-windows/lastFailedBuild/
<vila> http://babune.ladeuil.net:24842/view/debug/job/debug-windows/lastFailedBuild/testReport/junit/bzrlib.tests.per_intertree.test_compare/TestCompare/test_abc_content_to_empty_InterDirStateTree_C__/ is where I get lost
<mgz> okay, looking, thanks
<mgz> ack.
<vila> mgz: so you can start from lp:~vila/bzr/for-babune/
<vila> if you want
<mgz> probably also just an import ordering issue from me
<mgz> otherwise, I'll blame jelmer's xml removing branch
<mgz> will track it down.
<vila> more likely ;)
<vila> also, absolute import fallback came to mind
<mgz> er... what were these test__btree_serializer ones about...
<mgz> I thought I'd formed an opinion, but now can't remember it
<vila> hmpf, yeah, not very readable output, but I suspect the same underlying issue so didn't ever bother
<mgz> okay, your for-babune change is good, I'm going to send that to pqm
<vila> jelmer: I'm not sure I understand your desire for unescape_for_display, care to clarify ?
<mgz> can't a man have his desires?
<vila> hehe
<vila> sure, but understanding them help to address them ;)
<jelmer> vila: Mostly, I just like to not have a lot of different ways of converting URLs to user touchable things and vice versa
<mgz> URL.__unicode__
<jelmer> mgz: we do want to allow paths in locations.conf though
<jelmer> in particular, I worry about things like readonly+file:///
<vila> yeah and windows paths too (or at least one bug asks for that)
<jelmer> and escaping characters in URLs
<vila> right,
<jelmer> that's why I'm a bit skeptical - I'd rather just use normalized URLs internally and have user input converted to normalized URLs using something like location_to_url
<mgz> passing strings around of various different types does lead to breakage
<vila> so there are already several bugs filed for that and I agree with the goal and I'm not even sure I like allowing remote urls in config files given that  server settings that can be overridden are... unclear
<mgz> I don't think that means we need to use URLs for everything, but certainly we need to know what kind of path is being operated on when displaying it in an error message etc
<mgz> rather than looking at it and guessing
<jelmer> mgz: we do seem to need some guessing here, so I'd rather have it in one spot (location_to_url) than in multiple places
<vila> so when I say out-of-scope, I don't mean I don't care, it's just that this proposal is not about this topic
<vila> readonly+file is probably already a bug with locations.conf :-/
<jelmer> vila: I disagree, it adds more code that does this - and I think doing it properly is as much or perhaps less work than the current MP
<mgz> well, we can guess (or rather have a clear process) when the url enters bzrlib from the user (command line, config file, etc)
<mgz> s/url/path, url, or filename/
<jelmer> mgz: ah, yeah - I think we mean the same thing
<mgz> but that's... an ideally, not what currently happens in many cases
<mgz> yup, violent agreement
<vila> jelmer: well, I tried changing it while migrating locations.conf to config stacks and... encountered some ugly cases (sorry I can't remember the details right now) but it wasn't that easy
<mgz> hm, too many branches named "fix...."
<vila> looking at the config bugs: bug #85479 #359320 #437009
<ubot5> Launchpad bug 85479 in bzr (Ubuntu) "configuration location lookup does not take care of url encoding" [Medium,Confirmed] https://launchpad.net/bugs/85479
<vila> looking at the config bugs: bug #85479 bug #359320 bug #437009
<ubot5> Launchpad bug 359320 in Bazaar "Paths with links, or relative paths, cannot be used in location.conf." [Medium,Confirmed] https://launchpad.net/bugs/359320
<ubot5> Launchpad bug 437009 in Bazaar "locations.conf has problems with Windows paths with backslashes" [Medium,Confirmed] https://launchpad.net/bugs/437009
<mgz> nice set vila.
<mgz> incremental cleanups are fine, I've not looked at your branch yet, will shortly
<vila> yeah, right, as said above, it's not as if I don't care about the issue
<vila> jelmer: I agree that I use the same pattern as locations.conf but I did on purpose so any fix in one should go into the other and hopefully even more code can be shared but I wanted a simple proposal
<mgz> ow, builddeb makes a bt.test_selftest test fail
<mgz> it's.... a relative import issue! :D
<mgz> plugins/builddeb/util.py", line 32, in <module> from distro_info import DebianDistroInfo, UbuntuDistroInfo
<mgz> already fixed?
<jelmer> mgz: I don't think that's a relative import issue
<jelmer> mgz: distro_info is a top-level package
<mgz> ah, I just don't have it then.
<vila> mgz: and yeah, urls enter bzrlib in different ways, config files are utf8 but provides unicode, btw https://code.launchpad.net/~vila/bzr/907279-override-from-env/+merge/86737 has landed but I'll still welcome your comments about 'env_encoding'
<mgz> what's the lp: name for it?
<mgz> vila: will do, can probably simplify the encoding side a little now with some of the other changes (rather than previous tack of having lots of different possible encodings for different things)
<vila> mgz: yeah. your functions have the right stuff but the API doesn't quite fit what config is expecting, there is probably an easy middle ground though
<vila> hmm
<vila> more network issues on a different machine now :-/
<jelmer> :(
<mgz> okay, that's made a bit of a dent in the review queue
<jelmer> mgz: thanks
<vila> transient DNS failure ? Do such things really still happen ? :-}
<vila> jelmer: gha, look at smart/server.py line 360 :-(
<vila> jelmer: on the bright side, grep returns ~50 hits for local_path_from_url so there is still hope
<vila> jelmer: anyway, did I convince you I care about this stuff ? I already added a test with a location starting with file:/// (look at the last rev I pushed before my last comment), would you be fine with one more test showing that file:///foo is handled as /foo for section ids ?
<vila> jelmer: and also (which may give you some more context), I'm whacking moles fixing bug #832042 already so chasing more moles today... is a bit too much ;)
<ubot5> Launchpad bug 832042 in Bazaar "config files are read for each option" [High,In progress] https://launchpad.net/bugs/832042
<mgz> okay, my issue with StartingPathMatcher vila,
<mgz> is that I'm not sure if it's just trying to operate on local paths, or whether the if 'file://' check is intended to let other absolute urls through
<vila> . o O (Amazing how apparently simple proposals can raise so many issues ;)
<vila> mgz: same as locations.conf,
<jelmer> vila: I think this is just a single issue with it - it keeps the brokenness that's present in the previous implementation
<vila> mgz: the aim is (and was) to allow paths where internally we also deal with urls
<jelmer> vila: I never questioned whether or not you cared :)
<vila> hehe
<mgz> which would be weird, because then the self.location could be either a url or a filesystem path when the slash handling goes on
<vila> jelmer: but I can't fix all brokeness at once ;)
<mgz> vila: the problem is the proposal isn't also deleting the old logic, so it's not clear you're not to blame :)
<vila> mgz: yeah, not super pretty, I know, but that's what we have
<vila> oh my deleting the old logic will have to wait for all plugins to stop using the old implementation....
<mgz> right :)
<vila> well, for bzr itself to stop using it to start with
<vila> I fired that one to *avoid* reusing locations.conf logic for new config files (the section ordering in this case)
<vila> because I didn't want to have to deal with this brokeness in /etc/bazaar/defaults.conf or whatever we call it
<vila> I'm not a big fan of using urls in config files either mainly because the smart server ignore many options coming from there
<mgz> anyway, this is livable with, provided you define in the docstring what 'location' may be in practice, and add some XXX about making this saner
<vila> yeah, there are 2 call sites: initial location conversion, section id conversion, we need a bunch of tests around these anyway (the bugs I mentioned above are also around these calls)
<vila> .. and I haven't mentioned allowing relative paths there either ;)
<mgz> just enumerating what doesn't work and listing bugs right there would help
<vila> ... which open another can of worms: if these paths are inside a bzr tree, should we apply the renames too ? ;)
<mgz> right now, the code has various assumptions and it's not clear what they are
<jelmer> I think that would reduce some of my concerns about this code as well
<vila> right, I'm slowly discovering pitfalls and trying to make them clearer
<vila> \o/
<jelmer> I'm still not convinced that doing it right would actually be that much harder than what you have at the moment, but I'll defer to your judgement on that
<vila> yeah, may be I resigned too soon last time or may be too many issues were making it harder to understand...
<vila> I remember having to followup once or twice after my first attempt landed
<vila> but I was focused on minimizing differences between the old and the new implementation
<mgz> that's the kind of thing that is also useful to say in a docstring
<vila> at least now, it's all contained in a single class
<vila> 'that' ?
<mgz> "logic intended to be compatible with previous implementation config.olf_function"
<mgz> or similar.
<mgz> olf? old.
<mgz> I think the sky castle here is something like urlparse and poping from the tail to determine heirachy
<mgz> after converting input string to url from relpath etc
<vila> instead of just startswith ?
<mgz> clearly just looking at the path section one segment at a time is enough for nearly all cases though
<vila> not to mention globs :-/
<mgz> yeah, so you could say that http://example.com/bzr/branch?why=1/2 is in the same line as http://example.com/bzr/branch
<vila> the former starts with the later
<vila> oooh, jelmer, did you have some colo use case in mind ?
<mgz> ah, I see, but then say that http://example.com/bzr/branch_X isn't in the same line
<vila> yeah :-/
<vila> but is it really an issue ?
<mgz> colo has kicked up a bunch of issues around this by wanting to stick stuff on the end of locations
<vila> and potentially in the middle too
<jelmer> mgz: colocated branch names don't have slashes in them though
<mgz> you have a bug report requesting that :)
<jelmer> mgz: slashes have to be urlencoded
<mgz> say you wanted a location config for all your colo branches named 'trunk'
<mgz> would you invision having a section like [file:,branch=trunk] with rules?
<mgz> that's a relative path, not a glob
 * mgz ponders
<vila>   /path/asdfasdf/*/trunk
<mgz> would you invision having a section like [file://*,branch=trunk] with rules?
<jelmer> mgz: I think the latter makes most sense, probably
<jelmer> mgz: I don't think colocated branches (or rather, path segment parameters) need special casing
<vila> you have a branch.conf too,
<vila> so the other conf files should not be abused (not to mention you can move your branch and keep your settings)
<jelmer> as an example, I currently always have "email" in branches named "unstable" set to "Jelmer Vernooij <jelmer@debian.org>"
<jelmer> independent of what project they're in
<mgz> heh, I guess the glob would work with branches hidden in .bzr
<vila> jelmer: and this works for colo branches right ?
<jelmer> vila: I haven't tried it for colo branhces, but I don't see why it wouldn't
<vila> me neither
<vila> jelmer: errr, waitasec, what section name do you use for this ?
<jelmer> IIRC [/home/jelmer/src/*/unstable]
<vila> if I'm not mistaken it will fail for /home/jelmer/src/xxx/experimental/unstable
<vila> i.e. locations.conf will match '*' with a *single* path component
<jelmer> ah, I see. So I guess it won't work for colocated branches then
<vila> to match on the colo branch name, no, but to apply to all colo branches yes
<jelmer> anyway, I'm not really worried about that right now :)
<vila> ...hmm, but StartingPathMatcher will match, damn, forgot to mention that... gee
<jelmer> vila: are you sure?
<jelmer> in that case it seems like file://foo/bar will also match file://foo/bars ?
<jelmer> which would be Bad
<vila> well, locations.conf split the path and then try to match each component and also sort on the number of components (my issue with it)
<jelmer> vila: the components won't match for colocated branches
<jelmer> file://bar/bar vs file://bar/bar,branch=foo
<vila> sorry, components from split('/')
<vila> after removing the final '/' if present
<jelmer> right, so colocated branches won't match
<vila> if you have a section named /foo/bar and a branch named file:///foo/bar,branch=baz the section will apply I think, by luck, but apply...
<jelmer> vila: if that is the case, wouldn't file://foo/bars also match?
<vila> if the section is named foo/bar ? It should match
<vila> even /foo/bar/ :-/
<jelmer> urgh
<vila> yeah
<vila> note that nobody complained... yet :-/
<vila> s/yet/so far/
<vila> oh crap, smart server timing out while debugging :-(
<vila> uuurgh,
<vila> I found one cause of smart server calling get_config_file too much:
<vila> in at least one case, both the remote branch and the real_branch will ask for it :-/
<jelmer> vila: we shouldn't be using the real branch anymore in a lot of cases
<vila> I'm working on a branch based on bzr.dev@6404
<vila> the test is bzrlib.tests.per_branch.test_branch.TestStrict.test_strict_history(RemoteBranchFormat-v2)
<vila> hmm
<vila> jelmer: could it be that a failure in the smart server triggers a fallback to real_branch in the client ? I'm having a weird behavior right now:
<vila> I encounter either LockNotHeld errors or SIGPIPE or... no errors but a use of real_branch
<vila> AFAICS only pulls should be triggered, does that requires real_branch still ?
<jelmer> vila: no, that shouldn't require real_branch
<vila> jelmer: not sure if my description makes sense... ask for details if you need
<vila> crap, so some error is swallowed :-(
<jelmer> vila: I'm not sure that is the case, perhaps there's something oither than a pull here?
<vila> the test do commits and pulls
<vila> well, sprout, setting appen_revisions_only to start with too
<vila> ha, and some merge_from_branch
<vila> but all the trees should be local
<vila> (but the branches should be remote)
<vila> if I put breakpoints where LockNotHeld should raise, it stops raising... naughty
<vila> oh, progress, I'm at the raising call site...
<vila> weird, the real_branch is not None but still cannot be unlocked (so still some real_branch involved....)
<vila> jelmer: any advice about debugging lock issues with the smart objects ?
<jelmer> vila: not really, I'm not entirely sure what you're trying to debug
<vila> well, I don't really know myself :-/
<vila> AFAICS I didn't touch any locking stuff
<vila> hmm, or did I *remove* some ?
<vila> hmm, so, I'm working on changing stack.set() to not call store.save() but instead wait until branch.unlock() to save the config file
<vila> so far, I've fixed only a few places in the code and fixed the blackbox tests that were mixing config settings on branch objects and run_bzr() calls
<vila> and I've got all blackbox tests passing, so presumably my fixes are not that bad
<jelmer> vila: you probably need some magic in Branch._ensure_real
<jelmer> vila: a write lock on RemoteBranch can be upgraded to a write lock on the real branch
<vila> the trick is that I don't lock anything anymore (for config purposes) relying on ... damn it, let's try something
<vila> nope
<vila> so, relying on callers to always write lock branches when setting new values for options (which seems  correct so far, except for the tests themselves)
<jelmer> vila: if you do that, you probably want to also assert that the branch is locked when setting new options?
<vila> hmm
<vila> I didn't so far...
<vila> .. fearing useless IOs ??
<vila> which is ridiculous, let's try that
<jelmer> I don't think checking *we* have a write lock causes extra IO
<vila> yup, but it means I need the .branch attribute for BranchStore which I was hoping to get rid of, nm
<vila> hmm, no difference for the current test, but more blackbox failures to deal with
<vila> pfew, 59
<vila> jelmer: any objection on making branch write-locking mandatory to set an option ?
<jelmer> vila: sounds reasonable to me
<vila> (previously we were taking one on the config file itself without involving the branch anyway...(
<vila> ))
<jelmer> mgz: any plans on landing your no_locale_hacks mp?
<mgz> some, still a little concerned about the effect on random scripts using bzrlib directly
<mgz> basically, on nix only, if they don't call setlocale,
<mgz> currently they can do some things involving non-ascii characters, but not open non-ascii files or write non-ascii data to some streams
<mgz> the branch means a few more things won't work unless setlocale is called.
<jelmer> mgz: are you having seconds thoughts about it, or do you have anything in mind to address that?
<mgz> well, could change the fallback value, but that probably does more harm than good for a corner case.
<vila> ok, blackbox failures fixed, the diff is now >1400 lines and I've still to address the ~50 remaining failures :-/
<vila> and the previous test is still failing ;)
<vila> jelmer: another nice suggestion like the previous one ? :-P
<vila> kidding really
<vila> I've found interesting cases with this one ;)
<jelmer> vila: perhaps split out the change to require a write lock for config changes?
<vila> oh, I will split out the change, there are already 4 or 5 mps in my wip
<vila> and many controversial changes... like,
<vila> if you have read-access only to a branch you cannot push it anymore...(well, unless you had write access when you set push_location)
<vila> or the fact that we save some config settings even if the operation fails
<vila> on the bright side, some hpss_calls went down !
<jelmer> :)
<vila> O
<vila> M
<vila> G
<vila> RemoteBranchStore you idiot !
<vila> ...and I stay polite
<vila> I completely missed to do the same changes I did on BranchStore
<vila> @only_raises is evil
<jelmer> yep
<mgz> ehehe, naughty jelmer
<mgz> went with 'stronk' for the branch name :)
<vila> that's where I lost the exceptions I was searching for...
<jelmer> mgz: stronk is dutch for "branch" :)
<jelmer> mgz: strong was the typo, not the other way around :)
<mgz> ehehe
<vila> of course, now that I know,  calling store.save_changes() in unlock()... cannot fail with that ;)
<mgz> hm, should probably just do this change, it's low impact
<bzr-RM> jelmer: woohoo !!!!
<vila> :)
<jelmer> vila: hmm?
<vila> noticed your what's new update ;)
<jelmer> ah :)
<glen> hi, how new bzr i need here to merge then? http://pastebin.com/hM6mWAs9
<glen> it says i need 1.16 or newer, i have 2.4.2 and it's not new enough still?
<jelmer> glen: your repository locally is too old
<jelmer> glen: you probably want to run "bzr upgrade"
<glen> but i just checkouted it (branched it)
<jelmer> glen: the remote repository that you cloned was probably also in an old format
<glen> how do i upgrade remote repo?
<jelmer> glen: "bzr upgrade <url>"
<glen> "bzr upgrade lp:eventum" ?
<jelmer> yep
<glen> i need lots of bandwidth for that too?
<jelmer> For launchpad branches I think there is also a link on the branch page that can do it for you
<wgz> vila: I'm reasonably sure your odd babune debug-windows failures are pyx drift
<glen> jelmer: but how fresh version it lp web updates to? i need 2.0.4 support
<wgz> vila: tests pass here, failure makes no sense, and module path goes from "c:\cygwin\home\babune\babune\slaves\xp-32bits.local\workspace\debug-windows\bzrlib\workingtree_4.py" to "_dirstate_helpers_pyx.pyx"
<wgz> which implies a dirty cwd, but the error is still weird
<wgz> glen: the current format works with 2.0 clients still
<glen> does bzr have concept of svn:eol-style ?
<wgz> no, but you can set a similar thing globally for your local branches
<wgz> see <http://doc.bazaar.canonical.com/beta/en/user-reference/eol-help.html>
<wgz> vila: previous reference to these failures (thanks email search) <https://code.launchpad.net/~gz/bzr/url_unquote_unreserved_842223/+merge/82309/comments/177821>
<wgz> hm, I see, it's building with cygwin's gcc, and pyrex not cython
<wgz> so perhaps the failures relate to that, the debug-windows setup is not the same as the selftest-windows setup maybe?
<wgz> hm, random poking isn't getting me anywhere, but does show that the .pyx file being used isn't the one from the build process I think
<wgz> enough for today.
#bzr 2012-01-04
<vila> wgz: windows slave seems in better shape, as for debug-windows, a bare 'make' has been deleted, just restored it and running a test right now
<vila> wgz: i.e. removing the 'import win32utils' was the only needed bit apparently
<vila> wgz: oh, and having jenkins version controlled made it trivial to detect the removed 'make' which is a very good example of why I dislike clickety GUI to define jobs
<vila> wgz: 'make clean' does not delete .pyd, cleaning up the debug-windows workspace manually was required, something fishy there but probably not worth digging for now
<vila> wgz: in the other hand, http://babune.ladeuil.net:24842/job/debug-windows/102/console may give a hint about the (subunit/testtools ?) stream leak
<vila> s/in the/on the/
<mgz> morning all
<vila> hey mgz :)
<vila> mgz: let me re-paste previous remarks
<vila> <vila> wgz: windows slave seems in better shape, as for debug-windows, a bare 'make' has been deleted, just restored it and running a test right now
<vila> <vila> wgz: i.e. removing the 'import win32utils' was the only needed bit apparently
<vila> <vila> wgz: oh, and having jenkins version controlled made it trivial to detect the removed 'make' which is a very good example of why I dislike clickety GUI to define jobs
<vila> <vila> wgz: 'make clean' does not delete .pyd, cleaning up the debug-windows workspace manually was required, something fishy there but probably not worth digging for now
<vila> <vila> wgz: in the other hand, http://babune.ladeuil.net:24842/job/debug-windows/102/console may give a hint about the (subunit/testtools ?) stream leak
<vila> <vila> s/in the/on the/
<mgz> yeah, seemed like the compiled modules were just sticking around from an older build and breaking things
<vila> yup, caused by the removed 'make'
<vila> but debug-windows jobs 100, 101, 102 failing when no tests failed... ?
<vila> jelmer: around ?
<mgz> vila: I'm not sure on that, I only messed around with the make calls after a few runs had already failed
<vila> ha !
<vila> dependency not correctly tracked then ?
<mgz> I had the setup sh script, followed by make realclean; make for a couple of the runs
<vila> realclean deletes the .pyd files ?
<mgz> it should, but doesn't
<mgz> (clean should, but doesn't)
<mgz> basically, the makefile isn't written to work on windows
<mgz> but something else is going on as well I think
<mgz> vila: possibly something is wrong with the pipeline for subunit handling
<mgz> (causing the 'lost connection' issue)
<mgz> the output text on the server at least contains \r\n and \r\r\n rather than the expected line endings
<vila> ha ha, progress ?
<vila> 'server' ?
<mgz> if you do view console output as text on babune and download it
<vila> wow
<vila> that's *inside* the multipart stuff, wth ?
<mgz> might be after the fact mangling, it's not completely clear
<mgz> I note the current selftest template doesn't run ./bzr selftest but has a sh script for that as well
<vila> yup, part of the babune branch bin/selftest.sh
<vila> do you want a paste ?
<mgz> no, it's alright
<mgz> well, can look
<vila> http://paste.ubuntu.com/792536/
<mgz> anyway, this is mostly output log-cosmetic, the junit xml gets generated correctly
<mgz> so I'm guessing it's the 2junit | 2pyunit pipe at fault
<mgz> I bet splitting into ./bzr selftest > out; 2junit < out; 2pyunit < out; would work.
<mgz> subunit probably forgets to set binary when forwarding from the filters?
<vila> breaking the pipe means no report while running selftest, better if we can avoid it in the end, yeah, or one of the filters forget to set binary
<mgz> yup, that'll be it.
<mgz> what's the easiest way to try out a fixed subunit on babune?
<vila> ask me :)
<vila> the always-falling-down-in-the-stack next task for babune is to add setup/deployment step that could be used for that kind of tests
<vila> I'm using subunit revno 151 for now
<vila> could probably update to 156 if it helps
<vila> testtools revno 224, same remark
<mgz> vila: lp:~gz/subunit/binary_forward_stream
<mgz> shouldn't need to update testtools
<vila> meh, there is already an unconditional make_stream_binary two lines above ?
<mgz> it's for a different stream :)
<mgz> ...I didn't change it
 * mgz corrects
<mgz> pull --overwrite as I'm pretending I never made that mistake :)
<mgz> thanks for checking vila :)
<vila> pull -ooverwrite and I don't know what mistake you're talking about
<vila> the reason I checked is that I wanted to cherry-pick manually for the test ;)
<vila> running at http://babune.ladeuil.net:24842/job/debug-windows/104/console
<vila> looks pretty good no ?
<mgz> much more like it
<mgz> will propose branch for merging
<vila> Really looks pretty good to me and jenkins agrees :)
<mgz> thanks vila!
<vila> omg, thanks to you !
<vila> this one has been such a pita...
<vila> ... for so long
<vila> running a windows full test suite to celebrate ;)
<vila> gee, I'm so glad I nudged you on the reduced run...
<mgz> I have a nasty feeling I broke this in the first place...
<vila> bah, as long as it's fixed now...
<vila> and remember it has been there for.... ages
<vila> and 'False' for a default value stream.... is suspicious at best
<mgz> yeah, I'm guessing that's why I made the mistake, why would you want to set binary on a boolean?
<vila> indeed
<vila> another case for doc not matching code ;)
<mgz> okay, I'm out over lunch for a bit
<vila> jelmer, mgz: https://code.launchpad.net/~mbp/bzr/261315-stacked-hpss weird warning there...
<vila> did we break compatibility with BzrBranch6 format at one point ?
 * jelmer looks
<jelmer> vila: not that I'm aware of
<jelmer> vila: I don't see how that's related to BzrBranch6 though
<vila> ha, sorry
<vila> well, it seems our parametrized tests (for smart server) covers only BzrBranch7 and 8
<vila> and... damn, what was it...
<vila> while debugging yesterday I went across some piece of code that made me think that the smart server was more or less not supporting anything older than that for branches
<vila> coming cross the branch above while trying to understand why Branch.get_stacked_on_url was always called for smart branches
<mgz> you mean that it's out of date?
<vila> it may just be that this branch is stacked on the old trunk
<mgz> yeah.
<vila> and something broke around that
<mgz> that's the context I've seen that note in before
<vila> ha, good enough then
<jelmer> hah
<jelmer> commit in lightweight checkouts, from 220 to 30 roundtrips
<jelmer> with Vincent's config changes, that'll probably end up < 25
<vila> BOOM
<vila> \o/
<vila> emacs devs (among others) will be delighted :)
<vila> jelmer: just found back the bug that makes me hesitant to say we support subtrees in 2a: bug #634470
<ubot5> Launchpad bug 634470 in Bazaar "bzrdir.destroy_workingtree ignores conflicts (which means that subtree support is broken for treeless branches)" [Medium,Confirmed] https://launchpad.net/bugs/634470
<vila> jelmer: but I can't find your merge proposal about that anymore...
<vila> jelmer: also look at comments in test_sprout_recursive_treeless in bt.test_bzrdir
<jelmer> vila: I don't think we'll be able to use the 2a working tree format for nested trees
<jelmer> but we should be able to use the 2a repository format
<vila> ooooh, sry for the misunderstanding then
<vila> jelmer: ... but what's the point of having a repo we can't checkout from then ?
<vila> hmm, I mean, you surely have a use case in mind, what is it ?
<Wiz_KeeD> hey guys!
<jelmer> hi Wiz_KeeD
<Wiz_KeeD> hello jelmer
<Wiz_KeeD> i'm going to ask a noob question for which i might be accused but here goes, after downloading a branch (from launchpad) to just update it to the lastest revision
<Wiz_KeeD> do i still use bzr branch and be in the same place with the dir that has the same name
<Wiz_KeeD> ?>
<mgz> nope, you use `bzr pull`
<jelmer> Wiz_KeeD: if you want to update an existing branch you created with "bzr branch", you can use "bzr pull"
<mgz> from inside the directory where you created the branch
<Wiz_KeeD> so i do bzr pull lp:blabla in that directory, but is there something wrong using branch to pull an existing branch?
<mgz> `bzr branch X` means 'create a new branch of X in a new location
<mgz> `bzr pull` means get the newest revisions of a branch existing in the current directory
<mgz> they're for different situations.
<Wiz_KeeD> i should have paid more attention, i intend just to get the latest version and use it, thus pull is for me
<fullermd> Also, you don't need the lp:Blah on pull.  It'll pull from where you branched from automatically.
<mgz> generally you use branch once to get a copy of someone else's work, then pull thereafter to keep it updated
<Wiz_KeeD> so i did good by using branch first?
<Wiz_KeeD> or should i have used pull from the getgo
<fullermd> 'branch' is how you get the branch in the first place.  'pull' is how you update it once you have it.
<Wiz_KeeD> then i've got a good start
<mgz> yup.
<Wiz_KeeD> now i just need to use pull
<Wiz_KeeD> what about checkout, what's that about?
<fullermd> That's a whole different thing that will probably just add confusion to talk about.
<Wiz_KeeD> i know it's different i was just asking cause someone asked me if i had used that
<Wiz_KeeD> and i use bzr pull inside the directory which was created by bzr branch?
<mgz> Wiz_KeeD: that's right.
<Wiz_KeeD> that's cool, at least now i have some sort of control :D
<mgz> okay, fun done for the day
#bzr 2012-01-05
<wgz> happy unmorning
<wgz> bus time.
<vila> hi all !
<mgz> morning!
<vila> mgz: hey !
<vila> mgz: Is this the day you can tweak the pqm conf ? :-D
<mgz> yes.
<mgz> ...though, did we get anything out of mthaddon about where the right place to look is?
<mthaddon> eh?
<vila> mthaddon: there is a config file for pqm where we can set some bzr options to avoid conflicts in our news file, we don't know where exactly but we know the settings are wrong or not recognized :)
<mthaddon> vila: so what do you want to see?
<vila> mthaddon: the pain point for us is that the submission fails, we merge locally (with the right settings and hence no conflicts)  and resubmit
<vila> mthaddon: it's probably either a locations.conf or pqm.conf file which mentions the various branches
<mthaddon> vila: sure, but what value are you interested in in the PQM config?
<vila> more probably locations.conf, the misunderstandings we have is which one is taken into account when the merge occurs
<mthaddon> pqm@cupuasso:~$ cat .bazaar/locations.conf
<mthaddon> [/srv/pqm.bazaar-vcs.org/archives/thelove]
<mthaddon> post_commit_to = bazaar-commits@lists.canonical.com
<mthaddon> that's all there is in locations.conf
<vila> hmm, are the 2.x branches *below* thelove ?
<mthaddon> vila: that's the entire contents of the file
<mgz> the one we looked at previously was https://pastebin.canonical.com/57193/
<mgz> which is not the current one, then.
<mthaddon> so that was probably from the previous server
<vila> right, so we need more sections there for trunk at least, and ideally for 2.4, 2.3 etc
<mgz> okay, that's what we need to know, can bug gnuoy in a second to do the changes we want
<mthaddon> vila, mgz: can you create an RT with what you need - we'll want to make sure the added configs are puppetised
<mthaddon> please don't just have it added manually, or it'll fail if we ever have to move PQM again
<vila> so [/srv/pqm.bazaar-vcs.org/archives/thelove/+trunk] (not sure about the + there :-/)
 * vila nods
<vila> and news_merge_files = doc/en/release-notes/bzr-2.5.txt there (which will need to be updated when we start the 2.6 series, so definitely we want that to be puppetised)
<mgz> do we want a section per release with the right files, or how would be best to manage this vila?
<vila> jelmer, mgz: no laughing about my ignorance for url encoding in section names for locations.conf please ;-P
<vila> one section per branch, I'm not sure pqm always preserve them so putting this option in branch.conf may be brittle (and I'm not even sure it's queried)
<vila> them == the branches
<mgz> okay, if you file the rt vila, I'll assist as needed when making the changes
<vila> ha, let see if I can do that with an email mentioning the right people in CC
<vila> mgz: sent, let me know if you receive it *and* if you also get notices from rt after that
<mgz> vila: first mail arrived
<vila> mgz: cool, note that these settings comes from a known working laptop so apart from the section names that needs to be updated it should be good
<mgz> I think we don't need anything before 2.3 now
<vila> we shouldn't
<vila> on the other hand... if it doesn't seem too much trouble to add them too (if only to remember where the switch from NEWS occurred)
<mgz> that's true, but it might be knowledge the l-osas could do without
<vila> up to you :)
<mgz> is tools/http_client.py still used by anyone or anything?
<vila> I don't think so
<jelmer> me neither
<vila> blow it away, it's under version control :)
<mgz> jelmer, can you paste whatever pqm complained about with your ssl branch to the mp?
<mgz> seeing 'sent to pqm by email' as the last comment when nexting through approved reviews in hydrazine is slightly confusing
<jelmer> mgz: so, I tried twice
<jelmer> and both times I got an error from subunit saying that the test runner fell over
<mgz> fun... putting what it said in the mp certainly seems useful then
<jelmer> mgz: sure
<jelmer> vila: hmm, did we not always apply quilt patches in udd?
<vila> jelmer: hmm, my understanding was that the packagers decided what they track... applied or unapplied
<vila> but to be honest I don't know where exactly this is done
<jelmer> vila: we have to have a policy on what we do when we import packages though
<vila> should we ? Or should we have an option so packagers can still decide ?
<jelmer> vila: we already have a policy at the moment :) I'm just trying to find out if that policy has changed at some point
<vila> I'd say go with whatever works for you as long as it doesn't break existing workflows
<vila> oh, we have ? Always apply ?
<jelmer> vila: this is about whether we version with patches applied (and create .pc/) or not
<jelmer> nevermind, found it
<jelmer> we only apply patches for 3.0 (quilt) packages, not for packages that use other patch systems
<vila> I thought .pc wasn't required if either all patches were applied or not (i.e. required only when some of them are applied)
<vila> ha
<vila> but then we apply them all, right ?
<jelmer> I think .pc is always required if some patches are applied
<jelmer> I would like to see us move to not applying patches, but I'm not sure what the best approach to that is
<vila> and applying them automatically when needed ? I thought barry was preferring working with patches applied...
<jelmer> vila: yes, hooks for e.g. transform to apply them when we create a checkout or update
 * vila freaks a bit about conflicts...
<jelmer> if applying one of them fails we just warn the user and let them deal with applying the patch
<vila> and do so (from the hook) only if not conflicts are present right ?
<jelmer> right, or if there are no conflicts present involving the files touched by the patch
<vila> more delicate to get right and entering a thin ice zone
<vila> the usual pain point is: you have uncommitted changes, do something, and suddenly you cannot revert this 'something' and you cry
 * vila wishes there was an easy way to do some sort of commit-so-I-can-revert-but-dont-pollute-my-history
<fullermd> That's what colo is for  ;p
<mgz> +15/-1312
<jelmer> vila: you can go back since the state is tracked in .pc/
<vila> jelmer: oh, so if quilt create conflicts you can't 'bzr resolve' them ?
<vila> mgz: ??
<vila> fullermd: almost ;)
<mgz> left a few merge proposals for you to review while I have lunch vila :)
<vila> pfew, I would not have guessed ;)
<mgz> whoops, that's the problem with doing lots of merge proposals at once, I mixed up the descriptions...
<vila> hehe, for once, may be you could have done a single one ;)
<vila> mgz: and what is the python name ? utf-8 (lowercase ?)
<mgz> yup.
<vila> k
<mgz> saves worrying about the nine billion names of ascii
<mgz> slight hyperbole, with case and dash normalisation already done, python accepts:
<mgz> ['iso_ir_6', 'ansi_x3_4_1968', 'ibm367', 'iso646_us', 'us', 'cp367', '646', 'us_ascii', 'csascii', 'ansi_x3.4_1986', 'iso_646.irv_1991', 'ansi_x3.4_1968']
<vila> 86 or 68 ? To catch tyops ?
<Wiz_KeeD> hey guys
<Wiz_KeeD> can any of you tell me how i can go back 1 revision with bzr?
<Wiz_KeeD> i just made a pull and i think there are some bugs
<mgz> vila: pqm news merge
<mgz> with your new fancy config path segment thing
<mgz> ah, nope, doesn't help for trunk...
 * mgz scratches thought
<vila> put some trust in the old one, it has worked for quite some time :)
<vila> err, by old one I didn't mean me or fullermd, but the old locations.conf ;)
<mgz> vila: where's our current document for things to do when creating a new bzr series?
<vila> releasing.txt but there is a losa wiki page, let me see
<Wiz_KeeD> can anyone tell me how i can revert to the version before i did pull?
<vila> Wiz_KeeD: bzr pull --overwrite -r<my-precious>
<Wiz_KeeD> what's my previous? :))
<Wiz_KeeD> the number of the former revision
<vila> precious :)
<vila> generally yes
<Wiz_KeeD> how do i find out which one was it
<vila> if you have the bzr-tiplog plugin installed 'bzr tiplog' will tell you,
<vila> otherwise, 'bzr pull' *did* tell you which version was current before the pull
<vila> if you didn't notice, .bzr.log should still contain it
<vila> 'bzr info' will tell you where to find it
<vila> (the .bzr.log file that is)
<vila> alternatively, try 'bzr qlog' and see which one it was
<Wiz_KeeD> unknow command
<vila> (qlog is part of the qbzr plugin and you will love it ;)
<Wiz_KeeD> apt-get install qbzr?
<vila> should do
<Wiz_KeeD> bzr info doesn't tell me about the log
<vila> meh, typo, I meant 'bzr version'
<mgz> vila: was there any other reason not to use branch.conf for the news merge other than we were worried about it not working?
<vila> yes,
<vila> I'm not sure the branches on pqm are not scratched on occasion
<vila> meh, too many negatives
<vila> I suspect, the branches on pqm can be deleted sometimes
<mgz> they may be, but it seems like there's config setup to populate them with the right values
<vila> really ?
<vila> how ?
<mgz> various puppety thingies
 * mgz keeps it technical
<vila> hehe
<vila> all I'd like to know is whether a branch.conf file is created of if bzrlib is involved to populate it
<Wiz_KeeD> i see no version number in the log
<vila> Wiz_KeeD: can you find the offending pull ?
<Wiz_KeeD> how can i do that?
<vila> in the log file, each command output additional info, starting with its name and the parameters used
<mgz> news merge puppet changes made, we should try something to see if it works in a sec vila
<vila> \o/ err, no wait -o-
<Wiz_KeeD> wut?
<mgz> vila: done. have you got a change we can land that would fail without news merge, but succeeds with it?
<vila> ha !
<vila> no :)
<vila> https://code.launchpad.net/~vila/bzr/832046-globs-store-ordered/+merge/86734 possibly :)
<vila> or may be I can tweak it for this purpose
<mgz> that would be neat.
<vila> Wiz_KeeD: bah, I mixed uncommit, pull and a merge proposal that wanted to display the revision *before* the pull
<vila> Wiz_KeeD: qlog is your best bet to find your previous revision now
<Wiz_KeeD> lol...
<mgz> bug 912344 looks like one for you vila
<ubot5> Launchpad bug 912344 in QBzr "Bazaar explorer crashes when in browse and I try to show annotate on a file" [Undecided,New] https://launchpad.net/bugs/912344
<mgz> did set_user_option accept numbers previously?
<vila> it should
<vila> meh, or not ??
<vila> wow, so, bug #912344 is a bug in bzr that is triggered only for smart branches
<ubot5> Launchpad bug 912344 in QBzr "Bazaar explorer crashes when in browse and I try to show annotate on a file" [Undecided,New] https://launchpad.net/bugs/912344
<vila> the new implementation shouldn't suffer from it
<vila> the trick is... better explain that on the bug ;)
<vila> mgz: got it conflicting without the setting and merging properly with
<vila> mgz: I'll need to properly restore the right order after merge :)
<mgz> vila: net
<mgz> +a
<vila> care to review it ? ;-p
<vila> I think I've addressed the points raised in the discussions
<vila> mgz: ^
<vila> jelmer: you did review my monster cleanup ! You're a hero :-D
<mgz> vila: what do you want reviewed sorry?
<mgz> the globs branch?
<vila> https://code.launchpad.net/~vila/bzr/832046-globs-store-ordered/+merge/86734
<vila> oh crap, I should push the tweak
<vila> done
<mgz> approved, let's try it out
<vila> the new tests shouldn't break on windows... unless local_path_from_url involves disk access ?
<mgz> local_path_from_url may throw on an invalid file:/// url, which those are on windows
<mgz> I'd test it, but I'm afh
<mgz> so, may as well let babune tell us
<vila> k, will monitor
<vila> mgz: osx slave is a bit busted but the last run add 2 more failures you may want to look at http://babune.ladeuil.net:24842/job/selftest-osx-10.6/400/
<mgz> thanks vila, will check
<vila> hmm, 3 even, the 8 other are weird, I should have looked sooner :-/
<mgz> vila: the two test_locale failures are a deliberate change, just missed updating/killing the tests
<vila> cool
<vila> the test_mv_dirs_non_ascii looks older
<mgz> the bb.test_commit failure might need a require-filessystem-that-doesn't-normalise
<mgz> it's a new test, that just happens to hit our existing osx non-ascii filename issues
<mgz> do you know how this is handled elsewhere?
<vila> the others appear when I fix the race in revno 6337 ???? non-sense
<vila> justasec, I think there is a feature already for that no ?
<vila> nope, but CaseInsCasePresFilenameFeature should give some hints
<mgz> or I can work around by not using a character that decomposes :)
<mgz> \xa7 is the best!
<vila> ... and lose the opportunity to fix a bug ? ;)
<vila> or is it really a bug in the test ?
<mgz> ...I may tackle the root issue at a future junction :)
<vila> hehe
<mgz> it's the bug with all handling of names on OSX where NFC(s)!=NFD(s)
<vila> with ExpectedFailure_on_osx: :)
<mgz> in this case it's not the issue we're concerned about, so there's no point tickling it in the test
<vila> I was kidding ;)
<mgz> :)
<mgz> I'm not sure what to do about the locale tests for OSX
<mgz> previously on OSX, if LANG was none, we used utf-8
<mgz> now we also use UTF-8 if LANG is C or something bogus
<vila> sounds reasonable
<vila> right now, I'm connected to an osx host via ssh and locale is C
<mgz> but I XXXed for nix rather than doing the same change, as it's less pervasively unicode supporting
<vila> but it's pretty hard to get there ;) Most of the time you get some utf8 variant
<vila> well, when I say locale is C... http://paste.ubuntu.com/793954/
 * vila blinks
<vila> getaddrinfo doesn't recognize 'localhost' but still accept '127.0.0.1
<vila> on osx that is, but still, end of internet predicted or what ?
<mgz> heh. well, use the number then, and be happy.
<mgz> fix for one of the failures sent, home time now.
<vila> AFAIK we used the name for years... Have a safe trip !
<vila> wgz: In case you read the logs, the merge failed with a conflict in the release notes :-/
<wgz> vila: any sign from pqm if the news merge was invoked at all?
<wgz> I know that spiv tried previously to get it enabled and ran into some issue, but I don't know what it was.
<wgz> hm, my last merge failed too, on:
<wgz> error: bzrlib.plugins.launchpad.test_lp_directory.TestDebuntuExpansions.test_bogus_distro [ multipart
<wgz> InvalidHttpResponse: Invalid http response for https://xmlrpc.launchpad.net/bazaar/: Unable to handle http code 502: Bad Gateway
<jelmer> intermittent issue with launchpad availability?
<jelmer> it's pretty bad we have tests that connect to launchpad :-/
<wgz> yeah...
<vila> <vila> wgz: In case you read the logs, the merge failed with a conflict in the release notes :-/
<vila> mgz, jelmer: for pqm, yes, test suites can be far more agile than what we do on pqm, we should make the launchpad tests run only when some flag is active
<wgz> vila: I replied :)
<vila> ha, sorry, misunderstood
<vila> so, the mail is pretty terse and I don't think the plugin outputs anything outside of the log so...
<vila> Conflicts during merge: Text conflict in doc/en/release-notes/bzr-2.5.txt
<vila> is all I have ;)
<vila> wgz: did you set the options in branch.conf or locations.conf (both should work anyway, I've checked the code)
<wgz> vila: branch.conf
<vila> my little daemon giggles... but refuses to tell me why, damn it
<spiv> wgz: the issue was "turned it on but nothing happened"
<spiv> wgz: and it wasn't really worth sinking a heap of time into trying to debug it
<lifeless> remember that pqm uses a temp dir to do the work
<Noldorin> hi jelmer
<wgz> spiv: well, at least that's consistent with today's observations then... :)
<spiv> wgz: we backed out the changes that attempted to turn it on
<spiv> wgz: also, we changed to the release-notes layout for news since then
<spiv> wgz: so the old config wouldn't have triggered anyway if it had been working as intended.
<spiv> (Also, because we now have a file per release series the conflicts aren't as common/painful)
<wgz> spiv: I still need to merge bzr.dev before writing release notes for too many of my branches, but the plugin may not be a complete panacea there
<wgz> the change we tried today set the location to the right place in each of the active branches' branch.conf
<spiv> wgz: well, it's easy enough to find out how much it hels
<spiv> *helps
<spiv> wgz: when you find a merge that fails due to a conflict, retry it locally with the plugin configured and see if it takes care of it :)
<wgz> well, it seemed to not have any effect at all... how do we distinguish pqm not having the plugin enabled and the plugin not having done useful resolution?
<wgz> vila tried the merge locally before submitting the test branch
<spiv> wgz: right, that's partly why it's a PITA to debug.  I *think* the plugin now at least logs something to .bzr.log
<spiv> There's a bug about making it explicitly say something on stdout as part of the merge output
<wgz> we'll have another crack tomorrow... but stdout for merge plugins would be nice indeed.
<spiv> Something like: M doc/release-notes/bzr-2.6.txt   [merged with news_merge]
<spiv> You should at least be able to verify that the plugin is being *loaded* by looking at .bzr.log
<wgz> hopefully the .bzr.log for pqm operations is straight forward to access
<wgz> thanks for the input spiv!
#bzr 2012-01-06
<YokoZar> Does bzr 4.2.2 fix this crash over 4.2.0 (currently live on launchpad build daemons): https://launchpadlibrarian.net/89179259/buildlog.txt.gz (bzr: ERROR: exceptions.AttributeError: 'cStringIO.StringI' object has no attribute 'split')
<YokoZar> *2.4.2 over 2.4.0
<vila> hi all
<vila> hmm, so, lifeless, regarding pqm, when you say 'pqm uses a temp dir to do the work' do you mean the merge happens in a branch that is created from scratch (but still use some shared repo I presume ?) ?
<lifeless> yes, and no
<lifeless> yes new branch cloned from the target (which is on local disk in the bzr config)
<lifeless> there is no shared repo
<vila> ok
<lifeless> (And can't sensibly be, because the tests run in a chroot
<vila> does this temp branch use a predictable path ?
<lifeless> either the test executing wouldn't have access to the repo, or we couldn't trust the repo for the next test run
<lifeless> vila: yes, it is.
<vila> wgz: ^ here we go, so the settings should go in locations.conf
<vila> lifeless: thanks, do you happen to remember which path is used ?
<lifeless> or make them inherit from branch.conf when a new branch is cloned
<lifeless> uhm, it will be the wordir + -- + the branch name, I think.
<vila> yeah :-/
<lifeless> however
<lifeless> you don't need the exact path
<vila> but we have no mechanism to propagate settings from branch to branch
<lifeless> just set it to / ?
<vila> it is different for 2.5/2.4 etc
<lifeless> why?
<lifeless> can you not just list all the news files and it will do the magic on whichever ones are there
<vila> we can set the news_merge_files list to bzr-2.5.txt, bzr-2.4.txt and so on so it will take the first one that exists in the branch
<vila> :)
<lifeless> it should take them all surely
<lifeless> projects may have more than one file
<vila> should work
<vila> so, summarizing, the merge happens inside the chroot so the chroot locations.conf is where the settings should go, correct ?
<lifeless> no
<lifeless> the merge is done by pqm, the tests run in the chroot
<lifeless> the path that the merge is done in is within what will be chrooted
<vila> ha, so host locations.conf
<lifeless> yup
<lifeless> its a fairly paranoid system
<vila> is it: merge in host/tests in chroot/commit in host or merge in host/commit in host/tests in chroot ?
<lifeless> the former
<lifeless> gpg key for signing is in the host, not the chroot.
<vila> pfew, finally, I think I get it now
<lifeless> it is
<lifeless> trusted code in host, untrusted code in chroot
<vila> yeah, it's always clearer once you understand ;)
<vila> wgz: around ?
<mgz> morning all
<vila> heya mgz !
<vila> You may want to read the logs here to get more understanding of the news_merge issues
<mgz> thanks
<vila> ARGH, http://forums.crucial.com/t5/Solid-State-Drives-SSD/0x00000f4-error-on-M4-64GB/td-p/76392/page/16 discovered less than 2 hours ago seems to kill my SSD just *now* :-( :-(
<vila> screen turned black :-(
<mgz> any better vila? that ssd bug sounds fun.
 * vila backups like mad, hopefully the 1 hour window will allow...
<vila> after that I'll try to re-install on a different /
<vila> with a bit of luck I won't have to unplug it if it's not the boot disk anymore
<vila> alternatively I can migrate my home dir to my laptop and install some alternate mail handling setup and I'll be good for at least next week
<vila> dang it, when I read the report this morning I saw I was at 216.8 days and hoped I would be immune...
<vila> in one sense I'm lucky it happens now instead of next week...
<vila> home backup successful, ticked
<vila> 30 minutes left, what's next ?
<vila> attempting backup to laptop while the clock is tickling (20 mins to go)
<fullermd> Why not just reset the clock back?  Makes it way easier...
<mgz> fullermd always manipulates time :)
<fullermd> Yeah, cesium is my bitch.
<vila> bam, just at the th 1 hour mark :-(
<vila> and screen goes to black a couple of minutes after, definitely the same symptoms :-( :-(
<mgz> vila: babune is down?
<vila> oh yes :(
<vila> that's where it's running
<vila> well, usually :)
<fullermd> Funny.  After all those years of laughing at and then igoring people who kept saying that MLC's very limited erase cycles would never be a problem in practice, it turns out they were absolutely right.
<fullermd> Any SSD is going to have such completely broken firmware/controller that it craps itself long before the flash wears out.
<vila> hehe
<vila> recovery plans needs to be practiced to be effective...
<vila> that's the only way to know they work
<mgz> clearly the fail_after_warrenty_expires() function in the firmware had a date bug
<vila> the amazing part is that I didn't buy it *just* when it was released but more something like several months after that so many more people should have encounter the issue before *me* :)
<vila> this probably means they use theirs on machines that don't stay up 24/7...
<fullermd> What a bunch of wimps.
<mgz> vila: so, on the news merge side
<mgz> do you know where the inside-the-chroot branches are?
<vila> no
<mgz> because I'm not clear from the log what those paths are, the branches we were looking at yesterday were the permanent ones
<mgz> okay, so we need to find that out, then we can explain to gnuoy and try again?
<vila> lifeless said the merge occurs on the host in the branch where the chroot will find it
<mgz> I'm not sure how we know what the right values to put in location.conf are though
<mgz> or how to find out.
<vila> as long as you specify a directory *above* all of them and specify *all* news files, we should be fine
<mgz> ah, okay, so that's a change of thingy
<vila> yeah, my first proposal was conservative but a broader one should work as well
<mgz> perhaps update the rt with new guidance?
<vila> mgz: will do (in the middle of reinstalling so half-working setup on *this* desktop too)
<vila> mgz: what's the rt number ?
 * vila shudders
<mgz> right, after you're all sorted :)
<vila> it seems that even without booting from it, the ssd (m4 crucial 256 GB, let's advertise ;) bricks the desktop after 1 hour
<mgz> the... rt# doesn't seem to be in the email
<vila> 51... something, it shoudl
<mgz> rt #50151
<vila> hehe, just found it by searching my mail *files* (don't want to start my MUA for now)
<vila> crap, can't boot anymore :-(
<mgz> :(
<vila> back to bios ...
<vila> can't enter bios setup ???
<vila> weird, settings have changed their (third reboot was the charm to enter bios setup)
<vila> something related to disk order... could be related to the ssd being awol during boot... may be
<vila> booting now, pfew
<vila> right, disk order have changed indeed, lucky me for using the LABEL trick on all my disks I can keep track of the /dev/sdx used
<vila> mgz: updated
<mgz> cool.
<mgz> jelmer's going hooking mad
<mgz> I still sorta-want a repository open hook, but I'm not sure anyone else would have a need for it.
<fullermd> Yeah, he seems a little hooked up.
<mgz> we might even call him captain hook.
<jelmer> ouch, that are some bad puns right there
 * vila loves hooks
<fullermd> Knew that would hook you in.
<fullermd> Anyway, there are no bad puns, only bad people.
<vila> I just put  one on my wall with a little 'crucial' note on it
<fullermd> Solid plan.
<jelmer> thanks for the review mgz
<jelmer> we should now handle quilt patches much more cleanly if bzr-builddeb is installed
<vila> for those following the m4 crucial saga, booting from another hard drive works, the ssd still goes AWOL one hour after reboot though
<vila> ... and crucial announced a fw update for 2012-01-16
 * vila notes: next time, shut down for 3 more weeks so we get the fw update *before* the crash 
<mgz> what machine is this in exactly vila?
<mgz> not your fancy air thing?
<vila> nope
<mgz> so, won't matter for next week anyway
<vila> my main dev desktop where babune runs
<vila> well, that's where I handle mail too, both fetching and sending
<mgz> email holiday!
<vila> hehe
<vila> I'm blindly re-installing the ~1000 packages that the default install didn't provide...
<vila> ... I wonder if using an SSD there will be faster... err wait
<mgz> jelmer: any ideas on report from buildd issue previously: http://paste.ubuntu.com/794972
<vila> jelmer: seen the debian bug  about pristine-tar for kde tarballs being closed  ?
<mgz> yeah, I did a quiet woho when I saw that in bug mail this morning.
<mgz> AndrÃ© seems to have a talent for finding weird errors, the last .bzr.log he posted makes no sense to me at all,
<vila> can't remember which version we run on jubany...
<mgz> can't tell if all the bzr-svn errors are relevent or not.
<vila> bug # ?
<vila> (still no mail here)
<mgz> bug 814408 comment 5
<ubot5> Launchpad bug 814408 in Bazaar Explorer "Exception "bzr: ERROR: Could not acquire lock" occurs very often. " [High,Fix released] https://launchpad.net/bugs/814408
<mgz> but he ends up with a totally borked tree and dirstate file somehow
<vila> package install finished, let's see what blows up on reboot...
<vila> can't reboot :)
<fullermd> Hey, that means nothing blows up.  Awesome!
<vila> ..unless I power-off, so the trick is that the ssd requires a power off, but then, the bios lose it's boot disk order, fun :)
<fullermd> Gaah.  And so it took me a good minute to figure out why 'bzr diff' wasn't working in a mtn tree...
<vila> teach you to use the right tools ;)
<fullermd> The right tool as near as I can figure, is "strong-arm Samba into moving into mtn, so that jelmer writes bzr-mtn"   :p
<vila> hehe
<vila> pfew, desktop works again, now for all the rest
<jelmer> mgz: sorry, was away for a bit
<jelmer> mgz: that's still waiting for python-debian to be deployed on the buildds
<jelmer> vila: no, I didn't - why?
<jelmer> (why did they close it?)
<vila> jelmer: apparently they fixed it
<mgz> ...ah, it's a pre-python-debian changelog module? I'd expect everything to be broken then.
<mgz> or do other callsites pass str or something?
<vila> jelmer: i.e. a newer pristine-tar should now be able to import the kde tarballs produced on suse
<mgz> I think Joey Hess introduced a binary diff fallback as is used for gzip
<mgz> I didn't look at the change in detail though
<jelmer> mgz: other callsites pass str
<jelmer> mgz: ah, cool
<vila> damn, 1 hour is short :-/
<fbond> So ... the PHP PECL code repository looks like one big shared SVN repo used by all projects.
<fbond> Branching from it with bzr-svn is taking an extremely long time because it is caching all the revisions.
<fbond> Is there any way to make it only download the revisions that actually affect the project I'm after?
<jelmer> fbond: hi
<jelmer> fbond: you can disable the cache completely
<fbond> jelmer: Hello.
<jelmer> fbond: set 'use-cache = False' ~/.bazaar/subversion.conf
<fbond> jelmer: Okay, thanks!
<fbond> jelmer: Much better.
#bzr 2012-01-07
<ccxCZ> is there way to address specific branches in bzr-git?
 * ccxCZ pokes jelmer
<jelmer> ccxCZ: hi
<ccxCZ> hello
<jelmer> ccxCZ: e.g. git://git.example.com/foo,branch=bar
<ccxCZ> bzr: ERROR: Not a branch: "https://github.com/pazz/alot.git%2Cbranch%3Dtesting/".
<ccxCZ> also the uri that git-import created doesn't work
<ccxCZ>   parent branch: https://github.com/pazz/alot.git/,ref=refs%2Fheads%2Ftesting
<jelmer> ccxCZ: what version of bzr and bzr-git are you using?
<ccxCZ> I pulled bz-git yesterday
<ccxCZ> bzr is 2.4.2
<ccxCZ> dulwich 0.8.2
<jelmer> does git://github.com/pazz/alot.gitbranch-testing work?
<jelmer> does git://github.com/pazz/alot.git,branch=testing work?
<ccxCZ> ignoring parameters 'branch=testing', not supported in bzr < 2.5.
<ccxCZ> okay, I guess it's time to upgrade, thanks
<vila> jelmer: nice warning ! :)
<jelmer> vila: the alternative was reimplementing all of the parsing in bzr-git, that didn't seem worth the effort
<jelmer> vila: btw, it looks like our test https server hangs if you try to do a handshake?
<jelmer> ccxCZ: you might need the latest revision in lp:bzr-git, too, for branch= usage with https
<ccxCZ> kthnx
<ccxCZ> atm I have workaround via local git branch, will look into it later
<rgravener> I installed Bazaar on my mac but its not on path, where is it installed?
<Noldorin_> hi jelmer
<Noldorin_> poolie
<Noldorin_> no poolie these days :-(
<jelmer> hi Noldorin_
<jelmer> Noldorin_: I think he's travelling
<Noldorin_> jelmer, ah ok, probably
<Noldorin_> how's it going?
<jelmer> alright, how are you?
<wgz> hey jelmer, have you got my mobile number?
<lifeless> has it changed?
<wgz> nope.
<wgz> nice post of futher joy with signal handlers lifeless
<lifeless> wgz: thanks :)
<jelmer> wgz: hey
<jelmer> wgz: is it in the directory?
<wgz> hm, no, I still need to update (and find a photo)
#bzr 2012-01-08
<Noldorin_> jelmer, good thanks. break from bzr/coding over xmas? ;-)
<Noldorin_> hi wgz
<munchor> hey
<munchor> Similarly to what I can do with git's "checkout", can I change the branch I'm currently working on with Bazaar, so when I "bzr pull", it will pull from the branch I'm working on, and I don't have to indicate it? Thanks.
<fullermd> Yes and no.  Some terminological confusion there.
<fullermd> git checkout is about changing what branch the working tree is 'hooked up' to.  bzr has a 'switch' command that does that.
<fullermd> But bzr pull is about updating one _branch_ to match another.  That it also updated the WT is sorta a side effect.
<fullermd> If you want to change [semi-]permanently which branch your local branch is tracking, pull has a --remember arg that will change the remembered location; that may be what you want.
<munchor> Hm fullermd
<munchor> thanks fullermd
<munchor> bzr pull lp:my-branch --remember
<sjamaan> Hi. I'm having some trouble understanding the bzr API.  I'm trying to check whether a file is changed, so I'm doing tree.get_file_sha1(id) == tree.basis_tree().get_file_sha1(id) but they always differ
<sjamaan> I thought basis_tree was supposed to be the tree of the latest revision, whereas tree is the current working tree
<sjamaan> (I got the 'tree' object via WorkingTree.open_containing(dir))
<sjamaan> Ah, it looks like this works when I flush the changes I made to the file
 * jelmer waves
<sjamaan> hi jelmer
<sjamaan> What's the recommended way to publish a bzr plugin?
<sjamaan> I made a very small and simple plugin to help out with a very specific task. Should this have its own launchpad page?
<Noldorin_> hi folks
<sjamaan> hi Noldorin_
<Noldorin_> hi
<mgedmin> I have a bazillion unrelated checkouts of various projects in ~/src/
<mgedmin> I'd like to see if any of them have modified and uncommitted files
<mgedmin> with svn checkouts I can do svnst * 2>/dev/null|grep -v ^?
<mgedmin> (svnst is an alias for svn st)
<mgedmin> bazaar doesn't like 'bzr st ~/src/*'
<mgedmin> and for i in ~/src/*; do bzr st $i; done doesn't show me the particular $i
<mgedmin> also it recognizes svn checkouts and starts the slow conversion-into-cache process, any way to disable that?
<kgoetz> do echo $i; bzr st $i
<kgoetz> i use 'mr' for such jobs though, so i don't know what The Bzr Way is
<mgedmin> doesn't mr require you to have a config file explicitly listing all your checkouts?
<kgoetz> yes
<mgedmin> is there a bzr --disable-plugins or something?
<fullermd> Doesn't stat give useful exit codes depending on changes vs. not?  I'd go with that over output...
<sjamaan> it doesn't seem to
<mgedmin> ah, found 'bzr help global-options': there's a --no-plugins
<sjamaan> You could use -V and pipe that to wc -l and see if it's bigger than zero, or something
 * mgedmin ends up with for i in *; do test -d $i/.bzr && { echo + $i; bzr --no-plugins st $i; }; done
<mgedmin> dang
<sjamaan> hm, is there a way to get loggerhead tarball downloads to extract to only 1 directory named after the project? And can you use tags instead of revision numbers?
<mgedmin> with subversion I can filter out unknown files with |grep -v ^?
<mgedmin> how do I do that with 'bzr st'?
<sjamaan> mgedmin: -V does that
<mgedmin> ah!
<mgedmin> so _that's_ what "only show versioned files" means!
<sjamaan> heh
<mgedmin> read it, didn't understand it
<sjamaan> Does anyone know how I can see raw files without knowing their internal ID?  https://bugs.launchpad.net/loggerhead/+bug/605775 says it should be possible
<ubot5> Launchpad bug 605775 in loggerhead "Loggerhead doesn't support linking to the raw content" [Medium,Fix committed]
<sjamaan> (or should I ask in #launchpad?)
 * sjamaan tries there
 * mwhudson rediscovers loggerhead's context_url "feature"
<mwhudson> jelmer: around-p?
<mgedmin> behold my greatest creation: ~/bin/whatsmodified -- http://pastie.org/3150920
<mgedmin> duh, how did I miss bzr st -S?
<fullermd> I doSn't knoSw.  MaySbe Syou haSSve trSouble SsSeeing capSital sS'Ss...
<sjamaan> :)
<sjamaan> And he kept trying: bzr st -
<sjamaan> IT JUST WON'T WORK!
<mwhudson> soo
<mwhudson> bzrlib.delta.report_changes will tell you that the executable bit changed
<mwhudson> but not in which direction
<fullermd> I think I've grumbled about that at the UI level in the past.
<mwhudson> yeah, i presume that's why status is as it is
<fullermd> It annoyed me in log.  It's _really_ hard to understand what happened to +/-x over history.
<mwhudson> diff displays it nicely
#bzr 2013-01-02
<mb5> hi, I am toying around with bzr builder a bit and I have run into a small problem: the project that I am trying to have build has an upstream debian directory so I cannot just merge/nest my debian packaging branch or bzr will complain about conflicts and quit
<mb5> I also cannot just "bzr rm" in the recipe because of locking issues
<mb5> what would be the propper way to handle this problem
<mb5> ?
<ccxCZ> buildbot might help
<pabs3> is there a way to tell if a remote repository exists without downloading the whole repository?
<evillyEvil> How do I fix this error ConnectionReset reading response for 'BzrDir.open_2.1', retrying ?
<evillyEvil> I was able to branch from launchpad just yesterday.
#bzr 2013-01-03
<mgz> morning!
<lifeless> o/
<mgz> :)
<mthaddon> hi folks, can anyone tell me the way to compare two remote branches for differences?
<LeoNerd> bzr di --old=path/to/branch --new=path/to/branch
<RobOakes> Is it possible to check out one subdirectory of a git repository using bzr?
<RobOakes> There are many different projects in the repo, and as I said, I only need the one. (And unfortunately, it is not my repo, or I would happily reorganize it.)
<mwhudson> i think the answer is probably now
<mwhudson> *not
<mwhudson> you can probably something based on fastimport to do that?
<mwhudson> er
<mwhudson> insert verbs as necessary
<RobOakes> mwhudson: That's what I'm looking at now. Is it possible to push changes back to the original repository after using fast-export/import
<mwhudson> i doubt it
<mwhudson> well, you can always send patches like you would with git i suppose
#bzr 2013-01-04
<mthaddon> LeoNerd: thx!
<LeoNerd> .. for?
<LeoNerd> Ohright.. the diff thing? That was aaages ago
<mthaddon> the hint about "bzr di --old=path/to/branch --new=path/to/branch"
<LeoNerd> Ahyes
<mthaddon> yeah, just saw it in backscroll
<LeoNerd> I'm going to use bzr in a directory that is dual-shared with another revision control system, purely so I can have a 'shelve' functionallity ((because the other RCS doesn't have one))
<LeoNerd> Any particular gotchas I should be aware of? As long as I'm careful to bzr ci after $other commit, or updates, it should be OK..? I'm only going to 'add' a fwe specific files also, so I'm planning to  bzr ignore *
<qengho> $ bzr log -m demo
<qengho> bzr: ERROR: exceptions.TypeError: expected string or buffer
<qengho> Weird.
<mgz> qengho: pastebin `bzr -Derror log -m demo`?
<mgz> LeoNerd: provided it's not one bzr has a plugin to recognise, you're probably fine
<LeoNerd> mgz: yeah; it's perforce.. should be fine :)
<qengho> mgz: http://pastebin.ubuntu.com/1495715/
<mgz> qengho: that is fun. maybe pass -Ddebug and `p strings` `p res`?
<mgz> looks like generator confusion rather than an error from re.search though
<qengho> Er, what's the env var to break into pdb?
<mgz> hm, I guess strings could contain None which would do it
<mgz> qengho: sorry, `BZR_PDB=1 bzr log -m demo`
<qengho> lazy_regex.LazrRegex has no useful __str__ or __repr__.
<mgz> I can't find a bug for this though, so would be great if you could report one, https://bugs.launchpad.net/bzr/+filebug
<qengho> Okay.
<mgz> you should be able to thunk them, but I suspect 'strings' is the cause
<qengho> (Pdb) map(type, strings)
<qengho> [<type 'unicode'>, <type 'unicode'>, <type 'tuple'>, <type 'unicode'>](Pdb) map(type, strings)
<mgz> `fake._real_re_compile()` will give you something inspectable
<mgz> heh, tuple 'd do it. guess that's from the colo changes?
<qengho> No idea.  It's  (u'https://launchpad.net/bugs/992352', u'fixed') .
<ubot5> Launchpad bug 992352 in chromium-browser (Ubuntu Natty) "Please update to 18.0.1025.168" [Medium,Fix committed]
<mgz> o_O
<mgz> what's one of the normal ones?
<qengho> Here's the branch, if you want to reproduce. Wife is dragging me away to lunch. ...
<mgz> sure :)
<qengho> bzr+ssh://bazaar.launchpad.net/~cmiller/chromium-browser/ppa-chromium-browser.lucid.stable
<qengho> lp:// should work too.
<mgz> ta.
<mgz> yeah, fails done remotely in the same way
<qengho> mgz: LP: #1096121
<ubot5> Launchpad bug 1096121 in Bazaar ""bzr log -m S" causes TypeError in filtering through regex a tuple" [Undecided,New] https://launchpad.net/bugs/1096121
<mgz> looks like a misparsed debian changelog...
<mgz> but what is it actually doing there... >_<
<qengho> In case it matters, the only debian-specific ext plugin I have is  builddeb 2.7.0dev
<qengho> Lunch.  afk.
<mgz> okay, just seems to be a bug in the fancy log matching not realising that rev.iter_bugs() returns a tuple
<mgz> should be pretty simple to test and fix
<mgz> workaround: using --match-message or other more specific match for now
<LarstiQ> LeoNerd: iirc there is a perforce plugin though ;)
<LeoNerd> Well.... OK. :) But I happen not to have it installed
<dobey> anyone familiar enough with bzr-builder to figure out what's wrong from a traceback?
<dobey> https://launchpadlibrarian.net/127602321/buildlog.txt.gz is consistently happening with this one recipe, but i have no idea what's actually going wrong here
#bzr 2013-01-05
<jonkirkman> Did anyone else notice that Codebase [codebasehq.com] added support for bzr? Very awesome to see that.
<jelmer> that's nice
#bzr 2013-01-06
<flopper> hi, is there a way to use source recipes with upstream tarballs instead of bzr branches?
#bzr 2013-12-30
<LeoNerd> Typo of the day:  bzr gag "FOO"
<mgrandi> "urk"
<SamB> LeoNerd: what was that *supposed* to be
<LeoNerd> tag
#bzr 2013-12-31
<LeoNerd> Hrmm.... My bzr-git plugin seems to be unhappy
<LeoNerd> bzr: ERROR: exceptions.AttributeError: 'BazaarObjectStore' object has no attribute 'get_graph_walker'
<LeoNerd> bzr on native things works fine, but can't pull or dpush a git remote
<LeoNerd> Ah.. So I'm still running 0.6.12 out of debian, but I see there's a 0.7. I'll try that first
<LeoNerd> Hrmmm.. so I have done  bzr co lp:bzr-git  in my  .bazaar/plugins  directory and renamed the dir to just  git
<LeoNerd> But, still  bzr plugins  claims 0.6.12 (the debian version)
<LeoNerd> Ohwait.. the fetched plugin code also says 0.6.12.
<LeoNerd> https://answers.launchpad.net/bzr-git/+question/240033  <== appears to be my problem. No idea how to solve it yet :/
<LeoNerd> Looks like Jelmer's work, only he doesn't appear to be here
<canobi> Hi and happy hollidays! Got a question - I need a repository "mirror", and don't know if I'm on the right track. An example would describe it best, so: let's say I have a library I'm developing and keeping the code in my private central repository. However, I want this library to be accessible by outside people, and so I make another, publicly accessible repo. I also want outside people to be able to send merge requests via my outside repo, and then I would me
<canobi> All changes would then be replicated back to outside repo so anyone can access them. Can this be done, and how?
<mgrandi> you can just do a branch, a branch mirrors it =P
<mgrandi> and possibly bound branches
<mgrandi> and now its 5 am, i must sleep =P
<canobi> \part
<Ebe123> bzr: ERROR: Couldn't import bzrlib and dependencies.
<Ebe123> Please check the directory containing bzrlib is on your PYTHONPATH.
<Ebe123> Traceback (most recent call last):
<Ebe123>   File "/usr/local/bin/bzr", line 74, in <module>
<Ebe123>     import bzrlib
<Ebe123> ImportError: No module named bzrlib
<Ebe123> Help?
<Ebe123> Hi, I'm trying to get the Bazaar GUI. I typed "bzr explorer" in Mac OS X Mavericks terminal, but got the error: "
#bzr 2014-01-04
<rozzin> Hi.
<rozzin> Someone on the emacs-dev said he can never find anyone helpful here. I'm here to be helpful.
<SamB> 24 hours a day?
<rozzin> Maybe for some sense of "helpful"....
<mgrandi> people are usually good about helping here
<mgrandi> they have to ask first =P
<SamB> the mail said something about half-day response times being typical ...
<rozzin> I guess I can helpfully `be there and listen' while I'm asleep.
<mgrandi> ive noticed that a lot of people here are in the european/area/timezones
<mgrandi> so if its 10 pm like it is for me they might not answer =P
<rozzin> Oh, good--I'm US/Eastern, 5 hours behind them; so I can actually provide useful coverage :p
<mgrandi> =)
<rozzin> 00:30, here.
<ale2> Hi!
<rozzin> ale2: Hi.
<ale2> =)
<ale2> Can you help me with a small question?
<ale2> sorry for my poor english
<LeoNerd> Ask, don't ask to ask
<ale2> =)
<ale2> I have a question about user list in bazaar
<ale2> is it the same of server system?
<ale2> or there is a way to separate users list of bazaar and users of system' server?
<ale2> I use bazaar over ssh
<LeoNerd> bzr has no concept of user permissions
<ale2> he use ssh, right?
<LeoNerd> Anyone with access to the files can use it
<ale2> if I would like to add a user to bazaar, for example, I must add to my system
<ale2> with adduser
<LeoNerd> Maybe.. depends how you want to run it
<ale2> I don't want to mix system's users with bazaar's users
<ale2> is possible?
<LeoNerd> Then don
<LeoNerd> Then don'r
<ale2> ok, I understood well
<rozzin> ale2: Are you coming from CVS?
<ale2> no, I never use a DRC before
<rozzin> ale2: What have you used?
<ale2> none, still now
<ale2> I'm looking for a system review
<LeoNerd> bzr itself doesn't care who owns the files... author names are already stored and set by whoever committed it
<ale2> I saw cvs, git, bazaar
<ale2> and I'm reading about all of them
<rozzin> ale2: You have never used *any* version control system?
<LeoNerd> rozzin: such people do exist ;)
<ale2> not until now :D
<rozzin> OK.
<ale2> you scared me :P
<ale2> my cousin asked to me to find a way to track the changes of his project
<ale2> he has a very small software house
<ale2> and I will help him
<rozzin> Well, it's just interesting--usually questions like that come from people who are already accustomed to using some other tool.
<ale2> I have to give up?
<LeoNerd> Gaaahh
<LeoNerd> ale2: are you listening to me at all?
<ale2> yes LeoNerd
<LeoNerd> Then what on earth leads you to that idea?
<LeoNerd> You want multiple users to be able to use bzr, without adding those users on the system level. YES THAT IS EXACTLY WHAT I SAID YOU CAN DO
<ale2> rozzin scared me :D :D
<rozzin> Sorry.
<ale2> i'm joke :D
<LeoNerd> bzr users are TOTALLY INDEPENDENT of system users. (for the fourth time:) bzr doesn't care who owns the files, it stores user names, it does not care about owner uid of the underlying files.
<ale2> mh, I understand
<LeoNerd> Infact on a multi-user server setup you can (and probably want to) have every file owned by -the same- user, probably called 'bzr' or maybe a user per project, to which every real person who needs access has an ssh key
<ale2> aah!!
<ale2> I take advantage of you for only two second
<ale2> tell my if I understand
<ale2> I have only one users in my system calls "bzr"
<ale2> 5 employees connect with the same user
<ale2> but bzr can remember one of he with the nickname
<LeoNerd> Indeedy
<ale2> sorry but I have a small problem with english :D :D
<ale2> but I'm happy to understand :D
<ale2> thank you very much!!
<rozzin> Normally we just have people use their own accounts, though.
<LeoNerd> Well yes; at this point you're not massively using the D part of DVCS
<rozzin> Or, if they don't have an account on the server, then you have them send their changesets to someone else who does have an account.
<ale2> when I have a dedicated server with bzr, I use it
<rozzin> For example, you make a bunch of changes on your computer, then you do "bzr send -o mychanges.patch ..." and mail the project leader that patch, and the project leader merges it into the main codebase and publishes it.
<ale2> clear
<rozzin> ale2: Is your cousin a developer, or just a manager?
<ale2> both
<ale2> but he use only windows
<ale2> without revision history of his code
<ale2> brr
<rozzin> ale2: How big is his dev team? Just him?
<ale2> 5-6 developers
<ale2> is pretty small
<rozzin> That's pretty big to be running with no version control.
<rozzin> How do they collaborate on the same code? Do they have the code on a network drive?
<rozzin> Or do multiple people not work on the same thing?
<rozzin> ale2: Why do you not want to give all of the developers ssh accounts on the bzr server?
<ale2> rozzin: yes, they collaborate on the same code and they have it on a ftp server
<ale2> but happened that an edit crashed all code and no-one knows who delete a part of code
<ale2> and my cousin ask me if I know a method to save a things similar to changcode
<ale2> for me, is the same give or not an ssh accounts to all developers
<ale2> but I want to test bazaar on my local pc
<ale2> and I don't want to mix users =)
<ale2> that's all!!
<rozzin> I'm not sure I understand what "don't want to mix users" means.
<ale2> sorry
<fullermd> Neither do I.  Users are always better after you cram them in the blender...
<ale2> I mean mix users of my personal system with users of bazaar
<ale2> lol fullermd :D
<rozzin> ale2: Do you mean "mix users of your personal system with users of the ssh server"?
<ale2> of bazaar server
<ale2> but bazaar use ssh, right?
<fullermd> bzr doesn't really have "users" in any particularly broad sense.  It stores a committer identity for each commit, but aside from that it doesn't care about the matter one way or another.
<rozzin> I think I understand.
<ale2> is so difficult to me to speak in english :D
<ale2> for me*
<fullermd> ssh is a way (the most common, probably the best, but not the only) for people to exchange commits once they're made.
<rozzin> ale2: Yes, bzr itself doesn't handle authentication or access-control at the server.
<fullermd> And it requires some sort of auth/user accounts/whatnot, but strictly speaking that's outside bzr's sphere of caring.
<fullermd> Or maybe it's a hypercube of caring.  Anyway.
<ale2> (thumb up)
<ale2> :D
<ale2> anyway, is bazaar the correct answer to my cousin's question?
<rozzin> ale2: login/auth and access control are managed by something else--a transport--like ssh (if you're using ssh as your way of communicating with the server) or a web server like apache (if you're using HTTP).
<ale2> I think yes =D
<fullermd> Well, it's sure as heck a better answer than "CVS".
<ale2> but if I use http, I can't send change to server, right?
<ale2> thanks fullermd
<fullermd> The only people for whom CVS is a good answer carry titles like "Inquisitor"...
<rozzin> ale2: I believe it's possible to give write access via HTTP, but I think it's more complicated to set up than just giving people ssh accounts.
<ale2> yes, I read
<rozzin> I'm not a really experienced webserver admin, though.
<ale2> me too :P
<fullermd> At one point the only way to do it was DAV, and ew.  I think you can technically do it via the HTTP smart server, but that's not much less ew.
<rozzin> In any case, since I understand what you mean now--
<rozzin> ale2: It's possible to use bzr on your local PC without even having a network connection.
<fullermd> One wacky possibility that has occasionally been workable is to run the standalone smartserver in wide-open mode.
<fullermd> That requires special circumstances to not be a horrifically bad idea, but they do occasionally come up.
<ale2> I have a small network in my home ;-)
<fullermd> e.g., you have to trust everybody who can possibly get network access to it, since it's...  y'know.  Wide open.
<ale2> mh, interesting
<rozzin> ale2: You create a local repository with "bzr init-repo", create a branch inside it with "bzr init", add files and commit them (entirely offline), and then later do a "bzr push bzr+ssh://myserver/..." of your branch to send it to a server if/when you decide that you want to publish/share your branch.
<ale2> they works in the same agency :D
<fullermd> But if it's on an inside protected network at a company, where only the devs can access it anyway, it's just possible it could fail to fail.
<fullermd> But ssh is probably better all around, really.  Especially with such a small set of users needing to be setup.
<ale2> yes rozzin, I read =)
<rozzin> ale2: As as LeoNerd was saying, bzr doesn't care about what your local user is or whether it's the same name/UID as a remote acccount that you might have on some server somewhere;
<rozzin> ale2: bzr just knows what name and e-mail address you told it with "bzr whoami".
<ale2> I understand! =)
<ale2> and it will be useful ;)
<rozzin> ale2: Do you have bzr installed on your PC yet? :)
<ale2> yes
<ale2> and Bazaar Explorer installed in other windows PC
<ale2> because in future, my cousin will use it from windows
<ale2> (my pc is an Arch :P)
<rozzin> Ah.
<ale2> uff, is so complicated.. :(
<rozzin> Is it?
<ale2> I hate windows
<ale2> it a complication, ehehe
<rozzin> Ah.
<ale2> hihi
<ale2> and I will use ssh on windows pc to my pc
<ale2> but I think that's simple
<rozzin> I've never tried having Windows people using bzr Explorer.
<fullermd> Remember that in bzr there's a conceptual separation between "working and changing and committing" on the one hand and "sharing/combining those commits with other people", and only that latter involves and ssh or http or whatnot.
<rozzin> I introduced some Mac people to it and they all discarded it pretty quickly, in favour of just using "bzr qcommit", "bzr qlog", and "bzr qdiff" commands.
<fullermd> So you can comfortably ignore all that stuff while you get through "learning to use bzr for actual code work" part.
<ale2> if I'll succeed, I'll write you :)
<rozzin> ale2: Have you also looked at TortoiseBzr yet?
<ale2> not yet
<rozzin> ale2: What editor or IDE do people on your cousins team use?
<rozzin> ale2: MSVC? Eclipse?
<ale2> they wrote in c#
<ale2> I don't know what IDE they uses
<ale2> I know there are a lot of text file
<ale2> and mayble some executable
<rozzin> ale2: You may want to find out and see if there is a plugin for their IDE.
<ale2> but I read bzr can process executable files
<ale2> ok, I will find
<rozzin> Yes; bzr can deal with binary files.
<ale2> I hope they don't use Visual Studio :D
<fullermd> I'm not aware of any IDE plugins that are much beyond POC status.
<rozzin> whether to store the binary files along with the source code in version control, or in another place, is a whole other question though.
<rozzin> Mmmm: http://wiki.bazaar.canonical.com/VisualStudioIntegration
#bzr 2014-12-30
<sumanah> I'm learning to use Bazaar and I need some help; I think I did  'bzr branch lp:mailman' to get a local copy of the dev branch of https://launchpad.net/mailman/3.0 , and then I pushed a branch https://code.launchpad.net/~sumanah/mailman/mailman , and now when I run `bzr update` it won't grab any revisions after my branch
<Peng> I think you want bzr pull or bzr merge
<Peng> not bzr update
<sumanah> this was several weeks ago, checking out my .bash_history ....
<sumanah> Peng: ah interesting! I was looking at http://doc.bazaar.canonical.com/bzr.dev/en/user-guide/central_intro.html
<sumanah> I'm trying bzr merge now, thanks Peng
<sumanah> hmmm, I ran  `bzr merge`    (no argument, just to check) and although I got a sort of manifest of changes and "all changes applied successfully", bzr log still only goes up to revision 7274 (I know there have been more revs)
<sumanah> and `bzr branches` just gives me '* (default)'
<sumanah> 'bzr log --include-merged | head' also gives me rev7274
<Peng> sumanah: bzr status, bzr diff and bzr commit
<fullermd> Merge doesn't make a new rev, it just stages up the merge.
<fullermd> Presumably you'd really want to pull if you could, though if you're using the branch for local work you couldn't (well, wouldn't want to).
<Peng> Mm
<Peng> You can "bzr pull" if your branch is a subset of the remote branch. If you have revisions it doesn't, you have to merge.
<sumanah>  $ bzr pull
<sumanah> Using saved parent location: http://bazaar.launchpad.net/~mailman-coders/mailman/3.0/
<sumanah> bzr: ERROR: These branches have diverged. Use the missing command to see how.
<sumanah> Use the merge command to reconcile them.
<sumanah> OK! That is what I will do
<sumanah> Thank you Peng and fullermd, will work on that in an hour or so after this meeting :)
#bzr 2015-01-01
<croepha> Hello
<croepha> my team is using a bzr pull :parent; bzr commit; bzr push :parent  workflow
<LeoNerd> I'd just  bzr bind  that
<croepha> huh
<croepha> that works for multi user?
<fullermd> I hope so, or I've been doing nothing for the last 7 or 8 years...
<croepha> lol
<croepha> so, you just do bzr bind :parent
<croepha> and then commit like you would normally?
#bzr 2015-01-03
<aquarius> Using bzrlib, given a Branch object, how do I get a RevisionTree for that branch for a particular revno?
<aquarius> branchobj.basis_tree() gets a tree for the most *recent* revision, but I can't find how to get one for an arbitrary revno.
<aquarius> aha, branch.revision has it. Excellent.
#bzr 2016-01-06
<sidi> Since when does bzr pull slaughter local uncommited files without warning? :|
#bzr 2016-01-10
<renatosilva> can I rename the bzr executable?
<fullermd> I wouldn't think there'd be a reason why not...
<renatosilva> good, I will try, thanks
#bzr 2017-01-02
<chatter> hey guys
<chatter> allah is doing
<chatter> sun is not doing allah is doing
<chatter> to accept Islam say that i bear witness that there is no deity worthy of worship except Allah and Muhammad peace be upon him is his slave and messenger
<verticaltalker> hello
<verticaltalker> Peng reported this channel to #freenode because of Allah-related issues
<verticaltalker> Terrorist, i command you: reveal yourself
<verticaltalker> ajmitch_,  alexlist,  anthonyf`,  camerin,  catern,  charles,  djinni`_,  elmo,  FourDollars,  fullermd,  ggherdov,  irsol,  jam,  james_w,  jelmer,  Keltia,  lamont,  LeoNerd,  mthaddon:
<verticaltalker> nicoulaj,  nopf,  Peng,  Peng_,  pjdc,  rvba,  Shentino,  superfly,  tska,  ubot5`,  ubuntulog,  verterok,  verticaltalker,  vila,  wgrant,  yena,  zyga:
<verticaltalker> nickspam successfull!
<verticaltalker> dax, welcome to #bzr, the channel Peng just false reported.  I have been here since about ten seconds after Peng reported it, and i am the only one i've seen speak here
<verticaltalker> i.e. nothing was actually going on and Peng should be removed from the network because he/she is a liar
<verticaltalker> i'll probably just highlight everyone again.  even that did not get a reaction last time
<verticaltalker> this chan is so dead
<verticaltalker> dax, send a NOTICE to the chan maybe?
<Peng> Sorry, y'all
<verticaltalker> it seems dead
<verticaltalker> Peng, you did nothing wrong except make a mistake
<verticaltalker> i am here because you reported that there was Allah crap being preached here
<verticaltalker> and I am a radical anti-islamic anti-terrorist
<dax> got bored of it
<dax> anyways
<dax> Peng: would recommend mentioning the channel name in PM once a staffer shows up in future, otherwise dingbats join :(
<dax> (not your fault, it's an ongoing problem with #freenode I'm trying to beat out of them)
<vila> Peng: no worries, trolls are everywhere
<Peng> dax: Yeah. I skipped a step because this isn't the type of channel they usually target :/
<Peng> Don't skip steps. :(
<Peng> dax: Thanks, in any case.
<Shentino> dax: K-lines mean network staff already dealt with it
<dax> what?
#bzr 2017-01-03
<chatter> hey guys
<chatter> allah is doing
<dax> chatter is not spamming dax is k-lining
