#bzr 2008-05-26
<mwhudson> hello
<beuno> get_revision_graph was deprecated in 1.4, what would be best the way to do it now?  I'm using get_graph(), but it seems slower
<mwhudson> beuno: how much slower?
<mwhudson> beuno: i'm assuming this is for the history object creation time in loggerhead?
<beuno> 2.8sec vs 2.1sec
<beuno> yes, in History.from_branch
<mwh> mm, that's fairly bad
<mwh> is that on bzr.dev ?
<beuno> 1.5 actually
<beuno> I should probably switch to bzr.dev, but it should be faster in 1.5 too
<mwh> i woudn't expect much difference
<beuno> I may going about it wrong
<beuno> I doing log._get_mainline_revs, and then graph.iter_ancestry
<beuno> mwhudson, why would loggerhead want each revisions parents to generate it's current history?
<beuno> ah, probably to show "merged from"
<mwhudson> beuno: right
<mwhudson> beuno: "revisions that are in the ancestry of this revid but not this other one"
<beuno> what it doesn't seem to do is limit to what i actually will show on screen
<beuno> and just ask for the whole history
<mwhudson> beuno: mind you, there are much better graph apis for this now, thanks to jam
<mwhudson> beuno: loggerhead caches a whole heap of whole-history information when history objects are created
<mwhudson> beuno: it would certainly be interesting to take an 'outside in' approach
<mwhudson> where you consider what information each view needs and what facilities now exist to get this without whole history operations
<mwhudson> i think computing revnos from revids would still be a sticking point
<beuno> maybe the revisions that are going to be viewed can be retrieved and cache, if they aren't already
<mwhudson> it's not the revisions per se that are interesting
<mwhudson> it's the relationships between them
<beuno> hrm, yes
<beuno> alright, thanks for the brainstorming, I'll start looking for a better alternative to the deprecated method, and try to leave the caching intact for now
<beuno> mwhudson, https://lists.ubuntu.com/archives/bazaar/2008q2/042306.html  seems like a probable improvement
<beuno> but, using some of these will make loggerhead depend on bzr 1.5 >
<mwhudson> beuno: well, maybe, it's a trade-off between making the history creation a bit slow and having blazing fast revid->revno mappings
<mwhudson> beuno: and having slower page loads
<mwhudson> beuno: a more incremental approach would be nice, and probably possible
<mwhudson> probably need to be careful about memory usage &c though
<beuno> would you rather I look into memory issues first?   This was deprecated in 1.4, so it should be there for a few more months. I can do a few tests with Genshi
<beuno> (annotate does have deprecated methods too, btw)
<poolie> beuno: hello
<beuno> hey poolie  :)
<mwhudson> beuno: eh, looks like get_revision_graph is gone in bzr.dev already
<mwhudson> beuno: fixing this stuff seems like a good thing to do :)
<mwhudson> beuno: in particular fixing annotate has been on my todo list forever
<mwhudson> beuno: well, for at least 6 months :/
 * mwhudson goes for lunch
<beuno> mwhudson, alright, I'll stick with the deprecated methods first
<beuno> bonne appetit
<Vigh> Hey - anyone here available to help me with a quick problem?
<bob2> best to just ask
<Vigh> yeah, I just wanted to make sure I wasn't the only one that isn't AFK before I did =P
<Vigh> anyway, I'm pushing a versioned project to a dumb FTP server ("dumb" because it's not running Bazaar)
<Vigh> and I wanted to know if there's a way to remotely update the FTP server's working tree
<Vigh> pushing updates the .bzr directory but not the actual files, and the way that the documentation suggests I do it is by running "bzr update" on the host of the branch, but I can't since the FTP server isn't running Bazaar
<bob2> well, if you can ssh in, you can bzr co
<beuno> Vigh, do you want to keep the history on the other end, or just want the working tree?
<Vigh> meh, that's the thing - there's no way I can get Bazaar running on the FTP server
<bob2> but otherwise, no, unless you upload the checked out files  via ftp too
<Vigh> beuno: Well, here's what I'm working on. I'm working on a web application with 3 other people, and the web app is being hosted on a webhost which provides FTP access but no SSH access
<Vigh> I'm using Bazaar because we need versioning and revision control on the project
<beuno> Vigh, if you just need the working tree, there is an experimental plugin that does that
<beuno> you can use a random place to centralize the repo
<beuno> and upload to the production server with the plugin
<beuno> (it's main target actually is for web development)
<beuno> http://launchpad.net/bzr-upload
<beuno> it's still in it's initial stages, but it works well enough, we use it at work pretty frequently
<Vigh> Hmmm....this looks perfect
<beuno> :)
<Vigh> Thanks beuno!
<beuno> bugs and patches very welcome, btw
 * beuno curses graph.iter_ancestry
<Vigh> So I basically just run Bazaar with this plugin on one of my servers and store the repo there, then anytime one of the four of us pushes a revision to it, it will upload the modified files to the specified FTP server?
<beuno> Vigh, you don't need to run it on the server, just the client
<beuno> bzr upload location
<beuno> and it uploads, be default, all files changed from the last revision uploaded
<Vigh> Oh, wow, even simpler than I though
<Vigh> *thought
<beuno> yes, that's what we where aiming at  :)
<beuno> make sure merge eachothers changes before uploading, it will check on the remote server, the last revid uploaded, so you should have that in your repo
<Vigh> Can I centralize the project on the FTP server and have it upload the modified files in the working tree on the same FTP host? 'Cause we're each running Bazaar and we have the centralized branch already on the FTP server and it works great, the only problem was that any new revisions only updated the .bzr directory on the FTP server, not the actual files (i.e. the working tree)
<beuno> mwhudson, changed a few things around, got the new API with the same performance as the deprecated one. I'll cleanup a bit, upload, and start working on annotate.  Dinner first though  :)
<Vigh> In other words, can we each just install this plugin and start using bzr upload without changing any configs?
<mwhudson> beuno: excellent
<mwhudson> i would subscribe to the branch but there's not much point when the scanner
<mwhudson> 's fubarred
<beuno> Vigh, you can, but it should be to different locations. You don't need anything special to use this plugin, as it basically uploads via ftp/sftp all files changes since the last revid uploaded
<beuno> mwhudson, fubarred?
<mwhudson> beuno: not working
<Vigh> beuno: I ask because we already have the main project centralized on the FTP site and it works fine, it's just that we had to upload the modified files manually because pushing only modified the remote .bzr directory, not the remote working tree
<beuno> Vigh, yes. I usually upload the branch to a folder outside of apache's reach, so that only devs can see it, and upload files to a a public directory
<beuno> so I keep the repo and files seperate
<Vigh> beuno: I'd do that, but out webhost gives us very limited access to the server...no SSH access, and we can only read/write to apache's htdocs directory
<bob2> put the branch somewhere protected by htaccess
<Vigh> at the moment, we have a /bzr directory on the host that is hidden from public view via .htaccess
<beuno> Vigh, that works too, yes
<Vigh> Ok, thanks again for the help
<beuno> np
<Vigh> I'll tell ya' if I have any troubles with the plugin =P
<beuno> Vigh, please do  :)
 * beuno goes grab some dinner
<poolie> i'm going to do a patch for russel's nfs bug, should be trivial
 * igc lunch
<beuno> mwhudson, pushed the branch with some cleaning done. It now performs as well as the deprecated method does, I'll move on to annotate, and once I clean all deprecated methods, go back and start working on performance
<beuno> I don't see a cleaner way to get the graph, although it's an improvement to my previous approach. I'll catch jam tomorrow and see if he knows a cleaner/faster way of getting it
<mwhudson> beuno: i'll take a look
<mwhudson> beuno: i think you typoed the branch name (logger*g*ead) :)
<beuno> argh
<mwhudson> beuno: and left a mystery "OB"
<beuno> I forget to --remember   :p
<mwhudson> but otherwise it looks good :)
<beuno> mwhudson, re-pushed and cleaned
<beuno> hrm, bzr isn't remembering the location  :/
<beuno> btw, why is branch scanning disabled?
<mwh> it's wedged on a large branch :/
<beuno> ah, so it's just delayed
<mwh> yeah, it'll get unstuck at some point
<poolie> igc, hm i'm trying to work out how to reply to http://bazaar-vcs.org/AlexanderBelchenko
<bob2> does pqm run the tests on windows?
<mwh> beuno: i can confirm that your branch has basically identical performance to what's in trunk now
<beuno> mwh, cool. One less, 2 to go
<mwh> which are ... ?
<beuno> performance-wise, the main problems I saw, not having gone too deep, was annotate and diff
<beuno> mwh, annotate_iter is what I'm working on now
<mwh> ok, yes
<beuno> and there is one more which I don't have handy, but it may be the same
<beuno> (used somewhere else)
<beuno> I've been thinking we may want to try caching the diff's as static HTML, even if we get a good enough improvement with a different templating engine
<beuno> it will make diff views *very* cheap once they're generated
<mwh> there used to be something a bit similar done
<beuno> aha, and it was removed because...?
<mwh> but they weren't cached as html, so you still had to pay the rendering cost
<mwh> beuno: used heaps of diskspace and didn't benefit much
<beuno> well, the disk space will probably still stand, but we should render it once, and never again
<beuno> CPU and RAM will be very happy
<beuno> so make 2 people happy and one sad, 50% win!
<beuno> mwh, maybe we can try just storing the diff bit of the HTML, and generate the rest. That way we may save some space, and leave the rest as-is
<mwh> beuno: it makes some sense
<lifeless> I have three thoughts
<lifeless> one, I'm wasted, having travelled etc.
<mwhudson> hi lifeless
<lifeless> two, why would loggerhead benefit from such a diff cache and not bzr core
<lifeless> three, why not analyse logs that we have today to gather data on whether repeated diffs happen/sizeof cache needed etc
<beuno> lifeless, hi
<lifeless> in bzr we have found that caches need to be examined with great care to avoid $various issues
<lifeless> hi :)
<beuno> lifeless, I may be wrong, but the diff between two specific revisions will never change, so, if we handle that carefully enough, we should be able have a plain text (html) cache of it
<beuno> so if I have something like revid1_revid2_diff.cache
<beuno> I can look for those first, and fall back to generating it if it's not there
<beuno> of course, it may not be the case for many other parts of bzr, but diff and annotate I think should be possible, and extremely cheap to serve once generated
<beuno> analysing logs on where the current memory hog is, of course, would be of great help, but out of my hands
<lifeless> sure; I can see that. Of course it raises the cost of generating it on MISS, and adds a requirement to manage that cache
<lifeless> you could also just whack a http proxy in front of loggerhead to cache specific urls
<lifeless> anyhow, not saying its a bad idea, saying analyse!
<lifeless> also, I didn't say analyse logs for memory, I was saying analyse logs to see what benefit a diff cache would have
<lifeless> if any diff gets hit only once, what benefit a cache?
<beuno> right, if the current problem is diffs in different repos, than it won't help very much
<beuno> the http proxy may work well-ish for LP, but doesn't seem like a good implementation for Loggerhead itself, as it would force an extra setup step for people
<beuno> so, I agree. mwhudson, will you be able to spare some time to take a look at that?  Or is there any way I can help?
<lifeless> [lemma - standard rule in performance tuning is be sure you have identified the problem]
<mwhudson> i'm working, slowly, with the sysadmins to get some decent log analysis
<lifeless> a cache is a good answer for 'we repeat [making diffs] a lot and its the effort of repeating ourselve makes us slow]
<lifeless> s/]$/'$
<mwhudson> my limited intuition is that slapping squid in front would have a good bang/buck ratio when it comes to dealing with the problems launchpad had last week
<lifeless> if the problem is 'making diffs is slow' adding a cache only helps to the proportion of diffs avoided
<beuno> yes, since I don't have any performance information, yet, I went down the cache path, as it helps scale, and, worse case scenario, it's as expensive as it currently is
<beuno> mwhudson, squid will help, until we change the URLs to revnos  :)
<lifeless> there is a fallacy there; the worst case of a cache is not the same
<lifeless> if you are IO bound
<lifeless> loading dentries is not free
<lifeless> anyhow, I'm not against a cache per se; I just want you guys to be sure.
<beuno> yes, sane advice, thanks
<beuno> we also need to think on other use cases, outside LP
<beuno> where I do think it's more probable to hit the same diff several times
<beuno> but some performance analysis should absolutely be done, on how expensive adding a cache is
<lifeless> a cache costs you code; it costs you a cache dir to maintain (and filesystems can have surprisingly pathological behaviour)
<lifeless> it adds background tasks
<lifeless> there is also the question of where the cost is
<lifeless> getting two texts and diffing in bzr should be very cheap
<lifeless> is it rendering, or blaming
<lifeless> could we render on the client
<lifeless> or not blame by default
<lifeless> if its bzr diff performance that is the issue should the cache be in bzr
<lifeless> another concern on caches is that they can mask actual problems
<lifeless> by making 'op' seem cheap when its not, and this can lead to suprising results when later performance tuning. See for instance 'kndx' files.
<lifeless> we're still dealing with the fallout of making all operations access all history - much code started to depend on that, even when we were usually careful
 * igc pick up kids
<lifeless> do you juggle?
<mwhudson_> well, loggerhead also suffers from the 'needs to access all history' problem
<lifeless> I'm going to halt() for a bit; utterly stuffed and not really coherent
<beuno> lifeless, your input is very much appreciated  :)
<beuno> how was UDS, btw?
<lifeless> most excellent
<beuno> chech beer?
<jamesh> "czech"
<DanielEads> This is probably a stupid question, but I googled around for 20 minutes and couldn't find it....    How do you install someone's branch onto your system with bzr?
<lifeless> tchau for now
<beuno> DanielEads, you can get a copy of it with:  bzr branch remote_location
<DanielEads> beuno:  Thank you  :)
<beuno> mwhudson_, do you know of any way of forcing the annotate cache to re-generate, apart from cleaning the sqlite DB manually?
<beuno> I replaced the deprecated method, but I want to do some performance comparisons before pushing
<mwhudson_> beuno: er
<mwhudson_> beuno: the annotate cache is/was a bzr thing
<mwhudson_> beuno: to do timings without loggerhead's revision cache, you can comment out the cache_path in the config file
<beuno> mwhudson_, that's what I was looking for, thanks
<beuno> yay!  new method is 4x faster
<mwhudson__> beuno: :)
<beuno> mwhudson__, it seems applying the template to big files like NEWS is almost as expensive as generating the annotation itself...  changing the templating engine makes more and more sense
<mwhudson__> beuno: you noticed :)
<mwhudson__> though to be fair, it's not all the rendering engine's fault
<mwhudson__> there's a lot of time spent inside the loop that's the core of annotate.kid
<beuno> mwhudson__, pushed the code for annotate. That's the last of deprecated methods I could find
<beuno> it gets better performance in some cases, and the same in other (larger, more complex files)
<beuno> won't make a difference, but it won't get deprecated either  :)
<beuno> almost 3am here, so I'm about to call it a day.  If you can't think of anything more important, my next step would be experimenting with different templating engines
<beuno> and possibly evaluating how some of the caches are used, it seems there's room for improvement in some cases
<mwhudson__> beuno: it's the end of my work day too, so thanks and i'll get back to you tomorrow
<beuno> mwhudson__, thanks, cya tomorrow
<beuno> I'm off, have a good day everyone  :)
 * igc dinner
<tca> Have anyone here managed to use http://cia.vc and bzr together? I'm trying the cia client http://cia.vc/clients/bzr/cia_bzr.py, but see no message or warning, and nothing happens at cia.vc and the irc robot is silent.
<jamesh> tca: that plugin looks like it is using the old hook registration method so if you haven't updated your ~/.bazaar/locations.conf file, as the comment at the top says, it won't do anything
<jamesh> tca: https://launchpad.net/bzr-cia/ is probably more promising
<tca> I did modiy locations.conf. I'll try the client on launchpad now.
<tca> This works. Thank you. I will notify them about this client.
<Pieter> If I uncommit a large number of revisions, how can I get the space occupied by those revisions back?
<jelmer> tca: It's actually the same client, just that the CIA folks haven't responded my requests to update the one on their site
<jelmer> Pieter: a copy of the branch will not contain those revisions
<beuno> what does bzr commit --fixes actually do?
<gour> adds some metadata for the bug-tracker?
<Jemsquash> Can someone help me getting bzr visualise to work on windows Vista? I've tried various installs and can't seem to get bzr to recognise that its installed. I've tried the pygtk windows installer and a cygwin installation but no luck.
<Jemsquash> According to the instructions I need to install olive using python olive-gtk. It gives an error that pygtk2 is not installed.
<Jemsquash> I can see the following apps installed in the Control Panel: Python 2.5 pycairo-1.2.6, Python 2.5 pygobject-2.12.3, Python 2.5 pygtk-2.10.1, Python 2.5.2
<Jemsquash> Otherwise is there some other way to get a graphical representation of branches in a bzr repository?
<jelmer> it may be easier to get qbzr to work on windows
<Jemsquash> yeah I've got it working but it does not show a nice graph of the branches AFAIK.
<Jemsquash> qbzr is quite helpfull but I'd prefer to use a pretty picture to show me what's merged where. I'm a bit of a simpleton at times :)
<beuno> jam, could you pass a merge request I just sent, through the filter?  It's 1.7mb  :)
<beuno> (and if you have time at some point, I have a question on what the best way to get a repos's graph is)
<Jemsquash> em, I lost you there. Through the filter?
<beuno> Jemsquash, that would be for jam  :)
<Peng> 1.7 MB?! What'd you do, rewrite bzr in Ruby?
<beuno> Peng, LOL
<beuno> it may be that or it may be the images for the spanish docs. Nobody will know until it goes through the filter  :)
<Peng> That's way less interesting. :P
<beuno> well, it could still be the ruby thing
<fullermd> Well, maybe it's a rewrite in perl, that just LOOKS like the images for the spanish docs.
<beuno> and with tests!  :)
<fullermd> Everybody's all about the code being the documentation, after all...
<beuno> that should confuse the reviewers enough
<jam> beuno: for this one, could you push a branch to LP and just submit a plain diff? I'd rather not push 2MB to everyone on bazaar@
<jam> I can if it is hard for you
<Peng> It's possible to do a merge directive without a diff or bundle, right?
<jam> beuno: btw, how do you get 2MB from editing source files?
<jam> Peng: 'bzr send --no-bundle'
<jam> that sort of thing
<jam> but you need a proper public location
<jam> beuno: well, editing documentation, but that's still a lot of changes
<Peng> jam: Not if it's images.
<beuno> jam, I can, but it will take a while, as I have to upload a new bzr branch to LP
<jam> Peng: if it was bitmaps
<jam> Which is something we wouldn't really want to merge
<Vigh> Hola - beuno, you here?
<Peng> The en quick-start-summary.* is 1 MB.
<Peng> Maybe compressing and base64ing it blew it up.
<jam> could be
<Peng> 1.1 MB. base64 could do that.
<beuno> Vigh, yeap yeap
<jam> I'll let it through, I guess
<Peng> Really?
<beuno> it's the workflow png/svg's
<beuno> jam, I *can* upload the branch, I don't want to annoy everyone  :)
<jam> beuno: though technically, it is my day off :)
<jam> already sent, and I'm afk
<beuno> jam, aaaah, I did not know that, have a good holiday
<Vigh> beuno: I just installed bzr-upload and it's _almost_ working...the initial full upload fine
<beuno> and thanks
<beuno> Vigh, almost working is pretty good for a pre-alpha  :p
<Vigh> but after making a new commit and trying to upload, I'm getting this error:
<Vigh> File "C:\Python25\Lib\site-packages\bzrlib\plugins\upload\__init__.py", line 98, in run
<Vigh>     display_url = urlutils.unescape_for_display(stored_loc,
<Vigh> NameError: global name 'urlutils' is not defined
<beuno> Vigh, htm, let me check
<beuno> you have the latest version?
<Vigh> Yup, just pulled this morning
<Vigh> That's the only place in the script that urlutils is actually used, so I'm tempted just to leave out the unescaping
<beuno> hrm, all tests pass
<Vigh> the test_upload.py runs fine for me, too >.<
<beuno> Vigh, uploading a fix now, try pulling and re-uploading
<Vigh> I just fixed it myself too =P
<Vigh> I realized that urlutils was never actually being imported
<beuno> yes, that would be it  :)
<Vigh> Anyway, it's working wonderfully now
<beuno> can you see if trunk fixed it properly too?  just so I can be sure
<Vigh> sure, hold on
<Vigh> Yup, works with the newest version
<Vigh> Thanks =)
<beuno> Vigh, thank you  :)
 * beuno adds comment to add a test for those lines
<beuno> vila, ^^  :)
<jam> Vigh: just add a "from bzrlib import urlutils at the top
<Vigh> jam: yeah, I know =)
<Pieter> if I have a shared bzr rpo, can I just delete one of the working dirs and then get it back later?
<pasky> Hi, what are the most popular tools for history visualization in bzr? The dot-based tool in BzrTools, or something else?
<radix> Pieter: technically, all of the revisions are stored in the repository, so all the data is still. however, I don't know of any easy way to get it back out
<radix> Pieter: however, if the branch you have deleted has already been merged into another branch, then it's possible and easy to reproduce the merged/deleted branch
<jelmer> Pieter: it should be possible to delete the working tree files but leave the pointer to the revision in
<Pieter> I just think the one repo / dir thing is totally whack
<Pieter> coming from git / hg :)
<radix> Pieter: oh, I assume you mean one of the branches, not just the working tree files
<jelmer> Pieter: the "bzr remove-tree" command will do that - you can later create it again using "bzr checkout"
<Pieter> it'll just leave an empty dir?
<radix> Pieter: when you say "delete one of the working dirs" what exactly do you mean, please?
<Pieter> I want to get rid of the files, but keep the branch in the repo
<jelmer> Pieter: yes, an empty dir with just a .bzr directory with a couple of files in it
<Pieter> that also works in a shared repo?
<jelmer> Pieter: Pieter yes
<jelmer> whoops, one tab too much :-)
<Pieter> ok :) and if I want to delete the whole branch, and then remove any data added by that branch, in order to decrease repo size?
<gour> Pieter: what did you bring from git/hg ?
<Peng> Pieter: There's no easy way to do that.
<jelmer> Pieter: repository's are append-only
<Pieter> gour: you mean, which projects?
<Peng> jelmer: So are hg's, but mq has a "strip" command.
<pasky> By the way, is there any nice paper describing bzr's on-disk data structures etc?
<gour> what will rm branch-dir-folder do?
<pasky> or do I have to defer to the source code?
<jelmer> Peng: what does that do, simply create the repository again but only with the data it actually needs?
<Peng> pasky: Perhaps doc/developers/packrepo.txt?
<gour> Pieter: i was/am thinking you are migrating from other VCSs to bzr
<Peng> jelmer: I dunno. I've always figured it edits the revlogs in some hacky and unreliable way. :P
<Pieter> gour: I have my own projects that mostly I am working on (in git). Someone else wants to help me out, but he prefers bzr, so I was looking if it would be good to convert it :)
<Peng> pasky: Oh, that file doesn't have very many details.
<gour> Pieter: ahh, cool
<Pieter> gour: I just prefer git's inline branches somewhat
<Pieter> if I have multiple git branches, do I have to supply multiple branch url's for someone to get all of them?
<Pieter> when I convert them to bzr, that is
 * gour also wonders about bzr's best-practices when rm-ing e.g. 'feature' or 'fix' branches which are very cheap in darcs
<pasky> Peng: *nod* :( I'm looking for something like the Mercurial OLS paper or Linus-njs dialog about git packs
<pasky> on the other hand, there's more in there than I thought at first glance... I'll read it carefully
<pasky> Possibly my question was lost in the other conversation, so I'll try again ;-) - what are the most popular tools for history visualization in bzr, please? The dot-based tool in BzrTools, or something else?
<Pieter> you're looking for something like gitk?
<dato> pasky: I think `bzr viz`, from bzr-gtk, is commonly used too
<Pieter> How can I remove a single revision from my history (not the last revision)
<gour> heh, cherrypicking
<gour> uncommit -r rev
<luks> simple answer: you can't. otherwise you can make a new branch that ends on the revision you want to remove, and use bzr replay for the rest of the branch
<Pieter> is replay a plugin?
<luks> it's in the rebase plugin
<luks> but naturally it won't be the same branch anymore
<luks> so merge, pull etc. from the original branch will be broken
<Pieter> yeah, I know the risks :)
<pasky> dato: thanks - is that http://samba.org/~jelmer/bzr/bzrk.png or smt lelsE?
<dato> pasky: precisely that
<pasky> dato: thanks!
<Rhamphoryncus> Weee.. recovering a hosed repository definitely puts me in a better mood
<Pieter> how did your repo get hosed?
<Rhamphoryncus> https://bugs.launchpad.net/bzr/+bug/150438
<ubottu> Launchpad bug 150438 in bzr "AssertionError: Could not find target parent in wt in wt4 _process_entry" [High,Confirmed]
<Rhamphoryncus> https://bugs.launchpad.net/bzr/+bug/150438/comments/9
 * Rhamphoryncus wonders if bzr will grow a "Directory not found: Fake it?" prompt ;)
<tca>  /join #commits
<libwilliam> A couple questions I hope someone can help me with. 1) Is there a function that returns the list of files applicable to be removed? 2) I am looking at messing with 'list_files' but by its description it makes me believe it will just list the files to stdout as opposed to 'unknown' and 'versioned' which returns the list of files.
<libwilliam> Ideally I would like a list of just the versioned files.
<Odd_Bloke> libwilliam: Could you reiterate (1)?  I don't quite understand what you're looking for.
<libwilliam> ok, let me rephrase
<libwilliam> I have a GUI that will have a tree view with the list of files under version control
<libwilliam> the user will select which files they would like to remove
<libwilliam> so I just need a list of files that are currently versioned
<libwilliam> not sure if that help clears things up any
<fullermd> Well, `bzr ls --versioned` can do it, so you could see what that's calling behind the curtain.
<pfharlock> bzr status?
<libwilliam> bzr status lists lots of different categories. I was looking for just versioned, I will check out the source for ls --versioned and see if I can figure out what is going on
<pfharlock> ahh, I see
<pfharlock> hey, I have a silly question, if there are any vim users in here, I've not had much luck with bzr diff --using="vim -d" foo.file.  It works fine with gvim, but I don't always have the option of using Xwindows.  Does anyone else use vim as their diffing tool and has a solution to this problem?
<pfharlock> also it tends to completely foobar whatever terminal I'm using at the time to the point where it just has to be closed, which seems odd.
<tca> Have anyone seen this problem before: https://bugs.launchpad.net/bzr/+bug/235055 ? It looks like there is a problem with the very first revision created by baz_import (I think that was the script used to import to bzr)
<ubottu> tca: Error: Could not parse data returned by Launchpad: The read operation timed out
<tca> ubottu: just retry the link. launchpad is a little slow now, but it is not down...
<ubottu> tca: Error: I am only a bot, please don't think I'm intelligent :)
<Odd_Bloke> Hmm, ubottu probably shouldn't direct the timeout comment to the user that pasted the bug number.
<Odd_Bloke> james_w: o/
<james_w> hi Odd_Bloke
<awilkins> Is the Windows/Python installer not supported anymore?
<Odd_Bloke> awilkins: I think it is.
<Odd_Bloke> Why do you ask?
<awilkins> Just not made an appearance in 1.5 flavour yet :-)
<Odd_Bloke> It's always lagged somewhat, and bialix is taking a break from Bazaar development ATM.
<Odd_Bloke> So he's still doing the installers, but looking for someone to take over.
<awilkins> It can't be a hard build, can it?
<awilkins> Are the sources for the packages available?
 * awilkins finds the Win32ReleaseChecklist page
<awilkins> Erm, what if the 1.5 sources won't build (the docs, in this case) ?
<awilkins> Heh, ignore me, turns out the HEAD version of docutils has a bug up it's ass
<awilkins> I don't suppose anyone would be inclined to trust me to proffer an upload of 1.5 installers for Win32 py2.5 and py2.4 ?
<awilkins> Hmm.
<awilkins> Do the team have a policy of zero fails in the test suite or are a certain percentage of fails expected?
<lifeless> awilkins: drive by comment - alexander had terrible trouble keeping win32 failures at zero; I know this frustrated him, so my guess is that 0 failures on win32 is not currently realistic.
 * lifeless waves and heads off
<awilkins> Ah well... not strictly relevent since I'm just running the testsuite on my shiny new 1.5 build
<awilkins> I can't fix it, it's "released" code
<antoranz> Hi guys!
<antoranz> remember me? new lines on windows? :-D
<antoranz> I thought of a "cleaner" way to knwo what files to process, instead of having them in a file
<antoranz> How about using bzr's api to know which files have been aded/modified?
<james_w> it's not about knowing what was added/modified, but what rules to apply to those files
<james_w> got to go, sorry.
<antoranz> show_tree_status?
<antoranz> Hell! I'm importing bzrlib.workingtree
<antoranz> but python says WorkingTree is not defined
<antoranz> but it's right there
<antoranz> in /usr/lib/pycnetral/blahblah/bzrlib/workingtree.py
<spiv> antoranz: can you pastebin the exact error?
<antoranz> sure
#bzr 2008-05-27
<antoranz> http://www.pastebin.ca/1030503
<spiv> Ah, you need "from bzrlib.workingtree import WorkingTree"
<antoranz> oh, ok
<antoranz> let me try
<antoranz> ok.... I got another error mesage... let's see where I get to. :-)
<antoranz> OK.... I got the working tree.... how could I ask for added files?
<jml> is there a "getting started with Bazaar" doc that I'm missing?
<antoranz> in bazaar's docs you can see the five minute intro doc... which is a nice crash course
<spiv> antoranz: maybe take a look at how bzrlib.status.show_tree_status is implemented, or how bzrlib.builtins.cmd_added is implemented.
<antoranz> well.... that's quite reasonable.. let me see the show_tree_status
<jml> is it possible to set the public_branch on a branch using the CLI?
<mwhudson> jml: the help for bzr send claims that it will remember the public branch, i think
<jml> mwhudson: it appears that my trunk has no public branch set.
<mwhudson> jml: bzr send ../trunk http://whatever --remember
<mwhudson> and then it will
<mwhudson> if the docs are correct anyway :)
<jml> mwhudson: so the public_branch arg to 'send' is the public_branch of the submit branch?
<jml> not the public branch of the branch being sent?
<mwhudson> jml: oh i see
<mwhudson> i guess you can run send -o/dev/null in  the trunk branch to set it
<mwhudson> or maybe there's some more sensible way
<antoranz> got it!
 * jml does the up-thread; commit dance
<antoranz> but I worry about the way the working tree tells me about changed files
<jml> antoranz: how so?
<antoranz> Let me paste the code in the pastebin so you can see.
<antoranz> http://www.pastebin.ca/1030550
<antoranz> I get the filename from an array
<antoranz> I wonder if that structure changes often. I think an object would be more "elegant"
<antoranz> jml: see what I mean?
<jml> antoranz: kind of.
<jml> antoranz: the return type doesn't change very often at all (grep NEWS for iter_changes)
<spiv> antoranz: unfortunately, objects are considerably slower than tuples :(
<jml> right.
<antoranz> well... speed is a nice explanaition for it... the code is working though. :-)
<jml> all things being equal, I'd use an object instead of a tuple. However, given that this is performance critical code, there'd need to be some obvious benefit for using an object.
<antoranz> how's the code? A1? :-D
<antoranz> considering it's my first python program
<Odd_Bloke> OTOH, in Python 2.5 (I think), you can 'name' the fields of a tuple.  So eventually, perhaps... :p
<jml> antoranz: it's ok.
<antoranz> ok
<antoranz> will ./ work in windows?
<jml> antoranz: if you bump into a really big file, you'll have memory problems.
<antoranz> or is there a straight way to get the pwd?
<jml> antoranz: os.getcwd()
<antoranz> well.... file are not so big right now.... so I guess it's ok for the foreseeable future
<jml> antoranz: also, you want to make sure you don't run convert2unix on binary files.
<antoranz> if file start to grow, II'll change it to process line by line instead of loading the whole file into memory
<jml> antoranz: there's no need for the exit(0) at the end also,
<antoranz> is there a piece of information that tells me if the file is binary?
<spiv> Odd_Bloke: 2.6 has collections.namedtuple
<antoranz> I guess "kind".... but what are the possible values?
<jml> antoranz: not that I know of. (but I'm pretty ignorant in this area)
<spiv> antoranz: "kind" is for distinguishing files/directories/symlinks etc
<antoranz> also, I shouldn't work on directories.
<antoranz> it's cambio[6][1]
<spiv> There's nothing in bzr at the moment that tracks if a file is meant to be "text" vs. "binary".  igc is working on adding a feature like that, though.
<antoranz> ok.... I'm working on text file for now... so I guess that's not a problem actually.
<Odd_Bloke> spiv: Ah, perhaps that's what I meant.
<Odd_Bloke> I just remember being given some code which used them and it not working for me.
<Odd_Bloke> Which suggests that it wouldn't work in 2.5, now I reflect on it.
<spiv> Odd_Bloke: :)
<antoranz> how do you say "!=" in python?
<spiv> Just like that.
<antoranz> ok... the problem was that I'm forgetting about using ":" at the end of the conditional.
<jml> antoranz: oh, that reminds me: use 'fileName is None' rather than 'fileName == None'
<jml> for reasons that have long since escaped my mind.
<antoranz> ok
<spiv> Faster, more precise, less punctuation.
<jml> spiv: thanks.
<igc> poolie: any thoughts on whether filtering ought to be applied to .bzr* files?
<spiv> (In particular, it's immune to a weird __eq__ or __cmp__ that might claim that a non-None object is equal to None)
<igc> abentley asked in his review whether it ought to be skipped for .bzrignore
<igc> I wonder whether Windows users would expect .bzrignore to have crlf or not
<TheSheep> igc: make a compromise, use crlf every second line ;)
<mwhudson> or go for the annoy everyone approach, and just use \r :)
<igc> TheSheep, mwhudson: interesting ideas. That ought to maximise the confusion. Maybe we could combine those ideas ...
<igc> and have lf, crlf, cr alternating
<igc> or make it random at the end of each line - better still  :-)
<antoranz> guys, thanks 4 ur kind help
<antoranz> C ya later!
<poolie> igc, i would say it probably should be applied for consistency; if the user configures it to be broken it's their responsibility
<poolie> uh, we should probably accept either separator in those files
<poolie> spiv, just trying to wrap up here then will leave
 * beuno waves
<beuno> hi everyone
<mwhudson> hi beuno
<beuno> LP code scanner still seems lagged
<poolie> hello beuno
<poolie> hello mwhudson
<beuno> I wonder how big the branches that where added really are...
<beuno> hello poolie
<beuno> so...  mwhudson...  I've been thinking performance all day
<beuno> aside from switching the templating engine, I've been thinking that, even if we improve the cost of rendering, it will still be rather expensive for some operations
<beuno> so it got me thinking how we can avoid that cost
<beuno> anyway, what do you think of adding a json generator, that we can can ask for via ajax, and refresh the screen's information with that?
<beuno> we would only render the HTML once, and the client will render from then on
<beuno> it can be added to the current code base, and used optionally  (we would still be able to render all pages)
<beuno> and cache the jsons on the client side, so once he retrieves a set of information, we can avoid as much as possible to hit the server again
<jml> beuno: do you know that roundtrips are the main bottleneck?
<beuno> and, if performance still is a bottle-neck for repeated request for the same screen, we can still implement a server side cache
<beuno> jml, I have no information at all of what the real bottlenecks are, just guesses from playing around with the code
<beuno> it's almost as expensive to render an annotated file than it is to annotate it with bzr
<beuno> that seems like something we need to solve
<beuno> (no information on LP, that is)
<jml> beuno: sure. That said, it's worth spending some time profiling to be certain that you are solving the right problem.
<beuno> jml, right, I have been profiling the code, and rendering *is* the main problem curently
<beuno> just not what specifically is bashing the LP so hard
<jml> ok.
<beuno> so, while we may find a better templating engine, it will still be a cost we will pay
<jml> *nod*
<beuno> and we can generate json files without rendering them through it, and serve them (maybe even avoiding turbogears, and get one step closer to get rid of so many dependencies)
<mwhudson> beuno: it's certainly an interesting idea :)
<beuno> mwhudson, :)   so, my next still is profiling with different templating engines, unless you have a different request
<mwhudson> beuno: i think that's sensible yes
<jml> what should I do to work around this? bzr: ERROR: Repository KnitPackRepository('file:///home/jml/Code/gtimelog/.bzr/repository/') is not compatible with repository SvnRepository('http://mg.pov.lt/gtimelog/svn')
<jml> oh, I see, there's a Subversion repo format now
<jml> has that always been there?
<Peng> jml: bzr-svn?
<jml> Peng: yes.
<Peng> jml: I dunno. It's been there as long as I can remember, but that's only a few months.
<rockstar> The Bazaar slogan should be "Make like a tree and branch"
<spiv> jml: probably "bzr upgrade --rich-root-pack"
<Peng> rockstar: Heh.
<Peng> rockstar: I'm not sure that's a very good slogan, but I definitely like it. :)
<rockstar> Peng, what's so bad about it?  :)
<Peng> Wait a minute. Slogans don't need to be a pile of information. Never mind about not thinking it's a good slogan. :)
<Peng> But it could say more about bzr's focus.
<jml> the error I get now is: http://pastebin.ubuntu.com/14954/
<jml> SubversionException: ("REPORT request failed on '/gtimelog/svn/!svn/vcc/default'", 0)
<spiv> jml: random guess: retry
<jml> spiv: it's happened 3/3 times
<spiv> jml: bzr -Dtransport -Dhttp perhaps.
<spiv> jml: but basically I think you're in bug report territory.
<jml> ok.
<jml> I'm using whatever bzr-svn that 'bzr branch lp:bzr-svn' gives me. Is there another branch I should be using? (maybe the one called 'trunk'?)
<Peng> jml: Try using a release. (bzr revert -r tag:bzr-svn-0.4.10)
<beuno> abentley, I sent a merge request which was rather large (1.7mb), and it seems BB hasn't picked it up yet.  https://lists.ubuntu.com/archives/bazaar/2008q2/042455.html
<spiv> jml: I strongly recommend sticking to released versions, or at least the "stable" branch.
<jml> spiv: it's not clear what the "stable" branch is, looking at lp.net/bzr-svn
<Peng> There isn't a stable branch, really.
<jelmer> 0.4 is the stable branch
<jelmer> (most of the time)
<Peng> Yeah, but wasn't it unstable from 0.4.9 to 0.4.10? Like, for 6 weeks?
<jelmer> yeah, it tends to regress from time to time
<Peng> I run bzr.dev, but bzr-svn 0.4.10.
<jelmer> at the moment, the 0.4 branch passes all tests though so it should be considered stable
<jml> jelmer: does http://pastebin.ubuntu.com/14954/
<jelmer> jml: hmm, that is a regression
<jelmer> I have a local clone of gtimelog here made with an earlier release of bzr-svn
<jelmer> unfortunately the testsuite doesn't catch this as we don't test svn over http (because it requires setting up apache)
<jelmer> that shouldn't matter as the subversion libraries promise one API for all three protocols, but there are subtle differences
<jelmer> jml: please file a bug
<jml> jelmer: will do.
<chmac> Is there a trac equivalent for bazaar? I found the bzr-trac plugin, but I wondered if there was something different
<poolie> chmac: there's also 'cart'
<chmac> poolie: Sweet, thanks, I'll check it out
<chmac> poolie: Any idea how far along it is?
<uniscrip1> given a .bzr repository, is it possible to find out what branches are in it?
<Peng> uniscrip1: You can use the heads plugin to see the current heads.
<uniscrip1> Thanks for that. I notice that if I delete subdir branches from a repo they become dead
<uniscrip1> is there any way to revive them?
<Peng> uniscrip1: Find the revid, and bzr branch -r revid:...
 * igc lunch
<uniscrip1> Peng: returns "ERROR: Not a branch"
<Peng> uniscrip1: You need to do it from a branch.
<uniscrip1> and lists the path to where I want to put the new (old) branch under the repo
<uniscrip1> I have a repo with a bunch of dead branches how do I revive one (get it out into a full branch)?
<uniscrip1> if I have no branch how do I 'do it from a branch'?
<bob2> cd /repo ; bzr branch -r revid:23890174kj234h1k2j34hk1l24h12kj4123l47897 /somewhere/to/put/it
<uniscrip1>  bzr branch -r  revid:mhosken@sil-mh4-20080527025333-o3z49yp16xykkwg6 ../test_branch
<uniscrip1> bzr: ERROR: Not a branch: "/home/mhosken/Work/dev/shorts/repos/repo_test/test_branch/".
<uniscrip1> same if I change ../test_branch to fred
<uniscrip1> or . fred
<uniscrip1> bzr 1.3.1 btw
<bob2> oops
<spiv> Ideally that should work.  Probably worth a bug report.  In the meantime, do it from any branch in the repo (even if you just create an empty one with "bzr init").
<uniscrip1> OK. Thanks for that
<abentley> beuno: Appears to have been caught by my spam filter.  I don't get much legitimate email in spanish.
<beuno> abentley, lol, understandable
<abentley> beuno: I should have it processed in the next few hours
<beuno> abentley, thanks
 * igc pick up kids
<mwhudson> beuno: so i checked out the latest version of your branch, it looks fine
<mwhudson> well, apart from using log._strip_NULL_ghosts
<Rhamphoryncus> "bzr check" has been stuck in "checking versionedfile" for several hours.  Should I leave it for a couple days? ;)
<jamesh> Rhamphoryncus: how big a branch is it, and how are you accessing it?
<Rhamphoryncus> previous step said 40000.  Fairly large project
<Rhamphoryncus> local files
<Rhamphoryncus> oh, current step says 0/10727
 * igc dinner
 * gour likes --lightweight checkouts with treeless repo and using 'switch' to change working branches
<Jc2k> gour: is there a good description of that online somewhere?
<gour> Jc2k: see paragraph in http://doc.bazaar-vcs.org/bzr.dev/en/user-reference/bzr_man.html#checkouts section
<Jc2k> gour: can this work like Gits branches? or is there still a directory for each branch?
<gour> Jc2k: i created (for a test) shared repo (--no-trees), then one branch within it and then did some 'hacking' in another dir after checking out. created another 'feature' branch and then was able to 'switch' between the two.
<gour> Jc2k: no idea. git is not on my todo list...i'm coming from darcs
<luks> Jc2k: still one directory per branch, but you normally don't see those directories
<gour> Jc2k: there is only one 'working' directory and bzr switch populates it with appropriate working tree
<Jc2k> background here is that i'm wanting to extend the Bazaar/GNOME documentation, and Git people cite this as something important to them
<Jc2k> luks: where would the directories be?
<Jc2k> repo/branch1, repo/branch2, repo/working_copy ?
<gour> repo/working can be anywhere
<luks> Jc2k: anywhere under the shared repository
<luks> Jc2k: you can put them to a dotted directory and never see them
<Jc2k> so i could:
<Jc2k> bzr init-repo .
<Jc2k> bzr branch some/branch .
<Jc2k> whoops
<Jc2k> i meant
<Jc2k> bzr branch some/branch .branches/trunk
<Jc2k> bzr co --lightweight-command-foo .branches/trunk .
<Jc2k> so the repo and working copy are in same folder
<luks> you can do that, but it's probably not the best layout
<luks> better to have the repo with branches outside of the working copy
<gour> Jc2k: i'd keep working dir out of shared repo
<Jc2k> i agree
<Jc2k> the git people likely won't buy it, though :)
<gour> Jc2k: you buy it ;)
<Jc2k> it would be nice for jhbuild integration their way, though
<gour> any news about emacs' adoption of bzr?
<trepca> its integrated into it already ?
<trepca> at least i can use it easily
<trepca> well, except for diffs
<jml> gour: nothing yet. I think they are waiting on savannah and a couple of specific performance improvements.
<gour> jml: let's hope it will happen soon
<jml> trepca: I use dvc in emacs with bzr and use it to get diffs all the time.
<trepca> oh!
<trepca> how did you install it
<trepca> i use aquamacs
<trepca> didn't manage to get it working
<jml> trepca: I just dropped it into my load-path
<trepca> damn
<jml> (load-file "/home/jml/Code/dvc/++build/dvc-load.el")
<jml> trepca: I just have that in my .emacs
<jml> trepca: and followed whatever build instructions were in the tarball.
<mwhudson> is aquamacs any good?
<mwhudson> i've always been quite suspicious of it on principle
<trepca> hm, there is not dvc-load in my tarball
<trepca> aquamacs works great for me
<trepca> jml: btw, where did you get the tarball ... seemed to me that you can only checkout the source form the DVC site
<gour> hmm, i put: checkout=checkout --lightweight in ALIASES section of conf file. however, if i use bzr co it is not in effect although i might expect it to be?
<jml> trepca: by "tarball", I meant "checkout" it appears. "bzr branch http://bzr.xsteve.at/dvc/"
<trepca> mhm
<jml> trepca: I just pulled the latest -- './configure; make' builds a dvc-load.el in the top-level directory for me
<trepca> woohoo! works!
<trepca> thanks!
<trepca> jml: how do you view the log with dvc ?
<jml> trepca: uhh, I don't generally.
<trepca> ok
<james_w> hey jml
<jml> james_w: hi
<james_w> did you get back ok?
<jml> james_w: sorry I had to bolt before your set the other day
<james_w> no problem.
<jml> james_w: yeah, I got back fine. Had to fight a couple of bears to get past the checkin desk, but that's no big deal
<trepca> jml: what about creating diffs with another revision...not head
<jml> trepca: I use the command line for that too :)
<jml> trepca: basically, both of those ops are outside my normal dev cycle.
<jml> trepca: so I don't mind switching out of emacs
<trepca> so what is the purpose of dvc then :) ?
 * gour is fetching emacs from bzr repo
<awilkins> Last night I asked about the Python installers for bzr/win32 : since I had most of the dependencies anyway I built my own ; would they be wanted/trusted for the downloads page?
<james_w> awilkins: I'm not sure, though I don't see why not.
<james_w> perhaps mailing to the list first would be a good idea.
<lamalex> Hey guys, I'm trying to push to launchpad, but I keep getting a message about being unable to obtain a lock, and that it's help by me on "host vostok"
<lamalex> how can I get rid of that lock, and why did that happen
<bimberi> lamalex: bzr break-lock [LOCATION]
<lamalex> merci beaucoup
<lamalex> is there a way to check if it's locked? I just tried to push again and it still said it was locked
<james_w> lamalex: launchpad is a bit weird here
<james_w> you probably need to run the break-lock command a few times.
<james_w> and use sftp:// rather than bzr+ssh:// as well I believe.
 * bimberi takes note - for next time :)
<lamalex> weird
<lamalex> I'll try that
<lamalex> it's not even showing up as locked in bzr info
<lamalex> so just s/bzr+ssh/sftp
<asabil> iirc you need to run break-lock twice
<asabil> and it doesn't matter if using sftp or bzr+ssh
<lamalex> Is that a bug?
<asabil> don't know
<lamalex> sounds like it
<lamalex> there we go, it's pushing now. Thanks guys
 * lamalex wants to kill bzr
<lamalex> It's telling me the branches have diverged, and to merge, but when I do a merge, it says nothing to do
<Kinnison> Are the two branches public, can we see?
<lamalex> the one branch is local on my hd
<lamalex> do you want the output of bzr info or somethign?
<Kinnison> It was more for me to try the pull/merge/diverge check
<luks> are you sure you are merging from the same branch you are trying to push to?
<Kinnison> can you please run 'bzr missing url-to-push-location' ?
<lamalex> I fixed it, I don't know how this happened but it dropped /trunk off of the url
<lamalex> pushed now :) thanks guys. I really love how helpful #bzr is, compared to many other freesoftware irc channels
<igc> night all
<visik7> why I've to commit to use bzr upload -r <revnumber ?>
<visik7> make no sens
<jelmer> visik7, please file a bug
<visik7> where ?
<jelmer> https://launchpad.net/bzr-upload I think
<beuno> visik7, well, there is a specific reason for that
<beuno> ah, well, no
<visik7> why ?
<beuno> not for -r
<beuno> as jelmer says, file a bug, we'll get it fixed  :)
<beuno> my mistake, misread too fast
<weigon> jelmer: I have a small problem with pushing into a svn-tree (bzr-svn 0.4.10)
<weigon> bzr: ERROR: Tags not supported by SvnBranch(...)
<weigon> $ bzr info
<weigon> Standalone tree (format: dirstate-with-subtree)
<jelmer> weigon: bzr-svn doesn't support tags
<jelmer> (yet)
<weigon> that's fine
<visik7> lp: use a specific port ?
<weigon> but how can I move in from there ?
<weigon> jelmer: looks like this happens at the end of the push
<jelmer> weigon: you're trying to push a branch with tags into svn
<weigon> yep, can I remove the tags somehow and get a successful push ?
<jelmer> bzr tag --delete <name>
<visik7> could you get http://bazaar.launchpad.net/~bzr-upload-devs/bzr-upload/ working ?
<visik7> I can't
<weigon> jelmer: thanks
<beuno> visik7, loggerhead must be down again
<beuno> oh, it's not: http://bazaar.launchpad.net/~bzr-upload-devs/bzr-upload/trunk/files
<beuno> visik7, what are you trying to find?
<visik7> pull from http
<visik7> 'couse lp: is firewalled
<visik7> here
<beuno> visik7, try:  http://bazaar.launchpad.net/%7Ebzr-upload-devs/bzr-upload/trunk/
<visik7> yes
<beuno> visik7, did you get around to filing that bug?   I can look at it after work if you do  :)
<visik7> yes patch added
<visik7> check if it's correct
<weigon> jelmer: $ for t in `bzr tags | awk '{print $1}'`; do bzr tag --delete $t; done does the trick
<jelmer> weigon: :-)
<visik7> beuno: is ok ?
<beuno> visik7, you rock  :)
<visik7> :)
<visik7> it's damn easy with python and bzr
<visik7> combo killer
<beuno> visik7, do you think you can use bzr send, so you can get attribution for you work?
<visik7> yes I maybe need to setup bzr for launchapd
<luks> beuno: commit has an --author option exactly for this :)
<visik7> but anyway I'm behind a firewall that suck
<visik7> and doesn't work for lp:
<beuno> luks, ah, right, thanks
<beuno> visik7, I'll use that and make it easier for you
<beuno> thanks a lot. You'll see it i trunk in a while
<visik7> thanks
<visik7> is there a way to commit into a branch only some files ?
<visik7> yes
<visik7> stupid me
<awilkins> jelmer: Where bzr-svn has changed it's mind about file-id values is there a way of upgrading a branch to the new file-id mapping?
<jelmer> awilkins: bzr-svn shouldn't change its mind about file ids, that would be a critical bug
<Pilky> anybody know why when I commit a checkout to launchpad it doesn't update on the launchpad pages? (does update in loggerhead)
<beuno> Pilky, code scanning is behind
<beuno> so it will take a while for LP to pick it up
<awilkins> jelmer: Well then, I think I may have hit a bug....
<awilkins> jelmer: What about revision-ids which is what aI actually meant ...
<jelmer> awilkins: they shouldn't change either, unless you change the branching scheme or are branching from a different path
<LarstiQ> which happens rather frequently
<Pilky> beuno: well it's showing my last commit as revision 9, 3 days ago. I switched to using checkouts with revision 10 and it never updated, and I just commited revision 11 about 10 minutes ago
<awilkins> jelmer: Ah, I changed the branching scheme, because the structure of the repo was confusing the auto-scheme code
<Pilky> (revision 10 was committed 2 days ago)
<awilkins> jelmer: Problem was that I had a vendor-branch folder, which itself was a container for a project/branch tree, as well as a root level project/branch hierarchy
<Chris12349> will bzr let me replicate data between two bazaar servers?
<Peng> Chris12349: Well, that's what "push" and "pull" are for, but they only operate on single branches.
<Chris12349> Peng: gotcha, thanks
<beuno> Pilky, it will get fixed, don't worrk
<beuno> *worry
<visik7> beuno: good modification to my patch I would suggest it to you
<beuno> visik7, you're fast  :)
<beuno> I thought it would be clearer
<visik7> good good
<beuno> I hope I got your name right, it isn't very clear in LP
<visik7> CamelCase
<visik7> :)
<beuno> yes, I guessed as much, but I wasn't sure if it was FirstnameLastname
<beuno> or the other way around
<visik7> the other :P my fault
<beuno> aaah, I suspected
<beuno> thanks for the bug report/fix, btw
<visik7> you know I've never commited a bugreport/fix but with LP and python and bzr it's dead easy
<visik7> great tools
<bratsche> Is there a way to find out the nearest ancestor branch for a branch you're working in?
<bratsche> Like, I have branch A and then I create branch B from A.  And later on inside B I want to do "bzr diff -r ancestor:A"
<bratsche> I do this type of thing -all- the time, and I don't want to have to type in the URL for A.  Is there an obvious way to get that URL from bzr?
<radix> I do it all the time too, where "A" is something like "../otherbranch"
<radix> so it doesn't seem so bad
<bratsche> Mine is remote, and at the moment I just have a bash script setup to do "bdiff --repo-A" or something to tell it which repo to diff against.
<bratsche> But I'd rather not even have to do that much by hand.. if I could get bzr to return the nearest ancestor branch then the script could figure out where to diff against for me.
<radix> bratsche: "bzr info" shows the parent branch, btw
<radix> I don't know how to get that out in a simple way to include on the command line
<radix> or to include in `` or whatever
<Jc2k> bratsche: bzr help revisionspec ?
<bratsche> radix: It doesn't always show it.
<bratsche> Oh, I want submit:
<bratsche> I didn't know about that.  Thanks.
<bratsche> Oh, it doesn't seem to always work though.
<Jc2k> np
<Jc2k> you probably need to pull from the remote branch once
<Jc2k> so that it stores the parent branch
<Jc2k> i dont know why parent isnt set when you branch, tho
<bratsche> bzr: ERROR: No submit branch available for branch "/home/bratsche/bzr/my-branch"
<Jc2k> right. it says it falls back to parent branch. so is there a parent branch in bzr info?
<bratsche> I'll play with this some more later and see if I can figure out why this is happening.
<bratsche> No.
<Jc2k> if not, you can set it with bzr pull --remember <remote-location>
<bratsche> repository checkout root: .
<bratsche> checkout of branch: sftp://path/to/branch/
<bratsche> shared repository: /home/bratsche/path/to/repo
<Jc2k> good luck
<bratsche> Okay thanks.
<awilkins> jel
<awilkins> mer
<awilkins> Dang, he isn't here
<halstead> Is there an easy way to export a read-only svn repository from a bzr branch?
<awilkins> halstead: Not as far as I know
<awilkins> halstead: You could try configuring a read-only empty repo and pushing branches to it, but I don't know how well that works.
 * awilkins tries pushing to an empty SVN repo
<halstead> If I try to push to an empty repo I'm warned, ERROR: These branches have diverged.  Try using "merge" and then "push"
<awilkins> Hmmph, my error is more impressive than yours "tuple index out of range"
 * awilkins updates to a more recent build of bzr-svn
<Jc2k> are you using bzr push or bzr svn-push?
<awilkins> has I am running into different but no less annoying problems on a 1.5 / HEAD of 0.4 combo
<halstead> I was using bzr push. I will try the other.
 * Jc2k isn't sure when svn-push should be used tbh
<awilkins> Hmm. Trying to branch it in was less than successful ; I seem to have ended up with an SVN repo containing raw bits of bzr branch.
<halstead> Hmm..
<halstead> It asks me to merge them first but then refuses to merge because they lack a common ancestor.
<awilkins> halstead: I managed to push to an empty branch but ran into an error
<halstead> awilkins, How did you?
<awilkins> svn-push
<awilkins> Target URI was a subfolder of an empty project-level folder
<awilkins> It's running into an assertion when it tries to add a file.
<beuno> mwhudson, ping
<Peng> Is it just me, or is making 165 360-byte range requests for signatures.knit when making a branch kind of wasteful?
<mwhudson> beuno: hi there
<beuno> mwhudson, you wake up pretty early, don't you?
<halstead> Thank you, I didn't try an empty sub directory. That works great for me. :)
<awilkins> Peng: How big is signatures.knit? (small, I'll wager)
<mwhudson> beuno: it's 09:41 here
<mwhudson> beuno: so not really...
<Peng> awilkins: Almost 60 KB.
<beuno> mwhudson, oh?  I thought you where in australia, but it seems you're not  :)
<awilkins> Peng: Ooooh, scary. Maybe they should just download all of it :-)
<Peng> ...It would've used slightly less bandwidth if it downloaded the whole thing once.
<mwhudson> beuno: no, new zealand
<Peng> Or, I could upgrade to packs. ;)
<mwhudson> Peng: which bzr version?
<beuno> mwhudson, I'll have to add new zealand to my gnome-clock too then  :p
<Peng> mwhudson: Launchpad, so 1.3.
<beuno> mwhudson, did you see the loggerhead file-view yet?
<mwhudson> i have this recollection that some bugs in this area have been fixed
<Peng> Yeah.
<mwhudson> Peng: but this is a client thing
<Peng> mwhudson: Launchpad was mirroring my branch.
<mwhudson> Peng: oooh
<mwhudson> yeah, we'll be upgrading soon...
<mwhudson> beuno: yes!
<mwhudson> beuno: basically fine, apart from:
<mwhudson> 1) the drwxrwxrwx nonsense should be replaced with an icon for file, executable file, directory or symlink
<mwhudson> 2) why have the link icons after the file name and revision number in the table?
<mwhudson> 3) what does the clipboard icon do?
<Peng> What are .bzr/branch/pull and x-pull?
<Peng> Bwahaha.
<beuno> mwhudson, 1) I agree, although out of the initial scope (it requieres programming). I can probably add that after we finish this.
<Peng> Yeah, there have been major improvements since then. Now it downloads signatures.kndx again before downloading each range of signatures.knit!
<beuno> 2) We're trying to be consistant with what is a link and what's not. So we added an icon to represent it. We can remove it if it's confusing rather than helpful
<Peng> Actually, I don't know WTF it's doing. But it downloads revisions.kndx and signatures.kndx a hell of a lot.
<beuno> mwhudson, 3) First attempt at an icon for "log". We also added a "Help" tab, which will explain all icons
<mwhudson> tooltips for the icons would be good i guess
<beuno> yeah, I'll make sure to make a note of that for the HTML/CSS stage
<mwhudson> i guess for 2) i'd like to play with it before thinking to hard
<mwhudson> it's not a difficult thing to change is it?
<beuno> no, it's not. I can do it if you think it really makes a difference
<mwhudson> let's leave it for now
<beuno> we can (and will) always change it later on
<beuno> as for the _strip_NULL_ghosts, which I can clearly see there is a comment saying "don't use it", it's a bit of a problem, as if I don't loggerhead blows up. I may have to take a different approach
<mwhudson> yeah, would be good to get some proper advice here
<mwhudson> i think loggerhead need it for the same reason log needs it though: to give stuff to merge_sort
<beuno> yeap yeap, I'll send a mail to the list
<beuno> we may have to change that whole block of code, but it seemed like an overkill at the time
<mwhudson> yeah
<libwilliam> I am sure every time I log into this channel everyone goes "sighhh".... I am trying to use the  Inventory.entries() method to get a list of the versioned files. The API's description is "Return list of (path, ie) for all entries except the root. "... I understand how to use the C/Python API so I don't need any help on using it, but I need help with is what type of data the returned list contains.
<libwilliam> It says it contains (path,ie) but I don't know if it those are elements are a set, tuple, list, etc
<mwhudson> i did a little thinking about how you could do loggerhead without any ahead of time caching
<mwhudson> i think the graph api is getting mostly there
<james_w> libwilliam: path is a string
<mwhudson> though i don't really see how you can do "page 102 of 300" of the changelog view efficiently without preserving some state
<mwhudson> libwilliam: why not try it interactively?
<james_w> libwilliam: ie is an InventoryEntry object
<beuno> mwhudson, yeah, I have a few ideas floating around in my head too. I keep thinking the sqlite cache is evil
<libwilliam> I figured it was a string, the part I am unsure on is it is returning a list of those two objects stuck together. What is the type that keeps the path and ie together?
<mwhudson> beuno: eh, i don't think that's particularly relevant here?
<libwilliam> like a list of sets, or list of tuples, I am very unfamiliar with python
<mwhudson> phone, brb
<james_w> libwilliam: it's a tuple
<libwilliam> james_w: thank you!
<beuno> mwhudson, well, yes and no. We're already caching with sqlite, and that *does* give as an overhead I think we can either, get rid of, or replace with a much better one
<mwhudson> beuno: but the code we're talking about replacing is all about the relationship between revisions
<mwhudson> what is cached is (mostly) data _about_ revisions
<mwhudson> (i'm sure i said this yesterday :)
<beuno> right, sorry for drifting away. I understood it, just mixed in something else I had in my head  :)
<mwhudson> :)
<beuno> well, the latest graph work jam introduce seems to make it cheaper to do what we do now, so yes. I'd have to compare them, and, on the other hand, if showing the parent is costing us a lot, we may want to show just the revision info first, and fetch the rest if it's requested
<beuno> I've been thinking about that behaviour a lot
<jam> I have been summoned?
<beuno> ah, jam, hello  :)
<beuno> well, since your here...  want to talk graphs?
<awilkins> halstead: Yay, I think I may have fixed the bug I was hitting.
<halstead> awilkins, What was it?
<awilkins> Part of the code wasn't passing a baton (basically a null pointer but SVN code team calls them "batons" because they get passed a lot)
<beuno> mwhudson, if we could fetch through ajax the details of each revision, and not by default, browsing through logs will be much cheaper
<jam> beuno: I would like nothing better, I guess
<mwhudson> in fact, if you cached the data in a way that was less of an abuse of an rdbms you could do all sorts of interesting things...
<awilkins> halstead: This is bzr 1.5 and the HEAD of the 0.4 branch of bzr-svn
<mwhudson> beuno: perhaps
<jam> beuno: the sqlite cache is evidence that we are doing something inefficiently
<jam> certainly we should be able to have primary access through bzr
<jam> *should*
<mwhudson> beuno: but... emacs is 80000 revisions of mainline history
<jam> if we can't then we need to think about why not
<mwhudson> if you want to get revision 20000 ...
<mwhudson> jam: the big inefficiency is files changed between revisions in a large tree
<halstead> awilkins, I was having success with bzr 1.5 and bzr-svn 4.10.
<awilkins> I don't think 0.4.10 is too far from the HEAD.
<beuno> mwhudson, as I understand it, now, we're getting *all* revisions everytime we fire up loggerhead, so that clearly doesn't work well on deep-history repos
<jam> mwhudson: does 'item_keys_introduced_by' work for you?
<jam> or is the problem about deleted files
<jam> which iirc don't show up there
<beuno> if you accessed bzr directly, we would just grab what we're going to show
<jam> certainly having to do a diff for 100 revisions to compute the changed files is a bit problematic
<jam> But I think that shows something up in bzr itself that we should be dealing with
<mwhudson> jam: maybe, i don't know what that is :)
<jam> mwhudson: Reopository.item_keys_introduced_by is what we use for fetch
<jam> you pass in a list of revision_ids
<jam> and it returns (file_id, revision_id), or (inventory, revision_id) etc
 * mwhudson is on the phone
<jam> :returns: An iterable producing tuples of (knit-kind, file-id,
<jam>     versions).  knit-kind is one of 'file', 'inventory', 'signatures',
<jam>     'revisions'.  file-id is None unless knit-kind is 'file'.
<jam> mwhudson: fine, run away :)
<beuno> lol
<jam> beuno: what is the graph question
<beuno> jam, loggerhead was using deprecated methods, which I replaced for a new one
<beuno> let me find the diff...
<jam> beuno: get_revision_graph()?
<beuno> right, loggerhead is currently unusable in LP
<beuno> actually,  repository.get_graph(
 * mwhudson thinks perhaps multiple issues are getting confused here
<jam> beuno: repository.get_graph() shouldn't be deprecated
<jam> it is the recommended route
<jam> you just have to have a locked repo
<jam> mwhudson: you were saying that getting the list of 'modified' is expensive, and for fetch() we use that function
<jam> it may not be sufficient for what you want for 'log'
<beuno> jam, no no, that's the one I replaced it with, sorry
<mwhudson> jam: hm yes that does look interesting
<beuno> yes, it was using get_revision_graph
<jam> yeah, I think in dev get_revision_graph() was completely nuked by lifeless
<jam> it was "evil" but it had its uses
<jam> beuno: if you *need* to grab the whole revision graph, that is something to re-evaluate if possible
<mwhudson> jam: right
<beuno> jam, yes, that's what we are looking into
<mwhudson> i think with the newer bzrlib apis there is less and less need to do whole history stuff when loggerhead starts up
<beuno> loggerhead reloads this everytime you start it
<jam> Unfortunately, I haven't found a way to do dotted revnos without the whole graph :*
<jam> :(
<mwhudson> yeah, i think we'll still need to cache revid_to_revno_map
<jam> beuno: "on startup" or as part of looking at a branch, or what?
<beuno> jam, on startup currently
<jam> beuno: so it does it for all branches under its control or what?
<mwhudson> yes
<jam> mwhudson: yeah... I can think of ways to partition it to be somewhat more efficient than having 80k rows for every branch
<beuno> I then do  graph.iter_ancestry, but I'm forced to use _strip_NULL_ghosts, which has strong warnings not to use
<jam> beuno: I don't know _strip_NULL_ghosts, but I can describe how iter_ancestry returns ghosts
<jam> (entry, None) is a ghost
<mwhudson> DEB [20080528-10:20:25.575] loggerhead.bzr_dev: Reload branch history...
<mwhudson> /home/mwh/src/loggerhead/trunk/loggerhead/history.py:205: DeprecationWarning: bzrlib.repofmt.pack_repo.KnitPackRepository.get_revision_graph was deprecated in version 1.4.
<mwhudson>   self._revision_graph = branch.repository.get_revision_graph(self._last_revid)
<mwhudson> INF [20080528-10:20:31.185] loggerhead.bzr_dev: built revision graph cache: 5.3389949798583984 secs
<mwhudson> is what loggerhead/trunk says on startup, pointed at launchpad, currently
<mwhudson> jam: i don't think we really care about stripping ghosts, per se
<mwhudson> jam: we just want something we can safely feed to merge_sort
<jam> mwhudson: just that passing ghosts to merge_sort causes graph cycle failures, right?
<mwhudson> (which explodes if you give it a graph containing referencing ghosts)
<mwhudson> yeah
<beuno> well, we could probably skip them as we loop...
<mwhudson> -containing
<jam> beuno: _strip_NULL_parents should blow up for iter_ancestry
<jam> because the node returns None for parents
<mwhudson> i think for the short term maybe we should just duplicate _strip_NULL_ghosts in launchpad
<jam> which isn't iterable
<beuno> jam, I apply it after, and it doesn't
<beuno> well, wait
<jam> beuno: there *is* _old_get_graph()
<beuno> I do something else
<jam> which has the same warnings (I'm sure from robert)
<beuno> parent_map = dict(((key, value) for key, value in graph.iter_ancestry([self._last_revid]) if value is not None))
<beuno> 3121 def _old_get_graph(repository, revision_id):
<beuno> 3122     """DO NOT USE. That is all. I'm serious."""
<beuno> :)
<jam> beuno: you could do
 * mwhudson observes that the loggerhead instance running on launchpad is wedged yet again
<jam> well, you could reproduce the two fnuctions
<jam> functions
<jam> but you would essentially just be doing the same thing
<jam> and just not re-using the bzr functions for it
<beuno> yeah, I just thought that I was taking the wrong approach
<mwhudson> well, we are
<jam> beuno: if it makes you feel better 'bzr log' does exactly the same thing inline
<mwhudson> whole-history operations are bad
<beuno> heh, yes
<jam> part of Robert's push to get rid of get_revision_graph
<mwhudson> unfortunately......
<jam> without actually getting rid of it :)
<jam> mwhudson: james_w and I talked about possibly doing a lazy merge_sort that doesn't require whole history
<mwhudson> the issues loggerhead has to solve are very similar to the issues faced by log
<jam> the difficulty is it still required an awful lot of history
<beuno> mwhudson, from your experience, do you think getting the basic data  we show currently on screen with the new set of APIs (not the expanded one) from bzr directly will decrease performance too much?
<jam> mwhudson, beuno: If all you want is the revisions that are merged (as sort of a big set) I can give that to you
<jam> graph.find_unique_ancestors(tip, [others])
<james_w> I wrote one that is about the same speed for full history, and to produce the first revision on the bzr branch, but lightning quick on the emacs one due to the linear history.
<jam> However, if you want to *number* them, it gets tricky
<Peng> Why does BzrError inherit from StandardError?
<james_w> however, I didn't propose it as I wasn't confident that the behaviour would hold for all branches.
<jam> james_w:  did you get away from traversing the entire left-hand-history?
<jam> or is that just the one that goes linearly backwards and ignores revnos
<james_w> jam: yes, for linear history, but not if there was merges.
<jam> Peng: what would you have it inherit from?
<mwhudson> beuno: i think this is worth investigating
<jam> james_w: I'm saying you worked a bit on lazy dotted revnos, I know you also worked on 'git-log' or whatever it was called
<james_w> jam: and yes, this was without generating revnos, which was the other reason for not proposing it.
<Peng> jam: Not sure. Exception, I think.
<mwhudson> it will probably make things a bit slower
<jam> Peng: is StandardError a problem for you somehow?
<mwhudson> as jam says, numbering the revisions will be the the hard part
<jam> Peng: class StandardError(Exception)
<jam>  |  Base class for all standard Python exceptions that do not represent
<jam>  |  interpreter exiting.
<jam> seems reasonable to me
<Peng> The library reference says "The base class for all built-in exceptions except StopIteration, [etc.]".
<Peng> BzrError isn't built-in.
<jam> Peng:  so why not class BaseException(__builtin__.object)
<jam>  |  Common base class for all exceptions
<jam> Anyway, I don't know if poolie had a specific reason or not
<beuno> mwhudson, I'd like to try it. If it's a bit slower, but scales well, then a static html cache may be better than a sql one
<jam> It hasn't ever been an issue
<jam> beuno: any problem with a simple squid proxy?
<mwhudson> beuno: can we please stop talking about the sql cache?
<jam> I suppose you could more easily determine when the cache was out of date
<mwhudson> beuno: it's really a separate issue
<beuno> jam, well, first, that would be a LP-specific solution, I think. Second, we want to start using revnos as URLs, which will change the content for the same URL
<jam> beuno: well, rarely for most projects, but sure
<jam> I don't really know how you tell squid when things are / are not changed
<jam> or HTTP proxies in general
<james_w> jam: yeah, the dotted revno stuff stalled as my algorithm produced different results to the existing one, and I couldn't exactly justify it, and I couldn't see an easy way to produce the same results
<jam> james_w: I don't know if I mentioned it to you, but I had changed that specific case as well
<jam> it is rather 'edge' and didn't seem like it had a valid counting either way
<jam> The bigger problem is that it wouldn't really help emacs
<james_w> let me dig up the mail to refresh.
<jam> with 80,000 linear revisions
<jam> my bigger issue with your work is that it wasn't "resumable"
<james_w> ah, true.
<jam> in that you could compute some numbers, but you couldn't then ask it to incrementally compute some more
<jam> so something like 'log'
<jam> which would like to find out some numbers, go back, find some more, etc.
<jam> but if you can even get close to something that doesn't require searching all of history, that would be a start in the right direction
<beuno> mwhudson, don't we reload the whole history at startup to make sure our current sql cache is correct?  That said, I will leave it aside, sorry for the annoyance
<mwhudson> beuno: no
<mwhudson> well, there's the cron-like thing that fills the cache
<mwhudson> but that's a bit different, and stupid
<beuno> mwhudson, ok, I thought it did, hence my insistance.  I'll drop it and go deeper in the code
<mwhudson> (we should just fill the cache lazily like sensible people)
<mwhudson> or, probably, drop the revision cache
<mwhudson> and bully people in here to make the first call to get_revision a bit faster :)
<awilkins> Heh, I'm just working out how to add a revision metadata cache to bzr-eclipse
<jam> mwhudson: now what are you hinting at?
<james_w> jam: yep, I was hoping to extend it in that direction after the basic algorithm was worked out, but I don't know if it would even have been possible.
<awilkins> Because the way the Eclipse APIs call it calls "log" for each and every file that it views
<mwhudson> jam: well i'm mostly paging in old neurons here
<mwhudson> jam: but iirc, the first time you call get_revisions() on a locked launchpad repository it takes like 300 ms
<jam> mwhudson: I would expect that repository.get_revisions() on a Pack repo to be considerably faster than a Knit repo
<jam> because Knits had to load the whole list of revision_ids
<mwhudson> hm, time to benchmark!
<jam> (the full indexes)
<mwhudson> jam: you seem to be right
<mwhudson> well, in that case i think we can probably just dump the sql revision cache
<jam> mwhudson: $ py -m timeit -c "from bzrlib import branch; b = branch.Branch.open('.')" "b.lock_read(); b.reposi
<jam> tory.get_revisions([b.last_revision()]); b.unlock()"
<jam> 10 loops, best of 3: 18.8 msec per loop
<mwhudson> yeah
<jam> mwhudson: on my much older server running knits: 10 loops, best of 3: 352 msec per loop
<mwhudson> jam: and i think you want -s, not -c
<jam> mwhudson: I think i do too, but it was working :)
<mwhudson> jam: great, i like it when problems just evaporate
<jam> mwhudson: with -s, it is now  15.3 msec per loop
<jam> and the same on the slow host
<mwhudson> hm so the revision cache makes 0.05 - 0.10 s per page difference
<mwhudson> (on launchpad, a pretty big tree)
<mwhudson> --> it should die
<mwhudson> (but after we've got something more current running on launchpad)
<jam> mwhudson: wow... I guess that's the way it goes
<dlee> Not sure why I've never thought of this approach before, though I bet someone else has  ny reason we shouldn't have a case-insensitivity (for file names/folder names) option within a repo, like we have for shared?  I'm having mucho trouble with file/folder name casing under Windows Bazaar 1.5 (and back through 1.0).
<jam> dlee: because a lot of people on other platforms have multiple files with the same name but different cases
<jam> otherwise I would tend to agree with you
<dlee> Yes but probably not for a repo where you'd *want* case insensitivity
<jam> Makefile and makefile tends to be more common than you want
<jam> dlee: the other problem is figuring out how to be 'case insensitive but preserving'
<jam> which is what people really want
<awilkins> The only trouble I have is that the client library has trouble renaming files in case only on *dows
<jam> and when you do an "ls" you see different names than your stored list
<dlee> In other words, I thought this would give everyone their cake--could even arrange for users to be able to set the option as a default.  For me, the question is, can anyone think of a scenario where you'd want case sensitivity in only part of one repo.
<awilkins> But that's a trivial fix - you just check for case-only differences and rename via an intermediate
<dlee> I'm getting conflicts, extra "removed" files that still exist, etc.
<beuno> mwhudson, so we can scrap sqlite?  or are we caching anything else?
<beuno> (I promise my questions will get less stupid as time goes by)
<igc> morning
<mwhudson> beuno: the file change cache still makes a big heap of difference
<mwhudson> like 12s -> 1s
<dlee> I tried both a Unix host and a Windows host, both using bzr serve, in case that matters.  I'm not sure it does.
<mwhudson> but maybe we can do something about that using more modern bzr apis too...
<beuno> ok, good, this is looking better
<mwhudson> indeed :)
<beuno> so, my ToDo right now is: benchmark Genshi, and if it doesn't make a big different, a different templating engine. Then, get rid of the revision cache, then, look into performance with newer bzrlib APIs for files changed
<beuno> sound sane?
<beuno> s/different/difference
<mwhudson> beuno: yes, very
#bzr 2008-05-28
<mwhudson> beuno: i should say that it's not just performance we'd be looking for with genshi, but also memory usage
<mwhudson> beuno: if you change the limit for 'fancy' diffs up to say 10000 and view a big diff and watch loggerhead's memory usage in top you'll get a fright :)
<beuno> right, I tend to see memory as a part of performance, but, of course, you're not in my head.
<beuno> cool, I'll create a branch with a big diff and use that
<beuno> that helps  :)
<beuno> I'd also like to do something about setup.py sooner than later, so we don't break people's computers to install loggerhead
<mwhudson> beuno: well, you were ambiguous enough for me to want to check
<beuno> mwhudson, the more explicit, the better, so thanks for clearing that up
<mwhudson> beuno: when we first identified the problem with big diffs the irc transcript went like this:
<mwhudson> <mwh> right, i have the branch set up, let the machine crushing begin!
<mwhudson> *** mwh has quit (remote closed the connection)
<beuno> lol
<mwhudson> *** mwh has joined the channel
<mwhudson> * mwh didn't expect that to work so well
<mwhudson> the OOM killer got involved and killed x
<dlee> lol
 * beuno starts setting up a test enviroment in a different PC
<mwhudson> beuno: another bit of advice:
<mwhudson> don't use firefox to test the url, use curl or something instead :)
<beuno> ah, makes a lot of sense
<dlee> If I could dare one more question:  Is cvsps-import still the most preferred way of importing CVS to Bazaar (one-way, one-time should be all I need, but for a lot of projects, again with mixed case and Windows line endings)?
<beuno> two memory hoggers at once won't help
<mwhudson> dlee: yes
<dlee> I even have one project that ues vendor branches :P  (Tailor doesn't handle those too well)
<mwhudson> dlee: another sane option aiui is to use cvs2svn's 'fastexport' stream and bzr-fastimport
<dlee> Ah thanks!  I looked at that but missed how to get it all put together.
<dlee> looked at fastexport I mean
<beuno> ok, well, mwhudson, jam, many thanks for all the input/patience, I'll get back to coding for a while
<beuno> mwhudson, I'll move _strip_NULL_ghosts into loggerhead so we're on the safe side for now
<mwhudson> beuno: thanks
<beuno> mwhudson, just to recap, for the new theme for files, it's generally OK as-is, or is there something you want changed before we move on?
<mwhudson> beuno: it's ok with me, we should probably give some other people a chance to respond :)
<beuno> mwhudson, heh, yeah, probably. *Some* work has been done on the diff view already, so I hope to get that out soon too.
<mwhudson> great
<beuno> awilkins, related to the eclipse cache, the XMLRPC should solve the need for one. I know Verterok had played around with it, but it's a heap of work, so I'm not sure when that will land.
<thumper> spiv: ping
<thumper> now, I think I know what it is doing, but pushing to bzr+ssh it is sitting at Copying signature texts 4/5 for ages, could this be doing a repack (locally)
<spiv> thumper: check the ~/.bzr.log
<spiv> thumper: as it happens, I have a branch I made yesterday that does the autopack server-side.
<thumper> spiv: nothing in there
<thumper> spiv: since the last success anyway
<spiv> thumper: use
<spiv> "bzr -Dhpss ..."
<spiv> in future, and then the .bzr.log will tell you much more.
<thumper> spiv: should I kill my push or not?
<spiv> I'm fairly sure that an autopack does get logged, though.
<thumper> hmm..
<spiv> So it's probably "normal" operation.
<spiv> I suspect it's too late to kill the push and redo the identical push.
<spiv> You could try it, though.
<thumper> ???
<thumper> it said created new branch
<thumper> when the branch was already ther
<thumper> e
<spiv> The branch probably wasn't already there.
<spiv> If you had a -Dhpss log, we could confirm this :)
<awilkins> beuno: Why would the XMLRPC solve the need to cache?
<awilkins> beuno: Does it implement a server which itself caches?
<awilkins> Bah, anyway, it's late, beddy-byes time, gnight
<beuno> awilkins, for starters, you stop paying the cost of starting bzr everytime. And, eventually, if needed, you will be able to cache, yes
<awilkins> beuno: I've already mitigated the cost of starting bzr somewhat by integrating the "service" plugin into bzr-eclipse
<awilkins> beuno: But on my target working tree of 3700 files the performance still leaves a lot to be desired.
<beuno> awilkins, right, well, I don't know any specifics, but I suppose you can cache with the XMLRPC, and avoid re-writing it within eclipse
<awilkins> The problem is mostly uncached log hits for decorators
<beuno> but Verterok is the man to talk to
<awilkins> Yes, I correspond with him.
<beuno> awilkins, anyway, just though I'd comment. I'll let you sleep already, g'night  :)
<awilkins> The performance of "log" on a single file for bzr is not what it is for SVN/CVS
<awilkins> Gnight chaps, until tomorrows first coffee.....
 * igc medical appointment - bbl
<halstead> How do I cause bzr to forget an improperly set submit branch as listed in bzr info?
<fullermd> I don't think there is a UI to 'forget'.  You can overwrite with a --remember.
<fullermd> Only way to forget is just whack it out of the branch.conf manually.
<halstead> Thanks.
<beuno> code scanner just came back from the dead!
<mwhudson> indeed
<beuno> it's lying in some cases though  :/
<mwhudson> ?
<beuno> it says a branch was modified "50 minutes ago", when it clearly hasn't
<mwhudson> it's still catching up on a pretty huge backlog
<mwhudson> oh right, it probably sets the modified time to NOW when the scanner runs
<mwhudson> we don't usually expect that to be several days after the change...
<beuno> ah, that doesn't seem like the right thing to do at all  :)
<thumper> lifeless: ping
<beuno> mwhudson, my firsts tests with genshi don't show a big improvement over kid  :(
<mwhudson> beuno: bah!
<Peng> Big improvement in what? Performance?
<beuno> mwhudson, in fact, kid takes less time
<mwhudson> beuno: and RAM?
<beuno> mwhudson, looking for a good way to test it, but looking at top, it seems about the same or more even
<mwhudson> oh well
<mwhudson> it was a nice idea
<mwhudson> beuno: can you push your code?
<beuno> I'm testing this with annotate, as it was the simplest template to test it with
<beuno> mwhudson, sure, let me clean up, and I'll push it to LP
<beuno> I just converted the annotate template, so it's all mixed up between kid and genshi
<mwhudson> jam: still here?
<mwhudson> heh
<mwhudson> that's fine
<mwhudson> i'm not sure item_keys_introduced_by really helps loggerhead
<mwhudson> we want to know which fileids changes between two mainline revisions
<beuno> mwhudson, do you have a good way to test memory usage?
<beuno> (I can google around, but might be good to be using the same tools)
<mwhudson> you can find all the fileids changed by all revisions introduced between two given revisions, but that's not really correct
<mwhudson> beuno: i don't have any sophisticated tests, no :/
<mwhudson> beuno: i do know that builtins.py is the largest file in bzr.dev :)
<beuno> mwhudson, I went for NEWS, which takes 13-16 seconds to annotate
<mwhudson> ok
<Peng> I think http://wingolog.org/archives/2007/11/27/reducing-the-footprint-of-python-applications might be good, or one other page I can't think of.
<beuno> anway, I'll take a few more minutes to convert all templates to Genshi, and push
<beuno> so you can go crazy on it  :)
<beuno> Peng, thanks, I'll take a look at that
<poolie> igc, ping?
<poolie> spiv: will leave soon
<spiv> poolie: ok
<mwhudson> mmm, graph.py is getting pretty deep
<mwhudson> gar, revision numbers are pain
<beuno> mwhudson, https://code.edge.launchpad.net/~beuno/loggerhead/loggerhead.genshi
<beuno> I'm off for dinner
<beuno> only annotate was converted
<mwhudson> beuno: enkpy your dinner
<mwhudson> jo
<beuno> I ran into a few quirks with the kid<>genshi conversion on the other templates, so I'll just leave it alone unless you find it's actually useful
<beuno> I'll be back in a couple of hours, and thanks  :)
<mwhudson> hm
<mwhudson> my turbogears isn't finding my genshi
<mwhudson> oh look https://bugs.edge.launchpad.net/ubuntu/+source/genshi/+bug/226285
<ubottu> Launchpad bug 226285 in genshi "Due to packaging changes, Genshi no longer works with TurboGears" [Unknown,Fix committed]
<jam> mwhudson: I'm back for a bit
<jam> what's up?
<jam> ah, fileids...
<jam> yeah, I can see the problem
<mwhudson> jam: it's not really any faster anyway, on launchpad
<jam> versus doing a diff?
<mwhudson> yeah
<igc> poolie: pong
<jam> hmm... a bit surprising, but you did the test
<mwhudson> jam: let me pastebin the code
<jam> mostly because the item_keys_introduced code can work on the deltas directly
<mwhudson> jam: http://pastebin.ubuntu.com/15215/
<jam> without going up to full texts
<jam> well, r2r = b.get_revision_id_to_revno_map() is going to dominate your time
<mwhudson> vs http://pastebin.ubuntu.com/15216/
<mwhudson> jam: oops
<mwhudson> i tested without that line
<mwhudson> (and indeed it's pretty slow, get_revision_id_to_revno_map takes ~5 seconds)
<mwhudson> but the fileids_from... takes ~1 second
<jam> what about the find_unique_ancestors line?
<mwhudson> eh, not long, a few tenths
<jam> yay
<jam> that's been my work for the last while
<mwhudson> not even that
<mwhudson> 0.003
<mwhudson> which is pretty neat :)
<jam> though if it is a simple graph, that isn't saying a huge amount
<jam> but I'm glad it is fast
<jam> it is a way forward
<mwhudson> running this between the last 100 mainline revs of launchpad has one revision where it takes 3.5 seconds
<mwhudson> and a couple where it's 0.7 or so
<jam> yeah, those are the ones I'd like to work on
<jam> shortcuts cause some problems
<jam> because you have to search that far on the other side
<jam> which gets you into revs with lots of ancestors, etc
<mwhudson> ah dammit, what's the package name for R again?
<mwhudson> r-base-core
<jam> :)
<jam> one of the problems with extra simple names
<jam> how do you google for R ?
<mwhudson> indeed
<pickscrape> With great difficulty :)
<mwhudson> command-not-found to the rescue here
<mwhudson> the other problem with R is that i always forget how to use it
<pickscrape> Is R used in bzr?
<mwhudson> no
<mwhudson> jam: heh, log(time-to-run g.find_unique_ancestors(last, [last_but_one])) is ~normally distributed when run over the 1000 most recent mainline revisions of launchpad
<jam> interesting, what is the mean and stddev?
<jml> KnitCorrupt raises a stack trace
<jml> It probably shouldn't?
<mwhudson> jam: the mean is about -4
<jam> negative 4?
<jml> spiv: so it's like this.
<jml> spiv: I pushed up a branch into a shared repo, someone tried to branch it standalone and then they got a massive KnitCorrupt traceback
<mwhudson> jam: the mean of the non-log data is 0.03
<jml> spiv: I'm following the instructions on the traceback now (bzr check, bzr reconcile)
<mwhudson> though this is for 6000 revs now,
<jml> spiv: but it seems a bit buggy that Bazaar should show a traceback here.
<spiv> jml: Hmm.  So you think it should just give the KnitCorrupt error without a traceback?
<jml> spiv: yes.
<mwhudson> 0.05 for the first 1000
<spiv> Well, that's easy to fix (it's just a flag on the KnitCorrupt class).
<mwhudson> 3.5 for the worst case though
<spiv> jml: I'll talk it over with poolie when he gets here.
<spiv> jml: out of interest, what's the full traceback in this case?
<jml> spiv: cool. thanks.
<spiv> I'm a bit hesistant about suppressing the traceback there, because KnitCorrupt almost always so far is a bzr bug.
<spiv> And showing the traceback makes it more likely that we get the traceback in the bug report.
<mwhudson> jam: the 3.5 second case is for a moderately but not ridiculously complicated merge
<spiv> But possibly we should just be making sure we have enough context in the text of the KnitCorrupt message rather than relying on the traceback.
<mwhudson> jam: want more details?
<jam> mwhudson: there are ones in bzr.dev, too
<jam> generally the problem is that it is long enough to cause the *other* side of the search to wander a lot
<mwhudson> jam: heh, the worst case in bzr.dev seems to be "pack repositories!"
<mwhudson> jam: 'number of revisions introduced' seems only very loosly correlated with running time
<jml> ok.
<jml> so, now when I run "reconcile" on the repo that was causing the KnitCorrupt error, I also get a KnitCorrupt error
<jml> Can I do anything about this?
<jml> (it's a little worrying)
<Peng> Bwahaha.
<Peng> I just finally counted how many requests it took bzr.dev to branch that one branch. 765!
<poolie> Peng: over http?
<poolie> is this a pack branch? if so that's a bit bad
<poolie> igc, ping?
<Peng> poolie: No, knits.
<igc> hi poolie
<poolie> Peng: you should really upgrade it...
<Peng> poolie: I was checking how much it had improved since 1.3. About -600%, I think?
<poolie> knits have?
<Peng> Pulling with no changes has.
<Peng> 1.3 accesses the repo, but bzr.dev doesn't, I think.
<poolie> ok
<poolie> that's kind of interesting, but we really want people to move from that format
<Peng> Yeah.
<poolie> in fact in this release we should add a warning about it
<Peng> Also, bzr+http is quite good.
<poolie> igc, could you call me at andrew's house when convenient?
<igc> sure
<igc> how's now poolie?
<poolie> now would be great
<Peng> I haven't upgraded because upstream still hasn't.
<Peng> re bug 234748, so is bzr.dev eating old revisions?
<ubottu> Launchpad bug 234748 in bzr "Knit inventory corrupt in bzr.dev with bzr.dev r3452 (KnitCorrupt)" [High,Confirmed] https://launchpad.net/bugs/234748
<uniscript> given a file is it possible to print out the weave?
<spiv> Peng: yes, bzr:// and friends should make pulling knits approximately as good as pulling packs.
<spiv> Peng: bzr.dev isn't damaging old revisions as far as I know.  i.e. I don't think this is a dataloss issue.
<spiv> Peng: My guess is it's just being a little more pedantic with the metadata, and then not gracefully coping when it sees this inconsistency.
 * igc pick up kids
<poolie> uniscript: can you explain more what you mean?
<uniscript> I'm trying to debug a merge problem so want to look at the weaves
<uniscript> so given a file test.txt is there a command that prints the weave for test.txt in my branch?
<poolie> uniscript:  i think 'bzr weave-plan-merge' will do it
<poolie> uniscript: note that we don't actually store texts in weaves anymore for performance...
<spiv> AIUI the weave itself is not really relevant, just the shape of the graph.
<uniscript> the bzr weave-* take a weave file
<poolie> well, that will show you the line-by-line annotations of the merge
<poolie> oh i see
<poolie> are you giving any options to the merge command to choose an algorithm?
<uniscript> OK. well conceptually to dumb users like me you are :)
<uniscript> --weave
<spiv> uniscript: --lca is almost always better or at least as good as --weave, btw
<uniscript> for criss-cross merging?
<spiv> (possibly s/almost// in current versions)
<spiv> Yep.
<uniscript> OK thanks, I'll try that
<poolie> uniscript: it would be nice to expose some debugging info to help in cases like this
<poolie> bye...
<Peng> spiv: Ok. Not being a data loss issue is good.
<poolie> Peng: yeah definitely not, a bug in check i think
<Peng> poolie: Good. :)
<Peng> Wasn't check's performance improved a while ago?
<beuno> mwhudson, did you get a chance to verify Genshi's performance?   I'm not sure if I should try and see if we can tweak that, or go down a different path...
<mwhudson> beuno: no, sorry :/
<beuno> mwhudson, no worries. I'm going to look into it a bit further and make sure we're not improving in any way
<mwhudson> beuno: cool
<beuno> maybe the bottleneck is in turbogears?
<mwhudson> i'm about to stop work for today, so talk to you tomorrow!
<beuno> right, almost 3am, I'm getting used to that  :)
<beuno> thanks, and cya tomorrow
<mwhudson> night
<poolie> 234378 should be fixed now...
<poolie> jml, re that bug, you said you could reproduce it just branching out of your repository?
<poolie> i can't, even with the unfixed version
<jml> poolie: what URL are you using?
<poolie> i was branching my bzr trunk to /tmp/
<jml> poolie: oh. maybe try branching from my repo?
<poolie> jml, where is that?
<jml> poolie: devpad.
<spiv> jml: which branch?  Were you branching over bzr+ssh?
<spiv> jml: I can't reproduce by branching locally on devpad from your repo to /tmp
<spiv> jml: I tried both your bzr.dev branch and your most recently touched branch.
<jml> spiv: bzr+ssh.
<jml> spiv: stacking-policy
<spiv> "most recently touched" :)
<jml> spiv: oh. well.
<jml> spiv: which version of bzr were you using?
<jml> spiv: and was it into a standalone branch?
<spiv> jml: I get a different KnitCorrupt over bzr+ssh...
<spiv> Which tells you to run check and/or reconcile.
<jml> spiv: right.
<jml> spiv: then if you run check and/or reconcile...
<spiv> jml: ok, I didn't realise it was two different KnitCorrupts.
<jml> spiv: mea culpa
<poolie> it is a kind of vague error that sounds like it's specific
<poolie> um
<poolie> i should stop complaining and just send a patch to change it
 * igc dinner
<siretart> would someone please care to update bzr-svn in the PPA for hardy?
<gambler> is there a document anywhere explaining how to use bazaar with git?
<lifeless> dunno, but bzr-fastimport is a good conversion tool
 * gour recommends tailort
<gour> *tailor
<gambler> i must be mistaken because i heard someone say that there was some capability for bazaar to speak directly to git repos
<gambler> eg. use them natively
<gour> gambler: maybe https://launchpad.net/bzr-git
<Jc2k> it looks somewhat dead?
<Odd_Bloke> bzr-git is still in its formative stages, I think, so isn't really a priority for whoever was working on it (jam, I think).
<awilkins> I think we'll all eventually end up with a common VCS backend API, and a small selection of cliens.
<awilkins> And different implementations of the backend depending on requiremenbts
<awilkins> And the ability to type may atrpohy as we use our mind control interfaces
 * awilkins goes to fetch coffee to improve his synapse lag
<gambler> instead of a wetwire, how about an electronic vagina that I can control with my penis?
 * vila wonders how this relate to git, but English is not his native language...
<gambler> vila: #bzr
<gambler> no pun intended
<vila> gambler: the wetwire bits  ?
<vila> gambler: sry, then :)
<gambler> lol gold
<gour> one question...i defined alias: checkout=checkout --lightweight and bzr help checkout says: 'bzr checkout' is an alias for 'bzr checkout --lightweight'. otoh, 'co' is alias for 'checkout', so i'd expect that invoking: bzr co would does: bzr checkout --lightweight, but it doesn't :-/
<gour> is it a bug or a feature?
<james_w> gour: not sure, I have seen that behaviour before, but I used it as a feature.
<uniscript> are there any plans to 'fix' --lca to mark delete + change as a conflict?
<gour> james_w: hmm, i'd expect that user's alias is last in effect, i.e. 'co' should expand to 'checkout' and then *my* checkout should expand to defined alias
 * gour will submit a bug report
<gour> using mail-client = emacsclient does not invoke Gnus. anyone using Gnus with 'bzr send' ?
<james_w> uniscript: is there a bug report filed for that? I'm not familiar with the problem you mention.
 * gour would like to use gpg-sign when sending bundles around
<uniscript> see the developer notes on the lca merge algorithm where it states that currently lca silently does delete+change->change with no conflict report as does --weave
<uniscript> and that this needs to be fixed to conform to --merge3
<uniscript> and I would agree with that :)
<james_w> ah, I hadn't seen that.
<uniscript> so I guess there are no plans then?
<gour> hmm, problems with 'bzr send' and emacs...invoking bzr send gives http://rafb.net/p/ZXRhFV94.html
<gour> any hint?
<james_w> uniscript: no idea I'm afraid
<uniscript> OK I'll raise a bug
<james_w> gour: that looks like an emacs problem, is it?
<james_w> or an emacs error rather, not necessarily its fault
<gour> james_w: well, emacs is invoked and i can fill out the To/From...but i'd like Gnus to be invoked and wonder about the error(s)
<james_w> I'm not familiar with emacs, sorry.
<gour> ok, i'm asking in #emacs
<lamont> given a .git repo with several branches, is there a trivial bzr import process for that?
<lamont> of course, in my fantasy land, I'd wind up with one bzr directory in which I could switch between all the diff views.
<lamont> and would be able to bzr push changes back to the git repo
<lamont> and fetch and/or merge from said git repo
<Jc2k> not yet
<Jc2k> there is one way git -> bzr import
<Jc2k> i don't know the state of bzr-git... but that will allow what you speak of one day..
<gour> heh, solved my 'bzr send' & Gnus problem...the solution was to set mail-user-agent in emacs. fortunately, i also got nice reply on the ml. nice to have such info in the docs
<gour> someone was today explaining me how he likes that with git he can create several branches in one working dir and switch between them by checkout-ing them. i replied that bzr can do almost the same buy using e.g. treeless shared repo and doing lightweight checkout & switch in some working repo
<gour> his remark was that he does not like one directory per branch, but i do not see logic what would be advantage of sticking many branches in one folder except more hassle when one wants to access them remotely. anyone can shed some light if there is some?
<asabil> gour: the 1 folder per branch works better with IDE and various external tools
<asabil> on the other hand the git model work better when you want to checkout all the branches of a repository at the same time
<LarstiQ> asabil: well, having 1 tree works better when building is expensive, say, C.
<asabil> I tend to prefer the bzr model myself
<LarstiQ> but branches don't suffer from the same problem
<asabil> hmm, what do you mean ?
<asabil> which problem ?
<gour> asabil: is it easy with git to fetch just one branch?
<LarstiQ> asabil: if you have a project where a full build takes in the tens of minutes, you really want to reuse your intermediate objects
<asabil> yeah, but that's a build system issue
<asabil> not a revision control issue
<LarstiQ> asabil: also, things like Eclipes don't deal too well with suddenly having to look somewhere else for the code.
<LarstiQ> asabil: it is an important use case for `bzr switch`
<demod> hi
<LarstiQ> asabil: it's git's native way of working
<asabil> LarstiQ: people can still use out of tree build
 * gour likes bzr switch mechanism
<asabil> I never used bzr switch myself
<asabil> but I do see your point
<gour> asabil: it's handy being in one working dir and just switching between the branches you're working on
<fullermd> Having the repo be the functional unit makes it much easier to do multi-branch syncs.
<fullermd> Can only fake up parts of that capability with bzr.
<gour> fullermd: with shared repos?
<asabil> gour: cd ../foo-branch works
<fullermd> Shared repos don't change anything.
<gour> asabil: i mean using --ligthweight checkouts and --no-trees repo, then you can stay in one folder
<asabil> gour: personally I prefer seeing 1 branch == 1 folder
<gour> i do not see big advantage of git's model, especially considering its complexity over bzr
<asabil> I used to like the git model (when using monotone), it is just a matter of habit
<gour> asabil: me too, but in shared repo without working-trees
<gour> asabil: how is monotone these days? i looked at it in the past, but didn't like database dep
<fullermd> I sure wouldn't want to be stuck with one tree for all my branches; it's almost necessary to see multiple branches side by side.
<asabil> gour: didn't use it for 2 years now
<fullermd> But I wouldn't dream of pretending it doesn't come with drawbacks.
<gour> :-)
<asabil> fullermd: I agree
<fullermd> I use it very occasionally.  It's always fighting an impedance mismatch.
<fullermd> Ex: How, using bzr, do I get a local copy of all your branches, keep them up to date, and automatically get new branches when you create them?
<fullermd> Oh, that's right; I DON'T!
<asabil> the only drawback about 1 branch/folder that I see, is the lack of ability to pull/merge multiple branches
<asabil> (multi-pull sort of solves it, but ...)
<fullermd> Part of that is "nobody's written it", but writing it is some nontrivial amount of work with dir-per-branch architecture.  With the repo being the primary functional unit, it comes for free.
<gour> asabil: multi-pull is not quite interesting here
<awilkins> jelmer: So, this thing where the revision-id changes when you change branching-schemes.. is it not possible to use a different ID generator that is consistent regardless of branching scheme?
<fullermd> multi-pull saves doing a `for i in *; do ....` construct.  I use it mostly for ~/.bazaar/plugins/.  It's handy.
<awilkins> (I realise this would break all existing code, blech)
<jelmer> awilkins: this is bug 130372
<ubottu> Launchpad bug 130372 in bzr-svn "Abandon branching schemes" [Medium,Triaged] https://launchpad.net/bugs/130372
<awilkins> Groovy ; what would you use instead ; SHA of the changeset? Something like that?
<awilkins> Incidentally, that patch I sent you was applied against the current tip of the 0.4 branch, I'm not so sure it's fixed (maybe it's another instance of the same thing?)
<awilkins> Unless you've just not pushed for a week :-)
<nnutter> Good morning. I have a question that I wasn't able to clearly find an answer for. I'm just getting started using Bazaar (all VCS for that matter) and I'm confused about how to merge two branches together on different machines.
 * awilkins notices a new push
<jelmer> awilkins: what bzr-svn branch are you using?
<awilkins> nnutter: start in the branch you are merging TO, and do a "bzr merge <mrege from>"
<awilkins> jelmer: 0,4
<jelmer> awilkins, we won't be making the branching scheme part of the revid anymore
<awilkins> I've just noticed you pushed this morning sometime
<jelmer> I didn't do any bzr-svn stuff this morning
<awilkins> jelmer: There was a push 7 hours ago according to LP
 * awilkins refreshes cache
<jelmer> awilkins: are you using the launchpad mirror of 0.4 or 0.4 directly?
<nnutter> awilkins: Can it be done the other way. I'd like to start in the branch you are merging from and send the changes to another person. BTW the workflow I'm following is what the Bazaar docs called "Decentralized with Shared Mainline".
<jelmer> 7 hours ago I was sound asleep :-)
<awilkins> jelmer: code.launhpad.net - this page claims 7 hours 50, the actual revision is from the 23rd
<awilkins> https://code.launchpad.net/bzr-svn/
<awilkins> nnutter: If you want to send the changes to another, make a bundle using either bzr send or bzr bundle - they then treat that bundle as the  "from" branch
<jelmer> awilkins, not sure what's going on then
<james_w> nnutter: you have to be in the branch the you are merging to. If you don't control that branch then you can use "bzr send" to send the change as a text file.
<jelmer> awilkins, the 0.4 branch isn't hosted on launchpad so maybe the launchpad mirrorring is just slow
<james_w> nnutter: if it is the shared mainline you are trying to merge to then "bzr checkout" the remote branch to your local machine, and then run "bzr merge" in that.
<awilkins> jelmer: Says it last mirrored 1 hour ago ; it's usually something like that. But there is some misrepresentation about timestamps going on there, or it's cacheing a generated page too lon
<awilkins> Or my obnoxious ISP are
<awilkins> Nope, same from a different proxy
<nnutter> james_w: ok, thank you. I'll look at that.
<james_w> nnutter: if you haven't already I would recommend setting up a "shared repository" on your local machine before the "bzr checkout" if that is the way you are going, we can help you set that up if you like.
<nnutter> james_w: I'd appreciate that, I think I may have.
<nnutter> james_w: I made a dir in /var called repos, then made a project directory, e.g. /var/repos/him. I did bzr init in that directory and then added all the source files (bzr add).
<nnutter> Now it seems to work if I do bzr checkout bzr+ssh://whatever/project.
<nnutter> Is a "shared repository" more than that?
<james_w> yep that will work.
<asabil> awilkins: lp is sort of broken these days
<asabil> awilkins: branch scanning has been very very slow
<awilkins> asabil: That's software for you. I bet it's something to do with not using shared repos.
<james_w> a "shared repository" allows several branches to share revision data, and as your mainline and the feature branch will have mostly the same revision data it will save you having to download so much data when you pull.
<asabil> hmm ?
<asabil> awilkins: what do you mean ?
<nnutter> james_w: OK, cool. :-) New question. With the shared mainline method. Should I be using co, update, and ci (similar to how I think SVN works?). You mentioned merge but I got a message about location not being specified remembered.
<awilkins> asabil: If you branch on LP, you take a full copy of the branch - there are no shared repos on LP (except perhaps official ones)
<asabil> awilkins: on LP all branches within a project are part of a shared repo iirc
<asabil> so 1 project == 1 shared repo iirc
<asabil> awilkins: and how is that related to what I was telling you ?
<awilkins> asabil: Slow? Lots of branches to scan? Without repo sharing?
<james_w> nnutter: so if you "bzr init-repo repo; cd a; bzr init mainline" mainline will store it's revision data in "repo/.bzr" instead of "repo/mainline/.bzr", now if you "bzr branch mainline feature", feature will also store it's data there, and so won't need to copy anything
<james_w> nnutter: you need to specify a location to the merge command the first time, it will remember it after that.
<asabil> awilkins: nevermind
<nnutter> james_w: cd a?
<james_w> nnutter: sorry, typo, "cd repo"
<nnutter> ok
<james_w> so it doesn't sound like your branch at "/var/repos/him" uses one. You can change this by doing "bzr init-repo /var/repos; bzr branch him temp; rm -rf him; mv temp him", but make sure there are no uncommitted changes in "him" first.
<nnutter> so if I do that I could have repo/main repo/user1 repo/user2 where repo/userX was a branch of main. The users would co repo thereby downloading each user's personal branch as well as main. And then each user could commit to their own branch and periodically merge back to main?
<awilkins> nnutter: They'd make their own local repo, and branch or co main into it, then branch main from there to their feature branch
<nnutter> I think I'm getting a bit confused. branch and co are not synonymous right? Could you clarify the difference?
<awilkins> nnutter: "co" creates a "bound" branch ; this acts much like an SVN "working copy" only it has a full revision history not just a base copy of the last update from HEAD
<awilkins> nnutter: "branch"  makes an unbound branch ; identical, but commits do NOT automatically get pushed back to the parent branch
<gour> nnutter: branch creates a new copy of branch
<awilkins> "co --lightweight" is even more like an SVN WC and only has revisions in the master branch
<nnutter> Maybe I can/should explain my project and you guys can tell me if I'm totally off then?
<nnutter> I thought I had it mostly figured out, but now I'm confused about how to do what I want.
<nnutter> I'm trying to setup a repo for a computer model. This model has several components to it, some that handle basic physics, some that handle chemical processes, and some that trace the movement of chemicals. Each component is a different person's specialization.
<nnutter> What I wanted to do was have a main copy (I think would be called a trunk) which has the "stable" version of the code.
<nnutter> And for people to get a copy of that, make changes to the component they specialize in, while being able to commit revisions locally, and at some point when they are satisfied merge those changes back into the main source tree.
<gour> nnutter: see http://bazaar-vcs.org/SharedRepositoryLayouts?highlight=%28layout%29
<gour> nnutter: as well as http://bazaar-vcs.org/SharedRepositoryTutorial?highlight=%28layout%29
<nnutter> gour: thank you, looking.
<gour> nnutter: so, every user have write-access to the central repo?
<nnutter> yeah
<gour> ok, then it's just question how you want to layout central-repo...see the above urls
<nnutter> Yeah, looks like the first method of Simple Developer Naming is what I want.
<gour> nnutter: you probably can use tree-less shared repo on the 'central server'
<nnutter> There will only be 3-4 developers.
<nnutter> ok, looking...
<nnutter> Ah!
<nnutter> "he word shared in shared repository refers to branches sharing a repository for revision storage, not to users sharing the same branch for publishing revisions. They can be used used for that purpose, however. "
<nnutter> That clarifies a lot :-p
<gour> nnutter: whatever you choose, enjoy with bzr ;)
<nnutter> which is what james_w: met by "shared repository" earlier. I was thinking shared as in more than one user, but he was thinking of it as described there
<gour> heh, i also had some glitches in understanding the lingo and submitted bug report to write some part of the docs more clearly
<nevans> I'm having worse memory problems than ever before with bzr-svn... :(
<jelmer> hi nekohayo
<jelmer> *nevans
<nevans> new install of hardy on a new laptop, upgraded to bzr 1.5 and bzr-svn 0.4.10
<gour> nnutter: right. branches can share repo and therefore you can save some space
<jelmer> nevans, the memory leaks are in the subversion python bindings
<awilkins> jelmer: Did you ever get those Pyrex bindings working?
<nevans> and when I try to do anything with the svn repo, it locks up at determining changes     0/41590
<gour> jelmer: svn-1.5 fixes it?
<nevans> jelmer: yeah... but I was at least able to checkout this repository before...
<nevans> now it just grows to fill up my 3GB of memory in under a minute
<nevans> alse before the memory would grow as it moved through the revisions, so I could terminate and try again (starting at a higher revision), and it would eventually complete
<nevans> now it sticks at 0.  :(
<jelmer> awilkins: Haven't worked on them in a while
<nevans> also... I've got another computer which is currently working
<awilkins> jelmer: They were frustrating but promising...
<nevans> I'm going to try copying over the cache from that other computer... and if that doesn't work, then I'll downgrade to the versions used on that other computer
<nevans> jelmer: sorry to bring up the same-old bug again... but before I could always work around it.
<nnutter> OK, so if I'm doing this Simple Developer Naming method I'd have him/trunk and him/nnutter/feature1, for example.
<jelmer> nevans: afaik nothing has changed that could've affected the memory usage
<nnutter> Would him/nnutter be a branch, i.e. would I need to bzr init him/nnutter or just him/nnutter/feature1?
<nevans> interesting... then I wonder if something in the repository has changed which would trigger the memory bug worse than before
<nnutter> Or wait.
<gour> nnutter: "Another possibly layout is to give each developer a directory, and then have a single sub-directory for branches. "
<gour> nnutter: do you want option a) or b) ?
<nnutter> a
<nnutter> what you just quoted.
<nnutter> err
<nnutter> yeah
<nnutter> When I wear out my welcome just tell me :-p
<gour> nnutter: ok, then create 'project' shared repo
<nnutter> k
<gour> nnutter: with 'trunk' branch
<gour> nnutter: and joe/foo jim/bar ... branches
<nevans> jelmer: FYI: copying over the cache from another computer fixed it.
<gour> nnutter: does it make sense?
<nnutter> I think so. Let me see if I can translate it...
<nnutter> bzr init-repo project; bzr init project/trunk; cd project/trunk; bzr add; bzr ci -m 'Initial.'
<nnutter> bzr branch project/trunk project/nnutter/feature1
<gour> nnutter: yep. take care if you want --no-trees option for shared repo and about repo format
<nnutter> ok
<nnutter> So that gets the shared repo setup on the "mainline server". Now User2 wants to get a copy and start his own branch, etc.
<nnutter> So User2 does 'bzr branch prot://address/path/project'?
<jelmer> nevans: so this would just be the same problem as originally
<awilkins> User2> mkdir repo ; cd repo ; bzr init-repo . ; bzr branch <main_branch_uri> project.trunk
<awilkins> User2> bzr branch project.trunk project.mine
<awilkins> User2> # hacks
<gour> nnutter: branches are the 'deepest' folders in 'project' hierarchy
<jelmer> nevans, except that the caching format has changed recently
<nevans> jelmer: I suppose so.  But it feels a lot more severe than the previous problem that I've had... since it completely hangs and sucks up memory, rather than slowly leaking as it moves through revisions
<nnutter> gour: ok, gotcha there
<jelmer> nevans: The generating of the cache takes the most memory
<jelmer> nevans, and since the format had changed it had to regenerate that cache
<nnutter> awilkins: then User2> bzr commit -m 'User2 hacked file A.'
<nevans> it changed between 0.4.9 and 0.4.10?
<nnutter> awilkins: then User2> # Hacks
<jelmer> nevans: yeah
<nnutter> awilkins: then User2> bzr commit -m 'User2 hacked file B.'
<gour> awilkins: why not: bzr init-repo project; cd project
<nnutter> awilkins: then User2> bzr push?
<awilkins> nnutter: bzr push <my_new_branch_uri_on_server>
<nevans> so when I copied over the cache (which was built/used by version 0.4.9 and prior), it was still able to use that cache... did it transform it to the new style cache?
<awilkins> nnutter: Although they don't *have* to have a branch on the server
<nnutter> they could push it to <trunk_uri_in_server> or something instead right?
<awilkins> gour: *shrug* that's just how I tend to do it ; I also tend to share repos between multiple projects
<awilkins> nnutter: Yes, they can push to <trunk> but that disrupt others work
<nnutter> right
<nnutter> ok, getting really close to understanding whole process :-)
<nnutter> so last step
<gour> awilkins: i mean, bzr init-repo project saves one step, i.e. it creates repo & dir in one step
<awilkins> nnutter: What is best is to pull changes from server:trunk to your local branch of trunk, then merge your changes into that, and push when you've resolved any conflicts (and tested the crap out of things, natch)
<nnutter> User2 now wants to merge his branch into trunk, which you just explained :-p
<awilkins> gour: True, but I don't do that very often so I suppose it never occurred to me how much time I was wasting :-P
<gour> awilkins: ok. np ;)
<nnutter> so to merge to trunk...
<awilkins> cd ../project.trunk
<awilkins> bzr merge ../project.mine
<awilkins> until (branch.has_no_conflicts) { resolve conflicts }
<gour> nnutter: User2 wants to have his local branch 'up to date' and then push to the server
<awilkins> bzr commit -m "Merged my astounding new feature"
<awilkins> bzr push
<gour> (having, ass awilkins wrote, all conflicts resolved)
<gour> s/ass/as
<nnutter> OK, excellent.
<gour> awilkins: excuse me for the typo :-(
<nnutter> Oh, is there any difference between bzr+ssh:// and sftp://?
<gour> nnutter: iirc, bzr+ssh requires bzr on the server-side
<nnutter> oh ok
 * awilkins goes to catch train
<LeoNerd> sftp just uses sftp. bzr+ssh ssh's into the target machine and runs a bzr command on the far end
<LeoNerd> sftp will work with any sftp server. bzr+ssh needs bzr installed there
<LeoNerd> bzr+ssh can be more efficient in network transfer, because the bzr command on the far end can precalculate things
<gour> with LP one uses bzr+ssh?
<nnutter> ty LeoNerd
<pickscrape> Anyone here use the Colored Diffs extension for Thunderbird?
<jml> abentley: do you know why bzrlib/transport/sftp.py url escapes and unescapes paths?
<abentley> jml: That aspect of the API is rather underspecified.
<jml> abentley: I was afraid of that.
<abentley> It's never been crystal-clear whether it's using url segments or path segments.
<abentley> jml: It does seem to be pretty consistent in treating its input and output as url segments.
<jml> abentley: I think I see now. The interface takes url segments, but the internal sftp stuff doesn't, so the sftp transport escapes and unescapes.
<abentley> Right.  The sftp protocol itself is all about path segments, so the transport is our translation point.
<Pilky> Just out of interest, has anyone looked into why bzr ignored is so slow? I don't know much about the internals of bzr but I would've thought that being slow to compute which files are ignored would slow quite a few other operations down a fair bit
<fullermd> Well, what else cares what files are ignored?  add, status...   that may be it.
<Pilky> yeah, but they aren't exactly rarely used operations
<barretj> hello
<barretj> the revno command tells me what revision i'm at, is there a way to show that i'm at a revision plus some changes?
<barretj> i know i can use the status command to see what the changes are, but i just want to see that there are changes
<LeoNerd> bzr st >/dev/null   and use the exit code?
<gour> lol
<barretj> umm, i dont think that works
<barretj> i'm getting a 0 status code
<barretj> echo $?
<barretj> and i have changes
<LeoNerd> Ah.. boo
<barretj> unless 0 means there are changes
<fullermd> bzr version-info --customer --template="{clean}"
<fullermd> Er, --custom
<barretj> fullermd: thanks!
<awmcclain> Any ideas on status of https://bugs.launchpad.net/bzr/+bug/173002?
<ubottu> Launchpad bug 173002 in bzr "Branching from hpss doesn't preserve non-repository formats" [High,Confirmed]
<awmcclain> There's no way to convert my existing repository out of RichRootPack, is there?
<jelmer> awmcclain, the idea at some point was to make richrootpack the default for 1.6
<awmcclain> jelmer: So, at some point, if I just wait, the problem will fix itself? :)
<awmcclain> (I'm just getting tired of having to a) create a repository for my branch or b) download a revision via sftp and then switching to bzr+ssh
<jelmer> awmcclain: there's no way of downgrading from rich-root-pack root pack-0.92
<jelmer> what you can do is replay all of the changes in a pack-0.92 branch but that will obviously change the revision ids
<awmcclain> jelmer: Okee doke. But the idea is that the default branch-type in 1.6 will be rich-root-pack, right?
<jelmer> awmcclain: that's the idea, yes
<jelmer> abentley: is that going to make 1.6 ?
<abentley> jelmer: no
<gour> is there any other 'development' format cooking under the hood promising even better performance?
<jelmer> abentley, :-( any chance for 1.7 ?
<abentley> jelmer: quite likely.
<gour> after 1.9 there will be 1.10 ?
<awmcclain> :(
<jelmer> abentley, thanks
<awmcclain> Is there any way to squeeze in a fix for 173002 then?
<jelmer> ubottu, bug 173002
<ubottu> Launchpad bug 173002 in bzr "Branching from hpss doesn't preserve non-repository formats" [High,Confirmed] https://launchpad.net/bugs/173002
<awmcclain> basically, you can't branch existing repository that are in rich-root-pack over bzr+ssh
<awmcclain> you have to do one of the workarounds i mentioned before
<awmcclain> *repositories
<jelmer> awmcclain, I haven't ever had problems with that
<jelmer> maybe it's just checkouts that don't work
<jelmer> branching works fine afaik
<awmcclain> nope
<awmcclain> oh
<awmcclain> ok, just ignore me then.
<awmcclain> :)
<awmcclain> rooting out cobwebs in my brain
<jelmer> so you should be able to "bzr branch ..." and then "bzr bind"
<awmcclain> ... of course.
 * awmcclain smacks himself in the head
<awmcclain> Ok, lastly, any ETA on https://bugs.launchpad.net/bzr/+bug/211967?
<ubottu> Launchpad bug 211967 in bzr "bzr smart server should support hooks" [Medium,Confirmed]
<gour> there are 1395 bugs in LP. any statistics of the general trend?
<fullermd> 1395 is a good number.
<fullermd> Its prime factors are 3, 3, 5, and 31.  Multiple the 3's and you get 9, so you're left with 9531, which is the same digits swapped around.
<fullermd> Obviously, we can never open or close another bug, or we'll decrease our perfection.
<gour> :-)
<mwhudson_> beuno: hello
<beuno> mwhudson, mornin'
<mwhudson> beuno: i just remembered that i converted all the loggerhead templates to zpt a good while ago
<mwhudson> i guess that would be something else to test :)
<beuno> mwhudson, there is a branch for that somewhere?
<mwhudson> https://code.edge.launchpad.net/~mwhudson/loggerhead/zpt-templating
<mwhudson> it is a bit out of date
<beuno> mwhudson, ok, cool, I'll update it and test it
<beuno> I've been thinking about doing tests with Genshi, but avoiding turbogears
<mwhudson> that would be cool
<beuno> just so we can discard that turbogears is the real problem
<beuno> ok, only 4 conflicts merging trunk into that branch, not as bad as I expected
<mwhudson> yeah, but the templates will be a bit out of date
<beuno> they seem good enough to test performance, and if we get promising results, I'll work on updating them
<mwhudson> oh cool
<mwhudson> beuno: are you on hardy?
<beuno> mwhudson, yeap
<mwhudson> beuno: what did you do about https://bugs.edge.launchpad.net/ubuntu/+source/genshi/+bug/226285 ?
<ubottu> Launchpad bug 226285 in genshi "Due to packaging changes, Genshi no longer works with TurboGears" [Unknown,Fix committed]
<mwhudson> breakfast, brb
<beuno> mwhudson, "easy_install Genshi" did the trick
<mwhudson> beuno: hmm, i'm not sure i want to disrespect my packaging system that much :)
 * mwhudson goes to look for a newer debian deb
<beuno> mwhudson, well, it seems you haven't run loggerhead's setup.py then  :p
<mwhudson> only for sdist
<mwhudson> sweet, i managed to build a fixed deb for genshi
<beuno> sounds like something that should go into your PPA  :)
<mwhudson> yeah, if i had a ppa
<mwhudson> (i haven't signed to CoC yet for one thing...)
<beuno> ah, so you're expecting to mis-conduct?  :)
<mwhudson> no, just lazy
<beuno> jelmer, btw, the bzr-gtk BB has been down for a good 24 hours at least
<mwhudson> hmm, zpt-templating does seem to perform better
<beuno> significantly so?
<poolie> hello
<beuno> hey poolie
<poolie> beuno: hey it looks like the loggerhead theming is going well
<beuno> poolie, yeap, I managed to speed it up a bit. All mockups are finished, just need feedback from everyone, and I'm ready to start applying it to the template
<mwhudson> beuno: yeah, about twice as fast about half as much ram
#bzr 2008-05-29
<beuno> now, if we could only get it to stop crashing...
<beuno> mwhudson, wow, pretty big
<beuno> are you testing on diff?
<mwhudson> beuno: yeah, definitely a surprise
<igc> morning
<mwhudson> beuno: yes
<beuno> mwhudson, interesting...  I wonder if that will suffice to make it stop crashing
<beuno> mornin' igc
<igc> morning beuno!
<beuno> I like the templating layout for zpt much better, seems cleaner
<mwhudson> it's a lot more verbose
<beuno> mwhudson, did you update the branch, or as-is?
<mwhudson> so after rendering a 30002 line diff richly with kid loggerhead is using 711m virt, 493m resident
<mwhudson> after rendering the same diff with zpt-templating, it's 375m, 152m
<mwhudson> beuno: i merged trunk into it and fixed the text conflicts
<mwhudson> (oh and 50 s vs 16s)
<beuno> heh, very interesting
<mwhudson> yes
<beuno> I've been thinking how much we could reduce our memory usage if, instead of looping into a variable all the lines, we somehow start building the HTML as we loop
<lifeless> moin
<beuno> I think it may worth testing, should scale better
<beuno> hey lifeless
<mwhudson> mmf, two concurrent requests to that diff page still chew a lot of ram
<mwhudson> well, about twice as much, no real surprise there
<beuno> mwhudson, I'm going away for a few hours, but I'll probably work for a few when I come back. Anything specific you want me to look in to?
<mwhudson> beuno: not that springs to mind immediately
<mwhudson> beuno: i'll send you email if anything comes up
<beuno> mwhudson, cool. If not, I'll play around with some of the ideas I have and see if we can get a significant memory usage reduction
<mwhudson> cool
<beuno> later!
<poolie> lifeless: hi!
<poolie> lifeless: feeling any better?
<lifeless> the fever seems broken
<lifeless> so yes, but not 'well'
<lifeless> spiv: ping
<spiv> lifeless: pong
<lifeless> I'm just pushing up a new snapshot of versioned_files
<lifeless> poolie said you were interested in network edition of same
<spiv> Yeah, definitely.  I want to use the new streaming stuff.
<lifeless> there are two layers that need doing
<lifeless> a 'fetch' level layer, which replaces repository.get_data_stream
<spiv> I have some cheap hacks that implement a couple of pack specific RPCs (to e.g. autopack) that get significant improvements, but the long term solution is to use your stuff.
<lifeless> and a text/inventory/revision/signature level layer, for use by e.g. diff
<lifeless> there are some open questions
<lifeless> tree building for instance commonly needs all the texts for one revision
<lifeless> so it could use the repository level api to minimise the request size
<lifeless> OTOH when we have even a couple of local commits and the rest is on the network we won't need *all* the texts for one revision to cross the wire, but sending a whole inventory of .oO over the wire to ask for its tree probably outweighs the retransmission cost
<lifeless> and that doesn't even address the conceptual layering that would be needed to do that
<lifeless> Using saved location: sftp://rookery/~/public_html/baz2.0/versioned_files
<lifeless> Now on revision 3375.
<lifeless> 'punt'
<lifeless> :)
<spiv> Thanks!
<lifeless> I'm going to try to work today
<lifeless> there is much to do
<lifeless> note that that branch is currently in the middle of eliminating get_inventory_weave
<lifeless> specifically bundles are bust while I adapt the multiparent code
<spiv> Ok
<lifeless> hmm, how best to collaborate here; I think if you have a look at the code
<lifeless> and get a feel for it
<lifeless> then we can chat on IRC?
<spiv> I think so.  I'm currently focusing on getting my various push acceleration work so far to the list.  Digging into using your branch would be next on the list, though.
<lifeless> cool
<lifeless> also for the network apis we may likely want to use the single key space aaron advocates, because for the smart server there is no arbitrary split between indices (in some regards ideally no index at all)
<spiv> That makes sense to me.
<lifeless> poolie: talking is still unpleasant; if you want to catch up IRC would be massively preferable
<jelmer> Jc2k: ping
<jelmer> beuno, sorry about that, the server I'm running it on appears to've been assigned a new IP again
<lifeless> poolie: ping in fact
<igc> abentley: can you check BB please? It appears to be down again
<abentley> igc: Should be back in a minute.
<igc> thanks
<poolie> lifeless: sorry you were minimized :)
<Pilky> Who is it that updates the downloads page on the bzr site?
<poolie> Pilky: whoever is making the release; for the last one that was jam
<lifeless> poolie: must be offscreen rendering, I hadn't noticed
<poolie> lifeless: igc was wanting to know if there was anything he can do to help with merging stacks
<Pilky> ok
<lifeless> poolie: updating it to bzr.dev would be good
<Pilky> in that case, jam the OS X 10.5 installer link on the download page still points to 1.4 not 1.5
<lifeless> let me make sure its recorded and pushed
<lifeless> ssh: connect to host bazaar.launchpad.net port 22: Connection refused
<lifeless> bzr: ERROR: Unable to connect to SSH host bazaar.launchpad.net; EOF during negotiation
<lifeless> ?
<poolie> jml ^^
<lifeless> oh yeah, downtime
<poolie> oh
<lifeless> 2 hour window
<lifeless> I would so love to fix that
<lifeless> igc: poolie: sftp://rookery/~/public_html/baz2.0/shallow-branch updated
<igc> thanks lifeless. I'll take a look after I finish reviewing jam's patches
<lifeless> it needs bzr.dev merged into the bottom thread and propogated up
<igc> yup - shall do
<poolie> jam, in your mail about merge annotations (if you're still here) you say "merge node gets annotate (current)" - do you mean that's what we do now?
<poolie> iirc it is
<lifeless> I believe thats what it got updated to do
<lifeless> I would really like to see multi-ancestor annotations
<lifeless> but thats not trivial :)
 * RAOF queues up a strange bzr issue for later.
<lifeless> shoot
<lifeless> no need to queue :P
<RAOF> Actually, it's queuing on _me_.
<RAOF> But public acknoledgement makes it easier for me to remember :)
<lifeless> RAOF.pop()
<jam> poolie: (current) means it is what we do now, yes
<jam> the 'last modified' for that line is set to the merge revision id
<lifeless> so
<poolie> ok
<poolie> replying now
<lifeless> I seem to have a bug with left_matching_block stuff
<poolie> btw is there a bug number for the current failure?
<lifeless> I'd like to run this past someone :P
<lifeless> a left_matching_blocks of:
<lifeless> [(0,0,1), (1,1,0)]
<lifeless> means from 0, to 0, for 1 line
<lifeless> and from 1, to 1, for 0 lines
<lifeless> yes?
<poolie> from memory yes
<poolie> that seems odd
<poolie> i vaguely recall there is always a match anchored at the end even if it's 0 lines
<poolie> ^^ this may be completely wrong
<poolie> lifeless: ^^
<lifeless> this is for ['line'] to ['line']
<lifeless> which is why it smells excruciatingly odd to me
<lifeless> its being generated from multiparentversionedfile though, which is unfamiliar code to me
<lifeless> and I've got cold sweats right now; I think I'm going to call it in a few minutes
<poolie> jam, replied to your annotation mail, hope that helps
<poolie> igc, speaking of faster local branch, it would be nice to show better progress there too
<igc> poolie: progress as in UI, or progress as in 'faster before 1.6 ships'?
<poolie> heh
<poolie> :)
<poolie> i meant progress bars; it's just wishlist though
<igc> my patch cuts the phases from 2 to 1 so ui progress is better IMO
<poolie> oh nice
 * igc lunch
 * poolie lunches
<lifeless> I'm calling it a day
<lifeless> fading too much
<lifeless> I have at least tracked down the failure
<lifeless> we were generating a non-normalised line fulltext
<lifeless> due to a bug in annotation merging
<lifeless> it may well be the cause of some reports in launchpad
<igc> get well soon lifeless
<jml> lifeless: see ya
<beuno> mwhudson, still around?
<mwhudson> beuno: yep
<beuno> so, I'm about to jump into code, but I wanted to run by you what I'm getting into
<beuno> in the revision view (diff), we might have multiple files
<beuno> and now, we show the diff for all of them
<beuno> so, I'd like to try the following:
<beuno> by default, just show what files where changed, and add a "View Diff" to each
<mwhudson> i'm writing a long-ish mail to the bazaar list currently
<beuno> we would get the diff through ajax to make it nicer for the user and the server, and, we generate *just* the diff HTML on the server, most probably skipping the templating engine all together
<beuno> as it should be fairly straightforward to generate
<beuno> on LP specifically, that should reduce resource consumption a *lot*
<beuno> as you wouldn't get every single diff every time, even when the user doesn't want it
<mwhudson> yeah, i think that's probably a sensible idea
<beuno> and, if we find out that getting the same diff multiple times is expensive, we can just cache the diff itself
<beuno> which will be fairly space efficient
<mwhudson> beuno: i sent the mail, see what you think of it
 * beuno reads
<beuno> mwhudson, wonderful. Now we take a 2 week vacation and come back with that solved, right?  :)
<mwhudson> beuno: heh, i doubt it
<beuno> mwhudson, sums it up very well, can't think of anything I'd add
<mwhudson> cool
<mwhudson> now i think i'm going to work on bringing zpt-templating up to date
<beuno> ok, so I'm going to dive into what I explained above, on the zpt branch, which seems like the most promising
<beuno> ah, perfect
<beuno> can you push whatever you have so far?
<mwhudson> ok, it's not much
<beuno> it's just so I diverge as little as possible, not expecting anything new other than resolved conflicts  :)
<mwhudson> beuno: ~mwhudson/loggerhead/zpt-templating/ is up to date with what i have
<mwhudson> aargh, i just want to stab things :/
 * RAOF .pop()
<RAOF> So, sometime in the last couple of weeks I've lost the ability to push a bzr tree to my vfat-formatted USB stick.
<RAOF> bzr push will error out with errno 1: operation not permitted.
<RAOF> I'll pastebin the actual error, but it looks like somewhere around bzr 1.4/1.5 this broke; it previously worked.
<beuno_> server seems to have died  :/
 * igc pick up kids
<beuno_> mwhudson, I can't seem to get the zpt branch working, I've narrowed it down to: http://paste.ubuntu.com/15471/
<beuno_> any ideas?
<mwhudson> beuno: ah right, you need zope.pagetemplate installed
<beuno> ah, it's in zope-replacesupport
<beuno> thanks  :)
<mwhudson> what an obvious package name
<beuno> yes, I thought so
<mwhudson> as in this package? http://packages.ubuntu.com/hardy/zope-replacesupport
<beuno> and the fact that it depends on zope 2.10 makes me think something is going to go wrong
<beuno> mwhudson, yeap
<mwhudson> i find this a little hard to believe
<beuno> that's what apt-cache tells me
<beuno> ah, it lied to me
<beuno> beuno@beuno-laptop:~/bzr_devel/loggerhead.zpt$ apt-cache search pagetemplate
<beuno> zope-replacesupport - Add search and replace functionality to TTW Zope objects
<mwhudson> i think my money is more on zope3
<beuno> I already have that  :)
<mwhudson> then you should have pagetemplates
<mwhudson> ah, perhaps you're running with python 2.5 ?
<beuno> yes, turbogears explodes with 2.5
<beuno> er, 2.4
<bob2> that is definitely not zpt
<mwhudson> beuno: not for me it doesn't
<beuno> it only works for 2.4?
<mwhudson> zope3 only works for 2.4 yes
<mwhudson> i suspect page templates would be fine with 2.5
<mwhudson> gah, why is everything horrible
<bob2> easy_install-2.5ing zope.tal should work
<lifeless> mwhudson: why is everything horrible? 'zope'
<mwhudson> lifeless: it has help
<bob2> harsh!
<lifeless> whats the relationship between kid and genshi?
<beuno> mwhudson, well, hardy seems to come with turbokid 1.0.1, and loggerhead requieres 1.0.4
<beuno> pkg_resources.VersionConflict: (TurboKid 1.0.1 (/var/lib/python-support/python2.4), Requirement.parse('TurboKid>=1.0.4'))
<lifeless> RAOF: please do pastebin the error :P
<beuno> on the other hand, it does work with 2.5  :(
<mwhudson> lifeless: they're more or less equivalent, they're both templating engines
<mwhudson> beuno: eh?  it all works ok for me
<lifeless> mwhudson: at EP some guy whose name escapes me right now - the one that did the input locale which uses brackets not whitespace - was saying that kid was terribly slow and genshii rocked
<beuno> meh, I'll easy_install
<mwhudson> lifeless: i went to the genshi talk at ep, but i think i was still drunk
<lifeless> mwhudson: this was over lunch
<lifeless> SteveA was there
<lifeless> we had pizza
<mwhudson> genshi is much nicer than kid, but it doesn't seem to be much faster or less of a pig resource-wise
<RAOF> lifeless: Sorry; http://pastebin.com/m69b6b5ea
<lifeless> mwhudson: ah, you've tested I presume ?
<mwhudson> whereas my zpt branch is 2-3x faster and uses 2-3x less ram
<lifeless> RAOF: note the temp file name
<RAOF> jml has pointed me at https://bugs.edge.launchpad.net/bzr/+bug/59424 , which isn't my bug but may well be the cause; this seems to be a regression from 1.3
<ubottu> Launchpad bug 59424 in bzr "repository_implementations.test_vfat* is broken." [Medium,Confirmed]
<mwhudson> it's possible the genshi tests were flawed somehow, we haven't spent very long on them
<lifeless> RAOF: one possible cause the multiple dots
<beuno> mwhudson, sorry to be such a pain, but I can't seem to get it working... :(  Am I missing something else?  http://paste.ubuntu.com/15473/
<lifeless> RAOF: but essentially we need to trap and diagnose the bug
<mwhudson> beuno: oh yeah, only the annotate and revision views really work now :)
<mwhudson> beuno: i'm fixing
<jml> RAOF: run the command again with -Derror
<beuno> hahah
<beuno> alright
<jml> RAOF: that'll give you a full traceback
<lifeless> RAOF: the bug is orthogonal
<lifeless> RAOF: you are not even creating your repo
 * beuno breaths
<lifeless> RAOF: have you tried an old bzr to see if it is better
<RAOF> lifeless: It works in 1.3
<RAOF> lifeless: I'm not sure whether it works in 1.4, but this is 1.5
<lifeless> RAOF: if you have the time, it would be great if you could bisect down the mainline of bzr.dev to find the death point
<beuno> mwhudson, cool, works, thanks. I am a bit worried that it doesn't work with python 2.5 by default though (although the speed difference justifies it)
<lifeless> RAOF: I wager it will be a change in tmp file usage, mode management, or object creation
<RAOF> lifeless: Yeah, that's what I was thinking.  I don't have the time right now, but I'll check out the bzr-bisect plugin. :)
<lifeless> RAOF: the plugin just does the math :P. all you need to do is: bzr branch lp:bzr foo; foo/bzr push
<bob2> beuno: it does, just not with ubuntu's zope3 package
<lifeless> bzr revert -r -400 foo
<lifeless> foo/bzr push
<mwhudson> beuno: yeah, that part hadn't occurred to me
<lifeless> bzr revert -r -200 foo
<lifeless> etc
<mwhudson> bob2: oh good
<beuno> well, how would we package it then?
<bob2> mwhudson: afaik the only part of zope3 that doesn't run under 2.5 is some zope2 thing
<RAOF> lifeless: I know.  But I liked git's automated bisect (essentially the only git feature I liked).
<mwhudson> beuno: later
<mwhudson> :)
<mwhudson> let's make it work first
<bob2> this sounds like a job for buildout
<beuno> mwhudson, right, fair enough. Just thought I'd throw it out there. Back to work.
<lifeless> RAOF: AIUI bzr-bisect is feature equivalent; I haven't used it enough to say
<lifeless> RAOF: I have my own ideas on what would be nice; time FTL
<RAOF> lifeless: I'm not sure what 'time FTL' expands to :)
<poolie> abentley: bb is down....
<abentley> poolie: working on it...
<bob2> RAOF: "but I am very busy"
<abentley> load averag is 7.42
<RAOF> bob2: Thanks.  For some reason I was translating as 'Faster Than Light (travel)' :)
<Slant> Can anyone point me toward where to read about how to implement a new transport?
<Slant> Or which source files to start reading from?
<spiv> Slant: bzrlib/transport/__init__.py
<spiv> And other files in that directory.
<abentley> poolie: back.
<beuno> alright, time to get some sleep
<beuno> mwhudson, hopfully I'll have a proof-of-concept branch by tomorrow, based off zpt
<mwhudson> beuno: cool
<beuno> cya tomorrow  :)
<sili> how do I undo a commit?
<vila> sili: for the last commit, you can do: bzr uncommit
<liw> if you want to undo an earlier commit, but keep everything that came after that, you should do a "reverse merge": bzr merge -r 10..9 (if I rembember the syntax correctly)
<sili> ah just found it. thanks
<sili> cool
<mwhudson> beuno: my zpt-templating branch has all views seeming to work again now
<mwhudson> beuno: some have formatting issues
<dato> jelmer: bzr-launchpad???
<dato> jelmer: can you explain to me, wtf?
<dato> (why the split, I mean)
<Jc2k> jelmer: pong
<Jc2k> jelmer: i'll be at work in an hour, and so available for about 7 hours..
 * igc dinner
<Jc2k> jelmer: oooh, nm.. just saw my email :D
<gour> anyone can suggest something in favor of bzr for http://article.gmane.org/gmane.emacs.dvc.devel/2164 ?
<liw> "Merges look terrible in the bzr log output." -- I, on the other hand, find them beautiful and informative
<LarstiQ> gour: and the branch nick defaults to the dirname of a branch, but you can set it with `bzr nick nickname`.
<LarstiQ> gour: Like Aaron does with "Aaron's mergeable stuff" for example
<gour> heh, it would be nice if someone can post something. DVC uses bzr atm, but there is quite a bashing of bzr in favour of git
<gour> i replied recently showing how tailor can be used for git <--> bzr
<liw> I suspect that bashing is not going to stop just because someone injects facts or opposing opinions
<gour> well, facts are facts
<liw> in advocacy, facts are always debatable :)
<luks> I just wonder how did he manage to get that 'git log' output, if it's a 1:1 copy of the bzr branch
<awilkins> re: git/DVC post   i) Doesn't --short cut indented merge info out of the log ii) alias merge to merge --pull if you want that behaviour  iii) nick is useful information if it's used right - an informative name tells you what the branch was being used for
<awilkins> But I think all that's already been said
 * Mez wonders how badly he can kill bzr running bzr gannotate on a file in a svn repository
<jelmer> Mez, you can't, since annotate doesn't work on svn stuff atm :-)
<Mez> jelmer - well - it TRIES to do stuff..
<Mez> and then finally fails with a "database locked"
<Mez> 2nd try just finishes up with a locked X window ;)
<Mez> Exception exceptions.KeyboardInterrupt in <bound method apr_pool_t.__del__ of <libsvn.core.apr_pool_t; proxy of <Swig Object of type 'apr_pool_t *' at 0x915c598> >> ignored
<Mez> jelmer, I must say - checking out a svn branch with bzr is a helluva lot slower than with svn
<jelmer> Mez: It fetches all history
<jelmer> Mez: "bzr co --lightweight" is more like a real svn checkout
<Mez> will that make me something I can work with though (and branch)
<jelmer> yes, but it will contact the remote server a lot more often
<jelmer> (it's similar to a bzr lightweight checkout)
<jelmer> dato: to allow people who don't want to have the launchpad plugin to not have it installed
<jelmer> dato: it also makes sense since the launchpad plugin is totally separate from the rest of the code
<dato> jelmer: I think it's totally a waste an an overkill
<awilkins> dato: What, fetching full history from SVN repo?
<awilkins> It would be nice to see history horizons make an appearance.
<visik7> is there a bisect command like git
<Jc2k> https://code.launchpad.net/bzr-bisect
<dato> awilkins: uh, no. creating a bzr-launchpad package in Debian.
<Jc2k> debian folks dislike launchpad
<rockstar> debian folks dislike *
<LarstiQ> jelmer: If people really object, they can remove the python files themselves. Have you encountered people who object so strongly that it warrants the (archive) overhead of an extra package?
<LarstiQ> jelmer: if I understand you correctly, it is never the case of wanting to install the plugin extra, but only to remove it.
<Jc2k> thats a bit ewww, tho
<Jc2k> it would be trivial to have the bzr source package build a bzr and bzr-launchpad, not really a hardship at all..
<jelmer> dato, http://lists.alioth.debian.org/pipermail/pkg-bazaar-maint/2008-May/000843.html
<jelmer> dato: perhaps I'm underestimating the overhead on the archive
<jelmer> It just seems cleaner to give plugins their own package
<LarstiQ> Jc2k: we (Debian) need less packages, not more.
<jelmer> Jc2k, the bug you reported that affected a bunch of gnome svn branches should be fixed now, btw
<Jc2k> jelmer: i saw, rerunning my script now - all perfect so far
<Jc2k> jelmer: if i want to keep a bunch of branches up to date, is there anything cheaper than keep running svn-import ?
<jelmer> Jc2k: bzr multi-pull
<jelmer> that will update the existing branches
<Jc2k> i was looking at multi-pull, but that won't take account of new branches
<jelmer> but it will not fetch new branches
<Jc2k> right
<jelmer> other than that, svn-import is the cheapest available - it should be pretty quick when branches are up to date
<Jc2k> jelmer: its quite slow against evolution
<Jc2k> about an hour..
<jelmer> wow..
<Jc2k> 23,000 revisions
<Jc2k> quite a lot of branches too
<Pieter> it imports 23000 revisions in an hour?
<jelmer> Jc2k, it's probably somthing funny in the repository layout
<Jc2k> Pieter: no, it already has 23000 revisions
<Pieter> oh.. then I'm less surprised :)
<Jc2k> Pieter: about 1,000 revisions per 5 minutes iirc
<Jc2k> jelmer: any suggestions?
<Jc2k> jelmer: you can grab my evolution repo clone if you want
<Jc2k> actually, i dont know how you clone a repo in bazaar..
<Jc2k> there needs to be a bzr import-bzr :D...
<jelmer> Jc2k: Any chance you can run with -Dtransport and send me the output in ~/.bzr.log ?
<jelmer> Jc2k, there's no easy way but Odd_Bloke worked on a plugin to allow cloning of repositories
<Jc2k> cool
<jelmer> dato: Anyway, if everybody else objects to this I'd be happy to pull it out again
<jelmer> dato: but nobody yelled on the list, that's why I went ahead and put it in
<dato> jelmer: well, I follow -commits more closely than -maint :P
<dato> jelmer: anyway, splits in Debian are normally done because of (a) size, to allow users to unbloat their systems, (b) dependencies, same "bloat" argument
<dato> jelmer: but I'm slowly getting uninvolved, so I guess it's your call...
<jelmer> dato: Ok, I'll see if I cna revert it
<jelmer> dato: Getting uninvolved with Debian or just Debian+Bazaar?
<dato> Debian+Bazaar
<dato> using that I am, *cough*, using mostly git nowadays...
<jelmer> well, same here but that's not by choice :-)
 * dato goes for lunch
<dato> yay spain :P
<jelmer> lol, I know some folks here in .nl that eat dinner at 5...
<james_w> if I want to find whether two branches have diverged is this correct?:
<james_w> graph = branch1.repository.get_graph()
<james_w> diverged = len(graph.heads([branch1.last_revision(), branch2.last_revision()])) > 1
<james_w> also, do I need to do a fetch beforehand if they don't share all ancestory?
<lamont> in keeping with the whole english vs english thing, bzr vizualize should work. :-)
<abentley> james_w: If branch1's repository may not have the relevant revisions for branch2, you should do branch1.repository.get_graph(branch2.repository).
<abentley> The branch1 repository will be preferred.
<james_w> ah great, thanks.
<abentley> heads > 1 is a valid test for divergence.
<Pieter> how can I check out a previous revision?
<james_w> if you want a separate working area then "branch -r" will get you that, if you just want to look at one then "revert -r", if you want to move to an old one and discard the revisions after then "pull --overwrite -r ." or "bzr uncommit -r && bzr revert" will do it.
<Pieter> right, revert -r it is
<Pieter> thanks
<MattCampbell> Is there any way to convert a Perforce repository to bzr, preserving history?
<pasky> http://bazaar-vcs.org/BzrFastImport/FrontEnds
<pasky> or if you want to be particularly elaborate, there's git importer and git has p4 importer ;)
<Pieter> are there any git importers other than through the fastimport frontend?
<pasky> (oh, actually, the p4 importer on the frontend page is git's one; it's nice idea to reimplement the fast-import interface in bzr)
<Pieter> bazaar has a fast-import
<Pieter> but it's kinda crashy and eats tons of memory
<MattCampbell> So the only option is to go from p4 to git and then to bzr?
<Pieter> no, you can use the p4 fast-export and bzr fast-import
<Pieter> it might work
<luks> doesn't look like the git-p4 has a standalone exporter
<emgent> heya
<awilkins> I could just go for a slush puppie
<dennda> Hi
<dennda> I got a branch with several revisions
<dennda> I now discovered that, by magic, one important file got lost
<dennda> How would I best go about restoring that single file from a previous revision?
<jam> dennda: bzr revert -r XXX filename
<jam> bzr commit -m "restore filename"
<dennda> thanks
<ehazlett> greetings... i am getting an error when trying to import a svn repo ERROR: Invalid revision-id {None}
<jelmer> ehazlett: What version are you using?
<ehazlett> Bazaar (bzr) 0.90.0 -- ubuntu
<jelmer> ehazlett: this bug was fixed recently - it's not in any bzr-svn release yet
<ehazlett> ok
<jelmer> ehazlett: you can use the 0.4 branch of bzr-svn but that will requires bzr >= 1.4
<ehazlett> cool.
<ehazlett> i will build from svn :)
<ehazlett> ... bzr ;)
<ehazlett> is the release on the bzr site (ubuntu) 1.4?
<jelmer> no, 1.5
<jelmer> but 1.5 should work just as well
<ehazlett> ok.  thanks for all of your help!
<dvheumen> hi, I was wondering... I know that bzr currently does not support large (binary) files. Is there any indication when this support may be added? (few months? few years?) (If I could contribute, I would, but I am not at all familiar with Python or bazaar, so I think that would be kind of a long shot)
<beuno> dvheumen, well, it supports them, just needs a lot of RAM to do so
<dvheumen> beuno: yeah i figured that much out already reading the mailinglist and sorts
<dvheumen> but I was wondering ... at the moment there's no mention yet of it being implemented any time soon?
<dvheumen> (or not soon :P)
<beuno> a lot of work is being done on performance these cycles, but I'm not sure that's a part of it
<dvheumen> I think I read something about that on the 1.6 milestone list
<beuno> dvheumen, I'd say, make sure there is a bug open about it with enough information, and suscribe/comment on it
<dvheumen> beuno: I found this bug description and I think this is quite accurately described: https://bugs.launchpad.net/bzr/+bug/109114 But it says 'Nominated for 0.90' although I think it isn't of any significance
<ubottu> Launchpad bug 109114 in bzr "commit holds whole files in memory" [Medium,Confirmed]
<beuno> dvheumen, follow up on that. Someone randomly nominated it, but it seems it didn't get done
<dvheumen> beuno: what do you mean exactly with follow up, I have subscribed but do you mean to post more information or something else?
<beuno> dvheumen, yes, that usually helps
<beuno> more ways to reproduce it, attaching your .bzr.log, resource usage, etc
<beuno> it makes it more likely someone will pick it up
<dvheumen> hmmm... okay, posting more resource usage sounds useful... at least it's better than just saying "Hey, ... I'd like this to be fixed too!" :P
<dvheumen> okay, thanks I will do that
<beuno> thanks  :)
<beuno> (I run into that bug quite frequently too, btw)
<dvheumen> well, the thing is that I wanted to use it for something else than just simple source code file storage, but I found out larger files aren't supported yet so that's quite a bummer... other than that this seems to be the VCS I'm looking for
<dvheumen> I'm using SVN at the moment, but I would like to have some more distributed features and such
<beuno> yes, it's definetly something we want ASAP
<pickscrape> Won't the streaming stuff I've read about help there, or is that a different part of the code?
<dvheumen> I've read something about a MemoryError fix for HTTP Proxy something
<dvheumen> but I thought that it was about a different function, mainly because it specifically names HTTP
<dvheumen> although I think these kind of things can be fixed with doing a streaming diff with a fixed window
<dvheumen> I think the fix you just talked about is this one: https://bugs.launchpad.net/bzr/+bug/215426
<ubottu> Launchpad bug 215426 in bzr "MemoryError - recv for HTTP through Proxy" [Medium,Fix released]
<beuno> yeah, I think that's unrelated
<dvheumen> I have to go, thanks for the information ... it may take a few weeks because of examinations, but after that I'll try to post some performance/resource information if it helps you
<jam> vila: earlier you talked with abently about how the LP mirror of bzrtools seems out of date
<jam> I believe that is because it is a manual upload
<jam> not an lp mirror
<jam> At least looking at: https://code.edge.launchpad.net/~abentley/bzrtools/bzrtools.dev
<jam> It doesn't show it as a mirror branch
<jam>                  You cannot upload to this branch. Only                 Aaron Bentley                 can upload to this branch.
<jam> vila: do you remember the official location Aaron gave?
<jam> http://bazaar-vcs.org/BzrTools
<jam> has the launchpad one
<jam> I suppose I found http://code.aaronbentley.com/bzr/bzrrepo/bzrtools/ by poking around manually
<vila> jam: that's the one aaron gave me (I was having dinner, sorry for the delay ;-)
<jam> vila: I'm deeply offended that you would think to go away from IRC for long enough to eat
<jam> I expected more from you, vila
<jam> :)
<jam> I hope the food was good
<vila> apache2 was giving an headache, I had to eat :-)
<vila> It seems I can't explain him that I want directory listings...
<jam> vila: <Directory "/srv/bzr/public">
<jam>     Options Indexes FollowSymLinks
<jam> Isn't that enough?
<vila>  no :-(
<beuno> vila, maybe it has NoOverride set?
<vila> beuno: Hi
<vila> beuno: How can I check that ?
<vila> It's a test server with a very limited configuration
<fullermd> jam: re: bug 235715; could well be a 'cherrypick' in the form of 'add --file-ids-from'...  I do that from time to time when I find I want a file on 2 branches that will be merging somewhere down the road.
<ubottu> Launchpad bug 235715 in bzr ""bzr merge --lcs" (criss-cross merge) stops with error "bzr: ERROR: Reserved revision-id {null:}"" [High,Confirmed] https://launchpad.net/bugs/235715
<jam> fullermd: well, this was converted from another source
<jam> so there are lots of ways it *might* happen
<beuno> vila, let me see how to check for that...  (it's very normal in shared hosts)
<beuno> vila, can you see the apache conf file?
<vila> just a sec
<gour> how does lighttpd play with bzr?
<beuno> vila, check for: "AllowOverride None"
<vila> !paste
<ubottu> pastebin is a service to post multiple-lined texts so you don't flood the channel. The Ubuntu pastebin is at http://paste.ubuntu.com (make sure you give us the URL for your paste - see also the channel topic)
<beuno> /etc/apache2/sites-enabled/000-default would be the default location
<vila> http://paste.ubuntu.com/15607/
<beuno> vila, check in the location above ^
<vila> ...and don't tell me 66 lines is evil :-)
<vila> beuno: it's not included
<vila> it's a test server I setup myself, not the default apache2 server
<vila> from http://localhost/doc/apache2-doc/manual/mod/mod_autoindex.html#indexoptions all I have to do is to laod the module and use 'Options Indexes' I put a '+' just to be sure :-/
<beuno> vila, I always add that within the <Directory> bit, which you seem to not have setup
<jelmer> abentley: anything in particular that's blocking rich-root-pack as default in 1.6 ?
<james_w> I'm working on the SRU for bug 230294, and I need a test case for verification of the fix, a checkout over http doesn't trigger it, are there more conditions that need to be true?
<ubottu> Launchpad bug 230294 in bzr "ERROR: bzrlib.errors.KnitCorrupt: Knit <bzrlib.knit.KnitGraphIndex object at 0x86e1e2c> corrupt: attempt to add line-delta in non-delta knit" [Undecided,Fix released] https://launchpad.net/bugs/230294
<vila> beuno: Because I presumed <directory> inherits from server settings and, as it is a test server, I don't know what directories will exist
<gour> huh, more bzr rant in dvc-thread http://article.gmane.org/gmane.emacs.dvc.devel/2166
<jam> statik: we on for "this week" in 5 min?
<vila> gour: If you read the thread, you'll see that mwolson is not an example of impartiality, I will not continue that discussion
<beuno> vila, try adding a <Directory> config
<abentley> jelmer: http://bundlebuggy.aaronbentley.com/request/%3C48221A5F.60208@aaronbentley.com%3E and uncertainty about whether we should do a new format just be be safer.
<vila> beuno: I tried it (deleted it in the pastedbin), same results
<vila> the error log says Attempt to serve directory: /v/home/vila/.bazaar/plugins/local_test_server/work/apache2/www/tagada/
<vila> or without 'tagada' :-)
<vila> in the apache sources that string appears in asingle place>: when serving a GET request for a directory in the default handler
<beuno> vila, well, the only other configs I ahve related to Indexes are:  "IndexOptions FancyIndexing VersionSort" and ""
<vila> tell me more about ""
<vila> :-)
<beuno> vila, lol
<beuno> I was expecting for 2 config options, but it was unrelated
<gour> vila: you're right. "not possible to teach old dog new tricks..."
<vila> too bad :-/
<beuno> and it's a bit crazy at the office today, so I was talking to someone while typing  :p
<beuno> vila, any symlinks involved?  if there is: add: FollowSymLinks
<beuno> and I'm out of ideas  :)
<vila> beuno: thanks for the help, I tried all of that, thanks for confirming these solutions, may be something else is wrong in my setup
<jam> james_w: generally you have to push from a pack repository into a knit repository
<jam> I *think* you have to push multiple revisions
<beuno> vila, one last thing that may have something to do with it:   DirectoryIndex index.html index.cgi index.pl index.php index.xhtml
<statik> jam: sorry i had to run downstairs for a minute, i'm back
<jam> and then it will create one with a 'line-delta' when it shouldn't
<jelmer> abentley, thanks
<jam> then when you pull back from the knit repo => pack repo
<james_w> jam: ah, thanks, I got a failure with bzr+ssh://
<jam> it fails because it shouldn't have had the line-delta in the first place
<jam> statik: so you ready for thisweek?
<james_w> the problem now is that the patch doesn't apply to 1.3.1
<jam> james_w oops, why not?
<jam> I'm guessing it is close to correct
<james_w> I can't find any of the context from the diff -c of the revision that claims to fix it from bzr.dev
<jam> james_w: don't you mean bug 217701?
<ubottu> Launchpad bug 217701 in bzr "attempt to add line-delta in non-delta knit" [Critical,Fix released] https://launchpad.net/bugs/217701
<james_w> jam: yep, this is a duplicate, but it's already set up for an SRU, so I'll just carry on.
<vila> statik: ping, do you have a few minutes ?
<jam> vila: statik and I are working on "This Week" in bazaar right now, but he might have some time
<vila> jam: remind me the url again :)
<jam> jam-bazaar.blogspot.com
<vila> thks
<jam> statik: you got to "probably gonna drop my".... static
<vila> YES
<vila> stupid apache doc
<vila> they say: "so you can use or desactivate module A and/or B" but they forget to say: if you want module B only, load module A anyway :-)
<vila> soooo, if you need autoindex_module, load dir_module, just because
<vila> and with that apache2 pass the bzr test suite (well, the 70 tests triggered by bzr selftest -s bzrlib.tests.test_transport_implem -v Apache2 )
<felipec> how can I clone this? http://stephan.kochen.nl/bzr/gstraopsink/
<beuno> felipec, bzr branch http://stephan.kochen.nl/bzr/gstraopsink/
<felipec> beuno: thanks
<beuno> felipec, welcome'
<felipec> I tried with .bzr =/
<vila> beuno: the fix was to 'LoadModule dir_module /usr/lib/apache2/modules/mod_dir.so' :-/
<beuno> vila, ah, I would ov never guessed that  :)
<jam> vila: all that to test against the test suite
<jam> ouch
<vila> now that you mention it, I have already forgotten why the hell I tried that...
<jam> Do we need indexes to be able to run against apache?
<jam> We shouldn't
<vila> jam: strange isn't it, before I activated it the failing test was: test_has_root_works
<lifeless> jam: that mpdiffs stuff you are doing; the extra try:finally also seems redundant to me
<jam> lifeless: it was already there, if you want, I could just get rid of it
<lifeless> jam: I have found an apparent bug leading to deltas with 1 line too few in that code though - with annotated knits
<lifeless> jam: I'm replacing the entire code section
<vila> jam: but being able to plug a real server in the test suite will greatly simplify writing test servers for https and webdav, simplifying writing correct client implementations, simplifying writing robust ftp client implementation, etc, etc,
<jam> lifeless: I'm fine with seeing it go, but we may want to patch it until your stuff lands
<lifeless> jam: don't wait
<jam> vila: sure, I think it is a great thing to have. I'm trying to understand why we would need indexes
<jam> vila: because if we do, it means we have a bug
<jam> lifeless: for this week in bazaar, I'm writing about Stacked Branches
<jam> do you have any URLs I could give?
<vila> jam: I don't think we really *need* indexes, but I don't want to gratuitously skip some tests either
<jam> vila: sure. something called "has_root" sounds like something that we shouldn't be doing anyway
<vila> I'm interested in understanding why test_has_root_works (which test transport.has("/") is needed though
<jam> It might be a carry over from old transport tests
<statik> vila: i suck, i'm on the phone solid all day today
<jam> vila: I would say that we *don't* need it, but we probably had a bug with passing an absolute path at one point
<vila> statik: just one word then :-) Are you just delayed or something wrong is going on ?
<jam> we shouldn't be *passing* absolute paths to those functions
<statik> vila: just delayed
<vila> statik: 2 good words, thanks :)
<lifeless> jam: only those in the various communications I've made about it
<jam> well, are there *public* ones?
<jam> I remember some comments about rookery, etc
<jam> This is something that we would point interested users to
<jam> lifeless: I honestly haven't seen any URLs given on bazaar@lists...
<jam> Only on bazaar-canonical@
<jam> which means it isn't public
<lifeless> uhm
<jam> I just went back and searched my folders
<lifeless> I'm sure I've posted the loom location, status updates etc all to bazaar@
<jam> I found "Stacking Policy" from aaron
<jam> Your status updates haven't had a url in them
<jam> just "Things to be done"
<lifeless> all the bundles have source_branch: http://people.ubuntu.com/~robertc/baz2.0/shallow-branch in their headers
<jam> lifeless: with the one caveat that all of your submissions have been under the heading "VersionedFiles" not "Stack*"
<jam> and while I realize one is a precursor to the other
<lifeless> or shallow
<lifeless> in fact, 'shallow' predates versionedfiles
<lifeless> in the bazaar@ mail list
<michalski> hey, I've got a problem: when typing:  bzr push lp:~michalski/+junk/<XYZ>
<michalski> it comes back with error:
<michalski> Unable to obtain lock lp--1221433044:///~michalski/+junk/vector-core/.bzr/branch/lock
<michalski> held by michalski@bazaar.launchpad.net on host vostok [process #22773]
<michalski> locked 79 minutes, 10 seconds ago
<beuno> michalski, bzr break-lock lp:~michalski/+junk/vector-core
<michalski> ah ok :) thanks
<beuno> (a better message for that will be available in the next bzr release)
<michalski> worked, thanks beuno
<james_w> statik, jam: nice work, it's a good explanation
<james_w> is there any plan for server-side forking in launchpad with stacked branches?
<statik> james_w: thanks! lp will support stacked branches, but I think server-side forking is a ways off.
<lifeless> abentley: ping
<abentley> lifeless: pong
<lifeless> I've got something wrong with mpdiffs in my new code
<james_w> fair enough, I think it may make it clearer to a user what is going on, but I understand that it makes very little difference to the data.
<lifeless> I'm hoping you can spend a few minutes with me to walk me through/clarify some stuff
<abentley> Sure.
<lifeless> so in an annotated knit the 'noeoldup' test text fails
<lifeless> it ends up serialising wrongly - the serialised text is missing a \n and the knit record is corrupted
<lifeless> I've tracked this down I think to the output of get_mpdiffs differing
<lifeless> in the original knit code, we get:
<lifeless> MultiParent([NewText(['line\n'])])
<mwhudson_> beuno: hello!
<lifeless> (which is conceptually strange to me, because both texts are == ['line'] )
<lifeless> in the new code, we get:
<beuno> mwhudson_, morning!  I was just closing all my work-related windows to get started on loggerhead   :)
<lifeless> MultiParent([ParentText(0, 0, 0, 1)])
<lifeless> which is what I would expect
<mwhudson_> :)
<lifeless> (the new code runs same test scenario tweaked for api etc)
<abentley> So you are doing a diff and the ï»¿MultiParent([NewText(['line\n'])]) is the result?
<lifeless> with the original knit code yes ('test_make_mpdiffs' from test_versionedfile.py)
<lifeless> I checked that by adding:
<lifeless>             if version == 'noeoldup':
<lifeless>                 print "Y", mpdiff, version
<lifeless> to that tests inner loop
<lifeless> now what I *think* might be happening is that the get_mpdiffs with knits is broken for the specific case of the last line with noeol
<lifeless> but that something else is compensating on insertion
<abentley> Another possible problem would be trusting the KnitDelta's concept of 'line'.
<abentley> It might be split on
<abentley> \r or something.
<lifeless> not in the test case :)
<lifeless> ok, well I'll keep poking at this
<lifeless> I am concerned that when I find the root cause and fix it for the original code there will be some underlying issue exposed
<abentley> lifeless: A NewText always has a trailing newline.
<abentley> At least in the serialization.  Quite possibly in the repr
<lifeless> ok
<lifeless> how do you signal to a reciever that they should not have a trailing eol ?
<abentley> I signal that they *should* have a trailing eol by doubling it.
<abentley> Having a single \n means it should be stripped.
<lifeless> ok, so ['line\n', '\n'] -> 'line' as bytes ?
<abentley> No, ['line\n'] -> 'line'.  ['line\n', '\n'] -> 'line\n'
<lifeless> right,
 * lifeless wipes sleep from eyes
<lifeless> alright, the generated patch is ok, but its not matching where it can
<beuno> mwhudson_, I'm going through all the comments on the theme, so I can address all of them and move on to the HTML/CSS fun-part
<abentley> lifeless: Odd, but I guess better.
<lifeless> ahha!
<lifeless> _extract_blocks is buggy
<lifeless> abentley: can you do an experiment for me, just want to know its not me :)
<abentley> I can do a quick one.
<lifeless> change _extract_blocks in knit.py to return None
<lifeless> and run
<lifeless> ./bzr --no-plugins selftest versionedfile.*make_mpd
<abentley> I get a KnitCorrupt.
<lifeless> yup
<lifeless> excellent
<abentley> Knit <bzrlib.knit._KnitAccess object at 0x9ad5eac> corrupt: incorrect number of lines 1 != 2 for version {noeolsecond}
<lifeless> we currently never match the last line of identical files if they both have no trailing eol
<abentley> lifeless: We currently override that, actually.
<abentley> see KnitContent.get_line_delta_blocks
<lifeless> abentley: indeed - to never match
<abentley> lifeless: The intention is to make them match.
<lifeless> abentley: but if no optimised matcher is provided, we do a full diff, which the code I'm working on does
<mwhudson__> beuno: sounds great
<lifeless> (because I haven't yet hooked in the optimiser)
<lifeless> abentley: well, it doesn't seem to have the effect of making them match
<abentley> Well, this is in the case when there's an optimizer present.
<lifeless> the optimiser should say they match totally, but it doesn't
<lifeless> anyhow
<abentley> Why not?
<lifeless> I don't know - I've been working through this as we speak, as I said I didn't know enough
<lifeless> when I started digging I just had a knit corrupt and was pulling on the chain
<abentley> knit.py: 332 is supposed to do specifically that.
<lifeless> all I can say right now is that when there is no optimiser the diff correctly reuses the parent text entirely
<lifeless> and that we have a separate more severe bug
<lifeless> inserting into annotated knits with an identical noeol text that is a snapshot corrupts the text
<lifeless> (which is the error you see)
<lifeless> so we can't actually fix this generation bug for current bundles, or something
<abentley> Ah.  Bogus.
<lifeless> (it copies the annotated representation from the basis including the *lack* of trailing \n, so the record can't be parsed)
<lifeless> I'll finish analysing this on bzr.dev and write it up for consideration by the list
<lifeless> It's orthogonal to what I'm doing, and now I know it exists in potentia in bzr.dev I'm not blocked
<lifeless> thanks for the hand, very useful and saved me time
<abentley> lifeless: I don't recall precisely how it worked with annotation, but it's a bit surprising, because mpdiffs aren't annotated.
<jelmer> lifeless: I've almost finished merging bzr.dev into your shallow branch branch, btw
<mkanat> jam: If you have any questions about https://bugs.launchpad.net/bzr-cvsps-import/+bug/235884 I'll be around for a bit (if you're around).
<ubottu> Launchpad bug 235884 in bzr-cvsps-import "cvsps_import can think that trunk checkins happened on a new branch" [Undecided,New]
<jam>  mkanat: If i was to bet, I would say it is confusion on the part of cvsps, and I'm just copying what it is telling me to
<mkanat> jam: It's possible. I can attach the cvsps log, I'll do that.
<mkanat> jam: I was thinking it was also possible that cvsps_import creates branches by branching against HEAD w/o a revision number.
<jam> mkanat: that is possible as well, though the graph itself should tell me where to branch
<mkanat> jam: Yeah. There's some weirdness in Patchset 8195, where it says that one file is INITIAL->1.95, on HEAD.
<mkanat> How do you fix the content-type of an attachment in Launchpad?
<jam> mkanat: AFAIK it is auto detected, I don't know a way to change it
<mkanat> That's kind of lame. I can't imagine why it would have autodetected that file as text/html. "file" says it's ASCII text.
<mkanat> Looks like I can't fix it by manually branching from HEAD at the right point, I get a traceback from bzr when doing an import after that.
<jam> mkanat: are you getting this warning:
<jam> trace.warning('%s claims an ancestor branch %s which does
<jam>               ' not exist yet. Falling back to HEAD',
<jam>               patchset, patchset.ancestor_branch)
<mkanat> jam: I'll check.
<mkanat> jam: Not unless --quiet turns that off.
<jam> mkanat: so... looking at the code, I think you are approximately correct
<jam> specifically, I see this patch:
<jam> PatchSet 8199
<jam> Date: 2008/05/21 23:03:24
<jam> Author: lpsolit%gmail.com
<jam> Branch: BUGZILLA-3_2-BRANCH
<jam> Ancestor branch: HEAD
<jam> Tag: (none)
<jam> Log:
<jam> mkanat: the problem is that cvsps import doesn't actually give me a base revision to branch from
<jam> so I just branch from whatever is the current tip
<mkanat> Ah, yeah.
<mkanat> You could figure it out, theoretically, from the version numbers.
<mkanat> Provided that they haven't done anything wonky with their cvs binary.
<jam> mkanat: and part of *that* is because CVS logs aren't very good at telling you what was going on
<jam> mkanat: what version numbers?
<mkanat> Yeah, I ran into a lot of that with VCI.
<jam> the one for the file?
<mkanat> jam: The file version numbers.
<jam> 1.7->1.7.2.1
<jam> But did *that* file change on HEAD
<mkanat> jam: Yeah. 1.7 will have existed in some patchset.
<jam> or just the *other* files
<mkanat> Oh, right.
<mkanat> Because you can't know what the actual last HEAD revision was.
<jam> yeah
<mkanat> Man, CVS is so lame.
<jam> mkanat: you might find that using "cvs2svn --fast-export | bzr fast-import" works better for you
<jam> I don't really know
<mkanat> jam: If you had actual access to the repository files, would there be any way to figure that out, do you know?
<mkanat> jam: The problem is that I have about 30 branches based on my current imports, right now.
<jam> mkanat: unforunately, I don't know much detail about how cvsps works
<jam> I built on it, since it seemed tobe the recommended tool
<jam> (everyone else was doing it, and such)
<jam> only to find out later that it isn't really very good
<mkanat> Yeah. I did the same when I needed to abstract away CVS.
<mkanat> Yeah, but it's still the only tool.
<mkanat> jam: I'd be fine with switching to cvs2svn, but I need to keep my current branches updated...
<lifeless> abentley: the corruption is not mpdiffs fault AFAICT
<lifeless> jam: this is why cscvs doesn't use it :P of course cscvs then has its own problems
<mkanat> jam: I also have no idea how it's constructing the history now, pulling patches with an unrelated history...
<jam> mkanat: I'm not sure what you mean by unrelated history
<abentley> lifeless: Ah, cool.
<mkanat> jam: Well, theoretically a file is a collection of changes, and we have some HEAD changes followed by some 3.2 changes that may or may not have been to files with the same content.
<lifeless> abentley: its just triggerable *by* mpdiffs, and only triggers when mpdiffs creation is fixed for this corner case
<lifeless> abentley: a classic example of cascade failure/masked bugs
<jam> mkanat: I believe it goes to 'snapshots' each time
<abentley> Heh.
<mkanat> jam: Ahh...
<jml> lifeless: hi
<jml> lifeless: may I draw your attention to my bzr-loom patch.
<lifeless> jml: the one I reviewed?
<jml> orly?
<mkanat> jam: Any suggestions on how to fix the situation I'm in now? Reverse the additional checkins?
<lifeless> couple of days ago?
<jml> lifeless: where did you review it?
 * jml frowns
<jam> mkanat: well, depending on what is going on you *might* be able to rebase your changes onto a new converision
 * jml sees now
<jam> I don't know how well rebase handles that case yet, but it is a use case for it to handle
<mkanat> jam: Oh, we have rebase now?
<lifeless> we do, in a plugin
<lifeless> where it shall remain ;P
<mkanat> Hahaha.
<jam> mkanat: there is a plugin, worked on by jelmer, lp:bzr-rebase
<lifeless> there is a bug open on it for integration with treemapper
<lifeless> which would be needed to do what jam is suggesting
 * elmo is still waiting for bzr rerere
 * lifeless tickles elmo
<lifeless> I love how that is spelt: '/me tickles elmo'
<jml> lifeless: anyway, thanks for the review.
<lifeless> its *almost* right
<mkanat> Yeah, I'd think that this would be a good use case for rebase.
<mkanat> lifeless: So you're saying that rebase won't do what I need right now, then?
<lifeless> mkanat: AIUI there is a missing feature - the file id mapping logic. I may be wrong.
<lifeless> mkanat: but given you are converting between two mirrors of cvs, no renames are involved so a simple-implementation would likely suffice
<mkanat> lifeless: Okay. I guess I'll try and see if it goes.
<jam> by the way elmo, thanks for whatever you did to pqm, it is much snappier now
<jam> (that could just be updating to the latest kernel)
<lifeless> jam: it's a bzr bug
<lifeless> jam: elmo replaced the kernel to work around it
<jam> lifeless: sort of
<jam> The fact that one kernel is 10x slower than the other...
<jam> I can agree that it going from 5 => 18s is bzr
<jam> but going from 5 => 300ms seems like the kernel
<lifeless> jam: there are two theories. one is the GIL & thread starvation, the other TCP autotuning
<lifeless> jam: elmo thinks its tcp autotuning that the new kernel *adds* (e.g. kernel works around broken application requests)
<lifeless> jam: I think its GIL starvation due to scheduler changes
<jam> by the way, I wasn't able to reproduce it on tungsten
<lifeless> jam: either way its around 99% certainty that bzr is faulty
<elmo> jam: what?
<jam> at least, when I ran the test it ran in 300ms
<jam> rather than 5+s
<lifeless> really must disappear for a bit
<jam> elmo: I submitted 2 patches to PQM, and it was done in < 1 hr
<jam> It used to take 2hrs to complete 1
<jam> So I appreciate your work in that area
<elmo>  jam: try the branch in ~james/haha/home/+trunk
<elmo> it's entirely reproducable on tungsten there
<elmo> if it's gone in current bzr.dev that jus tproves it was bzr and not the kernel ;-)
<elmo> as spiv said he fixed the batching of stuff in the smart server
<jam> right, but AFAIK that would explain 5=>18 not .3
<elmo> err, no?
<elmo> it's 18 on tungsten right now, if I upgraded tungsten's kernel, it'd go to .3
<elmo> it goes to 5 iff I revert back from that branch -1000 revisions
<elmo> + stay on the current kernel
<mkanat> jam: Oh, cvs2svn won't do what I need, since it apparently doesn't support repeated syncs.
<jam> elmo: well we seemed to have fixed it then, bzr.dev @3452 gives 394ms
<jam> and I did reproduce your "haha" at 18.5s
<elmo> ok, cool
<elmo> spiv: ^-- whatever you did, don't ever undo it ;-)
<jam> elmo: how did you get that directory? it would probably be good to know what revision, etc you are using there
<elmo> jam: that was a copy of trunk at the time we were diagnosing the problem
<jam> elmo: so you don't have an idea of a number, right?
<jam> I think I just isolated it to Spiv's buffering patch
<jam> rev 3451 == 18.9s
<jam> rev 3452 == 349ms
<jam> pretty good indication
<jam>  3452 Canonical.com Patch Queue Manager 2008-05-24 [merge]
<jam>       Speed up HPSS v3 by buffering writes to the medium. (Andrew Bennetts)
<jam> elmo:  so I got "lucky" that andrew had just merged his patch when I went to test the bug
<elmo> jam: right
<lifeless> jam: see, bzr :)
<elmo> oh, yay, that revision even had tests
<lifeless> jam: generally, whenever bzr is slow, its bzr's fault until proved otherwise :)
<lifeless> irrespective of the width of the change
<johan> $ bzr push lp:~jdahlin/bzui/main
<johan> bzr: ERROR: Transport operation not possible: http does not support mkdir()
<johan> do you guys know why I get this?
<johan> using bzr 1.3.1
<beuno> johan, you probably haven't set your lp-login
<beuno> bzr launchpad-login username
<johan> beuno: oh
<beuno> should solve it
<johan> not a very good error message ;)
<beuno> not at all, and it's been fixed in 1.4 I believe
<beuno> (you can get the latest and greatest from the PPA)
<beuno> https://launchpad.net/~bzr/+archive
<johan> cheers
#bzr 2008-05-30
<jam> vila: btw, I've been using your --startingwith a lot lately, thanks for doing it
<jam> It actually jumps out at me when I'm using an older branch which doesn't have it
<james_w> Is there a pleasant way of deciding whether something is remote?
<james_w> I take BRANCH as an argument on the command line, if it is local then I want to "cd" there, if it isn't I want to change some values of something
<james_w> it doesn't have to be perfect in checking whether something is local, and  I don't mind about the case that someone gives an sftp:// URI that resolves to their current working directory.
<james_w> would just checking for local paths and file:// URIs with string comparison be ok?
<james_w> local = urlparse.urlsplit(location)[0] in ('', 'file')
<james_w> that would seem to do it
<beuno> mwhudson, you've got mail.  Let me know if that addresses your comments
<poolie> lifeless: can you please set up a pqm 1.6 branch some time soon
<poolie> actually nm
<poolie> we'll wait to branch til next week
<mwhudson> beuno: ok
<beuno> cool, ipython uses bzr and LP!   http://ipython.scipy.org/moin/
<igc> morning
<mkanat> jam: Where is cvsps-import storing the map history?
<jam> mkanat: look at your output there should be a directory where it is storing something.map
<jam> I don't remember off-hand
<jam> but it should be fairly obvious
<mkanat> jam: Okay.
<mkanat> Ah, yeah.
<mkanat> jam: If I do a manual checkin on one of the branches, will it break fmap?
<jam> mkanat: you aren't supposed to be modifying these branches outside of cvsps, I'm not sure what will happen if you do
<mkanat> Hm.
<mkanat> jam: I'm trying to figure out a workaround for the situation I'm in, any ideas?
<Pieter> Hmm.. I downloaded the bzr emacs repository from http://bzr.notengoamigos.org/emacs.tar.gz, but I get a fatal error when trying to check out revision 50255
<jam> mkanat: well, you can fix cvsps or rebase....
<jam> sorry I don't have a better answer
<mkanat> jam: It looks like rebase won't work, as far as I can see...
<jam> mkanat: sorry you can fix (cvsps or rebase)
<mkanat> Ahh.
<jam> not (fix cvsps) or (rebase)
<mkanat> jam: What would happen if I surgically remove those revisions from revision-history?
<mkanat> Ha, okay, that's bad.
<Pieter> jearl`: you there?
<spiv> Ah, I'm back online.
<lifeless> mkanat: uncommit should be fine, I would expect converters to just re-add them tho :P
<lifeless> mkanat: also, you may find that there are fixes for the cvsps program itself 'out there', I've seen various folk talk about patches for it
<mkanat> lifeless: Yeah, but this one isn't so much a bug as a missing feature.
<mkanat> lifeless: Also, there are commits after the "bad ones".
<lifeless> mkanat: sorry, I didn't track the very start of the conversation; whats the root bad behaviour of cvsps?
<mkanat> lifeless: It doesn't track what patchset a branch starts at from its parent.
<lifeless> so how do we create new branches at all?
<lifeless> does cvsps-import infer that itself?
<lifeless> jam: ^ ?
<mkanat> lifeless: I think so. I think the first time it sees a branch name it branches it from its ancestor at that point in time.
<mkanat> lifeless: I'm guessing there's no way to uncommit a series of revisions that aren't actually the most modern set.
<jam> lifeless: The stream of cvsps tells you "create a new branch, originating from this branch"
<jam> It doesn't indicate at what point in time along the other branch to split, it was just inferred by order
<lifeless> jam: ok
<lifeless> jam: so could we not just run cvsps in toto again, checking it for consistency against the last output
<james_w> lifeless: hi, do you have a minute, I'd like to confirm something?
<lifeless> james_w: shoot
<james_w> lifeless: is your idea that a revision should only appear in the left hand ancestory of a branch if it was uploaded to that distribution?
<jam> lifeless: I think cvsps deterministically gives the same results each time
<lifeless> james_w: from the branch point yes
<jam> lifeless: if it didn't, then I couldn't support resume without more work
<james_w> lifeless: e.g. if Debian was to upload two versions quickly, and the first wasn't synced then it should not be a revision in the Ubuntu branch.
<lifeless> jam: surely then new branches appear in the entire output correctly?
<jam> lifeless: apparently not
<jam> It seems that if you tag a branch
<jam> and then do a couple of commits on the source branch
<jam> and *then* commit to the new branch
<jam> it shows the same thing
<jam> except it doesn't realize that the tag was on an earlier commit
<lifeless> oh, date sorted output
<jam> something like that
<jam> it claims to do topological sorting, etc
<jam> but we are seeing date sorted here
<james_w> lifeless: what about packages that predate Ubuntu, should they adopt the history of the Debian branch?
<lifeless> james_w: I'm not sure what you mean
<james_w> lifeless: this is stage 2 really, but I want to get it clear in my head, the first version of package foo didn't appear in Ubuntu as it predates it, so if the above statement is true it should not be in the left-hand ancestory. However, this would mean that the branches for Debian and Ubuntu are divergent, even if foo has only ever been synced from Debian.
<james_w> is that the desired behaviour?
<lifeless> ah
<lifeless> so perhaps rephrasing
<lifeless> 'every upload we import from ubuntu should be in the left hand ancestry'
<james_w> sure
<lifeless> does that help ?
<james_w> and in the first case, where debian uploads two packages quickly and only the second is synced, should that cause divergence, or would it be ok to include the first upload in the left hand ancestry?
<lifeless> I think that is fine
<lifeless> given you're tagging to identify distro versions orthogonally to revision ids
<lifeless> I don't think I ever suggested that commit should imply upload, only that upload -> left hand commit
<lifeless> (If I did, sorry for confusion, I didn't intend to)
<lifeless> abentley: I have a test case
<james_w> ah, no, you didn't imply either way, I don't think. I was just unsure, so I wanted to confirm before getting too far down one path.
<james_w> thanks for your time.
<lifeless> abentley: http://pastebin.com/d54e0a61e
<lifeless> abentley: if you could just eyeball that and see if it makes sense to you
<james_w> back to bed :-)
<lifeless> fun, it breaks everything
<lifeless> actually, http://pastebin.com/d3ba9db64 is the working version
<abentley> lifeless: on line 21, is that "line\2line..."?
<lifeless> abentley: oh, nice catch :)
<lifeless> should be \n indeed
<lifeless> now it only breaks annotated weaves as expected
<abentley> Is the first vf only being used to generate a sha1?
<lifeless> yes, I am shrinking it further now
<lifeless> if it appears to make sense to you that is
<abentley> I forget what the parameters to ParentText are...
<lifeless> parent number
<lifeless>  |  __init__(self, parent, parent_pos, child_pos, num_lines)
<lifeless> I got those numbers by printing the bzr generated mpdiff with the optimiser disabled
<lifeless> but I wanted a test that was independent of that other discussion
<abentley> Yeah, assuming that \2 is \n, it looks reasonable.
<lifeless> thanks
 * fullermd hates the launchpad bug mailings...
<fullermd> Every time I THINK I've captured every way they can get to me, some whole new set of headers arrives...
<lifeless> ok, it has to be on top of a delta to trigger the error
<lifeless> http://pastebin.com/d3b2ceea5
 * igc running some errands - bbl
<lifeless> yay finally triggered this without mpdiff involvement
<poolie> lifeless: no test for 234748 yet, will do it soon
<lifeless> poolie: I'm dealing with a very similar bug
<lifeless> nearly finished
<lifeless> if you have a fix for 234748, perhaps you could try my test case against it ?
<poolie> happy to
<lifeless> http://pastebin.com/d6b23fcca
<jml> feature request:
<lifeless> a request for a feature
<jml> bzr foo --hlep should show the help for foo
<poolie> it does
<jml> If I can't type 'help' then I probably need it.
<poolie> unless you meant literally hlep
<spiv> Hmm.  We have quite a few tests that rely on indirect ways to force snapshotting in knits.  Which is fine (we don't want a public API for that), but maybe it deserves some explicit test infrastructure so that if the snapshotting heuristic changes we don't have to change/audit lots and lots of tests.
<poolie> oic :)
<lifeless> spiv: indeed. I'd already written:
<lifeless> meh
<lifeless> I'll finish, commit and you can review instead ;)
<spiv> lifeless: ok :)
<LaserJock> is there anybody specifically looking at git-bzr bridging?
<lifeless> igc
<LaserJock> I just had a possibly nasty idea of CVS -> git -> bzr
<lifeless> why?
<lifeless> cvs->git recommends cvs2svn fastexport nowadays
<lifeless> and bzr-fastimport can read that directly
<LaserJock> because CVS -> bzr isn't quite working and cvs->git is working for me
<LaserJock> hmm, maybe I should try bzr-fastimport then
<LaserJock> wait a sec though
<LaserJock> why doesn't LP use bzr-fastimport then
<poolie> LaserJock: i think fastimport is probably the way to go
<poolie> but it would be good to just fix the bugs in reading from cvs2svn
<poolie> jelmer was looking at doing git foreign branch support though
<lifeless> poolie: did your fix fix my test case? I would expect not ..
<poolie> sorry have not tried it yet, will now
<poolie> !!
<poolie> yes it did
<lifeless> thought it might
<poolie> i am a bit surprised; i thought this only affected the multiple extraction case
<poolie> interesting
<lifeless> no
<lifeless> we've an awkward abstraction
<poolie> it doesn't strictly do so
<lifeless> the Content objects
<poolie> yes
<poolie> also, the higher-level check code is still really thinking in terms of knits or weaves
<lifeless> ok, I'm going to commit what I have
<lifeless> because I think they are useful changes to review
<lifeless> and send in and move on
<mwhudson> LaserJock: because fastimport is pretty new, and launchpad has been doing cvs imports since 2004?
<LaserJock> mwhudson: makes sense
<lifeless> also
<mwhudson> not sure how well suited the fastimport is for syncs
<lifeless> I haven't seen anything as strict or capable as cscvs is at at handling *ongoing* fuckage of cvs
<LaserJock> ah
<lifeless> there are amazingly stupid things people can do to a live cvs repository
<mwhudson> yeah, if we can fix the file-created-by-merge bug cscvs starts to look quite good again for what it dos
<mwhudson> (and i think this bug is created by cvs changing since cscvs was written, believe it or not)
<fullermd> That's a side effect of there being amazingly stupid things people _have_ to do to a live cvs repository   :)
<lifeless> given it consists entirely of analysing breakage people *do*
<mwhudson> !cvs bashing
<ubottu> Factoid cvs bashing not found
<mwhudson> :)
<lifeless> fullermd: not true; choose to yes, have to - no
<poolie> lifeless: so this looks like a good test for 234748; do you think i should add another closer to the case where this arose?
<lifeless> poolie: uhm, my test happens to show up the bug. its a bit of a bug we don't have good tests of the behaviour on these things, neither fish nor fowl :(
<poolie> well, it's pretty close to what i had in mind, except i didn't think it'd show up through that api
<lifeless> poolie: I've committed and sent to the list my state
<lifeless> poolie: that bug actually can lead to knit corruption on knit repositories
<lifeless> (not packs though)
<lifeless> jml: if you use your patched loom
<lifeless> jml: and do 'bzr st --short' what happens?
<jml> lifeless: traceback. I guess I do need those args after all.
<lifeless> :)
<jml> and maybe a test to catch that.
<lifeless> mmm
<lifeless> no need for the test I think
<lifeless> bzr blackbox tests will exercise options
<lifeless> (bzr selftest status) with loom installed should break
<jml> hmm.
<lifeless> oh
<jml> if that's the strategy, why did I need to add a test for non-loom support?
<lifeless> also you should upddate the bzr_commands in setup.py
<lifeless> I'd like to someday have 'bzr selftest loom' use that metadata to also run blackbox tests that match those patterns from bzrlib core
<lifeless> jml: because non-loom support is an explicit case we will not cause a fragile test on
<lifeless> jml: as opposed to options from bzr itself which could change at any time
<jml> lifeless: (just clarifying) even though it's covered you think it's better to have something explicit? I'm cool with that.
<jml> lifeless: I've done all that now.
<fullermd> OK, I'm having a hard time figuring out what -Dhpss is saying, but I get two of the "does not understand protocol 3" messages when doing a pull over the smart server when I specify a URL.
<beuno> fullermd, I've been getting those for a while not with bzr.dev
<fullermd> It's not the getting them; it's the getting TWO of them.
<beuno> ah
<fullermd> (actually, I get it with a number of other commands too, but pull's the easy one to point at)
<beuno> fullermd, I get two also
<beuno> (I just checked with pull)
<beuno> I don't with push though
<beuno> from the log, it looks like one for get, and one for open
<lifeless> yay with that fix versionedfiles tests pass
<fullermd> beuno: You want to file it?
<beuno> what would be the best way to get a diff for a file between 2 revisions?
<lifeless> 'bzr diff -r x..y'
<beuno> fullermd, I don't want to take the credit  :p
<beuno> lifeless, right, I meant with bzrlib  :)
<fullermd> Well, I can't make heads or tails of -Dhpss   :|
<spiv> fullermd: that sounds like a bug in pull, we should avoid opening multiple connections when one will do.
<fullermd> merge at least did it too.
<lifeless> beuno: so do I - look at the code :P
<spiv> fullermd: feel free to pastebin the ~/.bzr.log + console output, or mail it to me.
<fullermd> I noticed on an attempt to merge --uncommitted over bzr+ssh.  Double sin-points for 2 protocol downgrades, before telling me it wouldn't work remotely anyway   :p
<spiv> fullermd: or a way to reproduce
<beuno> lifeless, lol, well, yes. I was hoping for some magical answer which would save me from half an hour of browsing through bzrlib, but I guess it's the only way to learn  :)
<fullermd> spiv: bzr init /tmp/foo ; cd /tmp/foo ; env BZR_REMOTE_PATH=bzr-1.4 bzr.dev pull bzr+ssh://localhost/tmp/foo/
<fullermd> Or 1.5, or whatever is old enough to force the downgrade.
<beuno> or just pulling from LP with bzr.dev  :)
<spiv> fullermd: ta
<spiv> fullermd: I see it, thanks!
<spiv> Ooh, three connections in fact.
<fullermd> Well, it was only one connection 'till *I* looked at it.  That moved it to 2.  Then you looked at it, and it became 3.
<fullermd> Nobody else look at it!
<lifeless> 37 errors left
<jml> lifeless: woot.
 * beuno curses loggerhead
<beuno> mwhudson, I may be wrong, but there is absolutely no easy way to get a diff for one file, with the current loggerhead code, right?  I gets *all* the files changed
<mwhudson> beuno: at some point, we should drink a very large amount of beer together
<mwhudson> beuno: that sounds entirely plausible
<rockstar> If I upgrade a parent bzr branch, is that going to break merges with the branch's children?
<mwhudson> you'll need to bend the history.History interface a bit
<mwhudson> rockstar: "depends"
<mwhudson> i think
<beuno> mwhudson, heh, I will owe you quite a few when a month in, so I'll make an effort to make that happen
<beuno> mwhudson, I'm going to add that then, I need that if I'm going to do any of the things I have in mind  (I've been going in circled cursing for the past 4 hours)
<mwhudson> ok
<mwhudson> i haven't been loggerhead-ing much today
<beuno> 30 minutes to get the ajax part sorted out, 4 hours jumping around loggerhead code and looking at many # This is a bad API, remove this eventually
<mwhudson> heh heh heh
<lifeless> aaargh backscatter time
<lifeless> rockstar: no except for the case of rich-roots
<rockstar> lifeless, pack-0.92-subtree  It's in great need of upgrading.
<lifeless> abentley: I've come around to your way of thinking w.r.t. keyspaces; the compelling argument for me is 'making pack indices regeneratable' - but the changes are all deeper than the surface stuff
<lifeless> abentley: we need to alter the knit records and up
<lifeless> rockstar: there is no more rececnt format than that
<rockstar> lifeless, more recent than pack-0.92-subtree ?  Really?
<lifeless> rockstar: there are three flavours of formats - plain, rich-root, and subtree
<lifeless> pack-0.92 is the most recent subtree format
<rockstar> lifeless, so no need to upgrade?
<abentley> I'm glad that you agree.  I'm curious about how it makes pack indices regeneratable, but I don't understand what you said afterward.
 * rockstar wonders who told him to upgrade
<lifeless> rockstar: no need
<lifeless> abentley: every record written to a pack file should have enough data to parse it and figure out what index to put it in etc
<abentley> rockstar: I recommend downgrading to rich-root-pack.
<abentley> Unless you are actually using the subtree functionality.
<abentley> lifeless: Right.
<abentley> Why do we need to alter the knit records?
<abentley> You want to store additional data in them?
<rockstar> abentley, will that break branches that need to merge back in?
<lifeless> abentley: and currently they don't :(. Anyhow, short term I think I've taken a huge step towards consistent access, but deadlines
<lifeless> abentley: yes, the knit records should store the full key
<abentley> rockstar: Not unless they're using the subtree features.
<abentley> Those features are experimental, and no one should be using them.
<abentley> lifeless: Alternatively, we could store supplemental data elsewhere.  Anyhow, I agree about deadlines.
<rockstar> abentley, alright, so I just bzr upgrade --rich-root-pack PATH_TO_REPO ?
<lifeless> abentley: storing it elsewhere makes verification harder amongst other things
<abentley> rockstar: No.  Because you're doing a downgrade that was supposed to be disallowed, you need to create a new branch and pull into it.
<rockstar> And then push that new branch with --overwrite  ?
<lifeless> upgrade --rich-root-pack may well work, because it will trigger the clone-and-copy upgrade path
<abentley> No, overwrite doesn't change format.
<lifeless> but take a backup first :P
<rockstar> lifeless, that's a given  :)
<spiv> fullermd: I've found the reconnection bug.  It's pretty trivial, I'll send a fix in a moment.
<lifeless> abentley: question for you on bundle installs - you check for presence of texts before installing...
<lifeless> abentley: it would be simpler to just add them I think, trusting to the underlying store to turn duplicates into a sha check
<abentley> lifeless: I don't think any of our current APIs allow this.
<abentley> In many contexts, an early check could avoid plenty of I/O.  But for this purpose, it would be fine.
<lifeless> abentley: thanks. in point of fact add_lines explicitly allows exact match duplicates IIRC
<abentley> Ah.  I guess I just assumed the API would match the store characteristics.
<lifeless> oh, add_lines raises RevisionAlreadyPresent
<lifeless> I'll check that that is not the cast any more
<lifeless> 19
<lifeless> (this is without reconcile tests being run :P)
<ToyKeeper> Hmm, is bzr supposed to require x11?
<lifeless> no
<ToyKeeper> It looks like bzr recommends bzrtools, which recommends graphviz.  apt-get follows those.
<lifeless> does graphviz require x?
<ToyKeeper> Yup.
<lifeless> I thought it was just a rendering library
<lifeless> anyhow, override apt :P
<ToyKeeper> Yeah, just inconvenient.  I figure I should check if it was intentional before filing a bug.  :)
<fullermd> graphviz can be built without requiring X, but I expect standard packages won't trim the options enough to do so.
<lifeless> ToyKeeper: its a weakness in dpkg
<lifeless> ToyKeeper: (I suspect)
<ToyKeeper> Of the two optional dependency types, apt treats one as a requirement and ignores the other.  I'd consider it a bug in apt, unless there's a hidden feature I'm missing.
<lifeless> ToyKeeper: its bizarre - graphviz package says that it contains the command line tools
<lifeless> ToyKeeper: and there doesn't seem to be a graphviz-nox package
<RAOF> ToyKeeper: That's a deliberate design decision - Recommends is there for packages which aren't hard dependencies, but which almost all sane people will want to use.  Thus, installing recommends-by-default is the new default.
<RAOF> ToyKeeper: "aptitude install bzr graphviz-" will, however, install bzr without graphviz (and hence x11).
<ToyKeeper> ish
<ToyKeeper> It pulls in graphviz plus all deps, then removes graphviz from the list.  So, 79 new packages instead of 80.  :)
<lifeless> ToyKeeper: thats a definite bug
<lifeless> ToyKeeper: (on aptitude)
<ToyKeeper> Oh, sorry.  That's what apt-get does.  aptitude works correctly.
<RAOF> Aptitude has had recommends-by-default for longer ;)
<poolie> spiv, are you away on friday the 13th? :)
<spiv> poolie: <insert ominous music here>
<ToyKeeper> I don't suppose there's a way to do an anonymous "bzr branch lp:foo", is there?  :)
<lifeless> ToyKeeper: exactly that will do it
<ToyKeeper> Oh, hmm.  I tried it and got a warning about logging in, then a traceback.
<lifeless> the whinging is quite annoying
 * ToyKeeper -> away
<poolie> there probably should be a way to turn it off...
<poolie> spiv: is that a yes? please don't make me go back into canonicaladmin :)
<ToyKeeper> FWIW, it was caused by a broken python2.5 package; difflib was not importable.
<poolie> oh ok
<poolie> so just local to your machine?
<TFKyle> mm, it'd be nice if launchpad people could register lp.net and have it like sourceforge has sf.net
<poolie> true
<fullermd> If only they'd thought of it 11 years ago...   :p
<spiv> poolie: yes :)
<lifeless> what the frell is it with concrete drills and epping
<lifeless> !!!!!!!!
<beuno> mwhudson, I'm off to bed. I've got most of the basics down for the diff-on-request branch, but I wasted a ton of time trying to figure out some of loggerhead (and bzr) inner workings. Hope to be able to upload the branch tomorrow (which will probably be your saturday, so I won't expect feedback)
<mwhudson> beuno: time spent learning about innards is hardly wasted
<mwhudson> beuno: i am on holiday my monday, btw
<mwhudson> though i guess that's your sunday
<beuno> mwhudson, yes, but it frustrates me when 7 hours go by, and I don't have much code to show for it  :/
<mwhudson> feel free to send me email about anything you like :)
<beuno> ah, well, that will give me more time to polish
<bimberi> lifeless: Is the railway line (to Chatswood iirc) finished?
<beuno> mwhudson, very cool, thanks. Enjoy your weekend+holiday@
<poolie> lifeless: your test doesn't actually fail in trunk afaics
<poolie> is it meant to?
<lifeless> poolie: the bundle I mailed? contains its own fix
<lifeless> bimberi: its not the source of the noise, buut no
<poolie> i applied just the test into a branch from trunk and it does not fail
<lifeless> poolie: *blink* let me check
<lifeless> poolie: bah I must have fucked it while shrinking it
<poolie> i was trying to write something based on it that would check get_lines and wondered what i was doing wrong :)
<lifeless> checking why now
<lifeless> here is why:
<lifeless> (Pdb) merge_content.text()
<lifeless> ['prelude \n', 'line']
<lifeless> (Pdb) content.text()
<lifeless> ['line\n']
<lifeless> (Pdb)
<lifeless> so I was wrong - you have to pass in left_matching_blocks to add_lines() to trigger the bug via the top level api
<lifeless> and the only thing that does that is bundles
<poolie> hm
<poolie> this sounds like a kinda different bug then
<lifeless> mwhudson: btw, is all the code import spam needed?
<lifeless> poolie: the one I pastebinned earlier definitely failed
<lifeless> I will reinstate that test
<mwhudson> lifeless: unclear, i guess
<mwhudson> it's probably not necessary for _you_ to get it :)
<lifeless> mwhudson: well, if you think about queue management, if the queue is centralised and gui managed, telling all the operators of the queue on any change is, well, overkill
<lifeless> 'queue died' is interesting
<mwhudson> lifeless: it should be a feed i guess
<lifeless> uhm, I guess I mean 'what happend to reporting exceptions' :)
<mwhudson> lifeless: thumper did all the email stuff, blame him
<mwhudson> :-p
<lifeless> thumper: this is me blaming you
<lifeless> poolie: ok, have a verified test now
<lifeless> and mailed
<lifeless> hmm, it probably wants a couple of lines trimmed, but thats minor
<lifeless> (cause I just realised I don't use the sha1)
 * spiv ducks out to the shops
<poolie> lifeless: http://pastebin.ubuntu.com/15732/
<luks> which I worked on in the pre-coding time into Picard itself.
<luks> er, sorry :)
<lifeless> poolie: http://pastebin.com/d47e68554 enjoy
<thumper> lifeless: feel free to filter it :)
<lifeless> thumper: I will but it makes seeing the wheat harder
<lifeless> night all
<slangasek> supposing that I have a pair of CVS repositories (one for upstream, one for Debian packaging) and I'd like to migrate them to bzr.  Are there any tricks available that might let me do a one-time import and merge?
<poolie> slangasek: would suggest importing them separately then merging i guess
<slangasek> poolie: if my Debian CVS repo happens to be a full-source repo rather than a debian-only repo, am I SOL on that count? :)
<poolie> are there any connections, like common tags between them?
<poolie> or are they just totally unrelated (but similar) histories?
<slangasek> I could reconcile the tags between them if that would help
<slangasek> poolie: so would that help? :)
<poolie> sorry, i don't have any good suggestions for how to merge them
<slangasek> so you were just teasing me? :)
<slangasek> well, I think I could probably get away with just ignoring the upstream repo altogether, if worst comes to worst
<slangasek> since upstream is dead :P
<enquest> my project wont update due some errors... I got two files with "RM or RN"  What do these mean?
<Pilky> enquest: I'd guess remove and rename
<spiv> enquest: see "bzr help status-flags"
<enquest> I already did that "RN  www/media/admin/js/tiny_mce => www/media/admin/js/tiny_mce.OTHER@"
<enquest> no tiny_mce.OTHER@ is there nor tiny_mce
<enquest> as I removed them
<poolie> night all
<enquest> now I get Path conflict: www/media/admin/js/tiny_mce.OTHER / www/media/admin/js/tiny_mce.OTHER
<igc> night all - have a good weekend
<dragffy> hi all
<dragffy> trying to push a branch on to launchpad but it keeps failing with an error, can anyone help please?
<dragffy> $ bzr push lp:~dragffy/grope/dev
<dragffy> bzr: ERROR: Target directory lp:~dragffy/grope/dev already exists, but does not have a valid .bzr directory. Supply --use-existing-dir to push there anyway.
<thumper> where are the archives of the bzr mailing list?
<spiv> dragffy: have you tried "bzr push --use-existing-dir lp:~dragffy/grope/dev"?
<thumper> nm, found it
<dragffy> hi spiv  i tried that, but when I looked in launchpad it still said that the branch hadn't been pushed to
<dragffy> i'm creating a new hosted branch
<thumper> dragffy: had you interrupted it before?
<thumper> I've forgotten how to run the bzr tests :(
<LarstiQ> thumper: ./bzr selftest pattern?
<thumper> LarstiQ: thanks
<thumper> dragffy: have you done a "bzr lp-login" ?
<jimcooncat> I'm having a hell of a time trying to figure this out. Is there a really easy way to get started? A mature plugin for nautilus or gedit?
<dragffy> thumper: i didn't interrupt it
<dragffy> thumper i didn't do bzr lp -login
<dragffy> thumper: but i did do:  bzr launchpad-login
<dragffy> is that ok?
<thumper> dragffy: yeah
<dragffy> i just did that the one time
<dragffy> so it seems it found me on launchpade and found my ssh key
<thumper> hmm..
<thumper> that is very strange
<dragffy> not really, i'm always unlucky!
<thumper> dragffy: how about calling bzr with -Dhpss and looking in your .bzr.log file
<dragffy> i've tried deleting the branch several times to begin again
<dragffy> thumper: i'll try
<dragffy> seems like it worked this time
<dragffy> perhaps bzr liked it if i waited
<dragffy> i mean launchpad
<jimcooncat> I have bzr-gtk installed, but no apparent nautilus integration. How to?
<dragffy> olive
<thumper> jimcooncat: sorry, I use KDE
<leroux> Was wondering if anyone can help me - I develop on my local box that doesn't have a live ip, then I use bzr rspush to push my changes to a dev server on the net somewhere. Now I made some minor changes there, committed them and merged it in to my local repository using bzr merge. But now if I try and use bzr rspush from my local box it tells me that the local branch is not a newer version of the remote branch. How can I get back to the point wh
<dragffy> thumper: kde4?
<jimcooncat> dragffy: I have olive up, but there's no help. website provides no guidance I can find
<thumper> dragffy: sometimes
<dragffy> mm yeah it's pretty new
<thumper> rspush?
<dragffy> jimcooncat: i don't know of anyway to integrate it with nautilus
<dragffy> jimcooncat: but the command line is fairly simple
<thumper> leroux: does your other machine have bzr on it?
<leroux> thumper: yes. I used it to commit my changes ;)
<thumper> leroux: did you commit the merge?
<leroux> thumper: yes..
<leroux> thumper: I've also committed afterwards locally
<leroux> thumper: see.. I want to get the changes I've made after successfully merging back onto the other machine, but can't push there now because bazaar says this version isn't newer
<thumper> leroux: I'm not familiar with rspush, is there a particular reason you are using it rather than push?
<james_w> jimcooncat: the nautilus integration is separate from bzr-gtk. The last I looked the nautilus stuff had bitrotted though.
<leroux> thumper: yes - it is much much faster and it automatically creates/updates/whatever the working copy on the remote box
<jimcooncat> james_w thanks. I have an idea for a project but no files yet, and I want to use version control. Should I write my first file first, then bzr-add?
<thumper> leroux: sorry not sure, perhaps james_w may know
<leroux> thumper: it is from bzrtools
<leroux> thumper: ok, thanks
<james_w> jimcooncat: yup, you can start with "bzr init foo" to create a branch "foo" to work in, then when you are ready to commit some work "bzr add && bzr commit"
<james_w> leroux: did you "bzr commit" locally after the "bzr merge"?
<leroux> james_w: yes. and then I made some minor changes and then I committed again
<james_w> leroux: also "bzr missing" will tell you what revisions are different on each side.
<dragffy> thumper: thanks for your help
<james_w> leroux: "bzr missing --theirs-only" needs to be empty to push.
<leroux> james_w: it says theirs is empty, mine has 4 new commits (a change I made here before merging, the merge and two minor test commits I made afterwards in an effort to get bzr to realise that yes - this is the newer one.
<james_w> leroux: strange, does "bzr push" work, or does it refuse in the same way as rspush?
<leroux> james_w: I'll check now..
<leroux> james_w: btw, could it be a time and timezone thign?
<james_w> don't think so.
<james_w> it doesn't use timestamps to figure out what's newer
<Pieter> How should I send in fixes to the bzr-fastimport thing? bugtracker, register a branch, send patches somewhere?
<james_w> Pieter: whatever is easiest for you, you can email bazaar@lists.canonical.com with [fastimport:MERGE] in the subject, or do it through launchpad.
<leroux> james_w: odd. bzr push worked. must be a bug in rspush
<leroux> james_w: how do I update the working tree manually again?
<james_w> leroux: ssh to the machine and run "bzr update" in the branch
<jimcooncat> ok, so I've got two versions of my simple hello.sh committed, "bzr log" looks good, but "bzr diff hello.sh" shows no output.
<leroux> james_w: thanks. that sorted it. hopefully after this rspush won't be confused any more.
<james_w> jimcooncat: "bzr diff" will show you differences between what you just committed and what is currently in the file, which is nothing if you haven't changed it since committing
<james_w> if you want to see the changes between the first and second version use "bzr diff -r 1..2"
<jimcooncat> james_w thanks. I might figure this out yet.
<jimcooncat> ok, now stuff is showing up in olive. thanks for the help
<james_w> no problem
<jimcooncat> one more please, to rename my file, do I just mv it, or do I have to use a bzr command?
<Pieter> How do I edit the log message of an earlier commit?
<Kinnison> IMO you don't
<Kinnison> but there may be a way
<james_w> jimcooncat: "bzr mv"
<james_w> it will move the file as well
<jimcooncat> good. olive rename feature doesn't seem to work
<james_w> if you have already moved it then doing the "bzr mv" should work it out anyway (there is an --after flag if it doesn't)
<james_w> Pieter: that's not possible.
<james_w> Pieter: if it was the last revision and you haven't pushed it yet then uncommitting and committing again will allow you to do it, but if you the revision is already public it is a bad idea.
<emgent> someone remember how to set profile on bzr?
<luks> 'profile'?
<emgent> luks: yeah, "name surname email"
<luks> bzr whoami
<emgent> cool true.
<emgent> thanks
<Pieter> james_w: yes, I know, I just want to clear up the logs before pushing them
<Pieter> Can I then export some revisions as plaintext and apply them one at a time?
<vadi2> Is it possible to get olive on windows?
<jelmer> vadi2, yes, see the wiki page for bzr-gtk
<jelmer> there's a installer linked from there
<vadi2> Found it, thank you
<vadi2> Odd question, but I don't suppose you know how to install a decent gtk theme on windows?
<jelmer> no, sorry
<Pieter> Just did my first launchpad merge proposal \o/
<james_w> Pieter: cool, thanks. How is the revision you refer to broken?
<Pieter> james_w: it crashes with bzr: ERROR: not well-formed (invalid token): line 16, column 56
<Pieter> there's a more verbose message if you try to get the revision tree
<pickscrape> Is the launchpad merge stuff really bundle buggy in disguise?
<james_w> pickscrape: not really
<james_w> though the do fulfil a similar need
<Pieter> james_w: http://bzr.pastebin.com/mea883cc
<nedosa> hi, have a question about bzr-svn
<jelmer> nedosa, hi
<nedosa> are merge-commit logs supposed to appear in the svn repo
<james_w> Pieter: I've not seen that error before, it may be a bug in the converter that was used to create the branch I guess.
<nedosa> jelmer, hi
<jelmer> nedosa: no, they're not supposed to appear unless you're viewing the repo with bzr itself
<nedosa> aaah, excellent
<jelmer> nedosa: svn can't represent merge commits
<nedosa> jelmer, so, bzr log svn://... should give me merge-commit logs
<jelmer> yes, but "svn log svn://" won't
<nedosa> jelmer, trying to atm, but can't see merge logs, is that maybe an svn 1.5 feature ?
<jelmer> nedosa: What are you trying specifically?
<nedosa> jelmer: so, i've used bzr svn-import to set up a bzr repo, then created a trunk branch off that
<nedosa> jelmer:, did a dummy commit, merged the two, then pushed the merge into the svn repo
<nedosa> now, both bzr and svn repo are in revno 607
<nedosa> but only the bzr repo display the merge-commit log message
<jelmer> nedosa: The svn repo doesn't contain the merged revision itself, only a pointer to it
<jelmer> try viewing the svn branch in "bzr viz"
<nedosa> whether i use svn or bzr for the svn repo I only get 1 commit message for that revision
<nedosa> jelmer: trying...
<nedosa>  bzr vis --limit=1  svn+ssh:// ... crashes... :(
<jelmer> does it work ok on the bzr repo?
<nedosa> jelmer: yeah, viz works great on the bzr repo
<jelmer> nedosa, please file a bug
<jam> jelmer: doing 'log' on the svn repo won't try to access the local bzr repo
<jam> so all it has is a dangling pointer
<jam> I wonder if "viz" is confused by the ghost reference
<jelmer> jam: Yeah, I know - I was just expecting bzr log to indicate ghosts
<jelmer> jam: viz does show ghosts
<nedosa> jelmer: will do
<jam> jelmer: I believe it gives a parent reference, but doesn't show a node for it
<jam> so if you have --show-ids, you'll see the parent referenced
<jam> but otherwise it hides ghosts, IIRC
<jelmer> jam: ah, ok
<nedosa> k, for reference, i sue bzr 1.5 in hardy, with bzr-svn 0.4.10
<nedosa> will file a bug
<jelmer> thanks :-)
<nedosa> jelmer: this behaviour is pretty important to us, so is this something that should be supported and is a bug, or something difficult to implement by bzr-svn ?
<jelmer> nedosa: what specific behaviour are you looking for?
<jelmer> nedosa: bzr-svn does do merge tracking
<jelmer> nedosa, but it won't push right hand side revisions into svn, just pointers to those revisions
<nedosa> jelmer: yeah, i meant merge tracking
<nedosa> jelmer: as long as a log appears, it should be sufficient
<jelmer> nedosa: to see the log for those right hand side revisions you need to fetch them from some bzr branch first
<jelmer> since they're not pushed into svn - only a pointer to them
<jelmer> e.g. you can do "bzr branch svn://repo-you-pushed-to-earlier/" on some other machine
<jelmer> and then "bzr pull url-to-your-bzr-repo" and it will fill in those right hand side revisions
<nedosa> jelmer: if I try and pull, it says there are no revisions
<nedosa> which is to be expected, since both svn and bzr repos are in sync
<vadi2> Does anyone know why would a "Authentication type (password) not permitted." be given on windows? From this log: http://pastebin.com/m1224f4de
<fullermd> Well, pretty much what it says...
<fullermd> bazaar.launchpad.net Bad authentication type (allowed_types=['publickey'])
<fullermd> LP only allows publickey auth.
<vadi2> ?
<vadi2> The ssh key was generated from the putty thing as the instructions say
<fullermd> Is it uploaded to launchpad?
<vadi2> Yes, it's set in his profile (https://launchpad.net/~dazedxjoker)
<jam> vadi2: I think you have to manually add the ssh-key to pageant
<jam> and then everything should work
<vadi2> What's that, and how?
<jam> There should be an icon in your sys tray, right click, add key, find the key you generated
<jam> and type in the password (if you gave it one)
<jam> You may need to "Start/Putty/Pageant" if it isn't already running
<jam> (I have it set to start on windows startup on my machine)
<vadi2> Ok, we got it. Thank you very much
<jam> did that work?
<vadi2> yep
<matkor> Hi ! If I want revert given commit I do: bzr merge -r <rev>..<rev_pre> ./
<matkor> What if I want revert only chnages made in one file ?
<Pilky> matkor: bzr revert <file> -r <rev>
<james_w> matkor: does it work to pass the filename to the merge command?
<james_w> otherwise you could do the merge and then "bzr revert" all the other files, but I realise that is not the easiest thing to do.
<matkor> james_w: No bzr merge refuses to get filenames as parameteres ...
<matkor> Pilky: I will have file at version <rev> ... bu I want only exclude changes made _between_  <pre_rev> and <rev> ...
<Pilky> and your current version is greater than <rev> I assume
<matkor> james_w: Not bad idea when changes are in few files ... I was thinking about bzr diff -r b..a -p1 | patch -p1
<james_w> that would work
<james_w> it's pretty much what bzr is effectively doing.
<matkor> Pilky: correct .. I am tring to remove sb mistake ...
<matkor> OK. bzr diff | patch seems to work for me- only you have to be in topmost directory in working tree :) Thanks a lot for your help
<dato> matkor: | patch -d `bzr root` ;)
<matkor> dato: ha ! I will test it next time :) Thanks to tou , too :)
<matkor> c'ya l&gs
<jelmer> Nephyrin, Ah, I think you need "bzr fetch" these days
<jelmer> nedosa, Ah, I think you need "bzr fetch" these days
<lamont> from the "not sure which manpage to look at" department: if I want a command to run every commit, how do I do that?
<beuno> lamont, post-commit-hook?
<lamont> sounds right.
<lamont> and that's documented where?
 * beuno looks
<beuno> lamont, http://doc.bazaar-vcs.org/latest/en/user-reference/bzr_man.html#hooks
<lamont> tjamls
<lamont> thanks, even
<beuno> welcome  :)
<lamont> and if I want to set the hook for the branch, rather than the user, is there a plugins directory in the branch? or just back in ~/.bazaar/plugins?
<beuno> I don't think you can set a hook for a specific branch. I may be wrong though, I haven't played with them very much.
<beuno> (no plugins per branch, that's for sure)
<dato> well
<dato> bzr-cia is per-branch
<dato> but I guess
<dato> it runs for every branch, and only acts if it's configured
<beuno> right, it's a plugin-config rather then a bzr one
<beuno> you may be able to write a plugin that runs hooks on the specified branches  :p
<fdv> Hi. I was trying to 'co' a repository from an svn repo using 'bzr co svnrepo bzrrepo', when, after a long time, bzr failed with 'bzr: ERROR: exceptions.KeyError' on a plain filename with only [a-zA-Z./]. Does anybody know why this happens (and if there is a way to work around it)?
<beuno> fdv, can you pastebin the full traceback?
<fdv> beuno: most of it, I guess :)
<fdv> http://rafb.net/p/MZ74fW96.html
<beuno> looks like a bzr-svn error
<beuno> jelmer, around?
<Jc2k> fdv: what version of bzr-svn are you using, also what version of bzr
<Jc2k> does it happen if you bzr branch svnrepo bzrrepo?
<Jc2k> also, is there a public copy of this repo so we can recreate it?
<jelmer> Yeah, I suspect this is a bug that was fixed in 0.4.10
<fdv> bzr-svn is 0.4.9-1, and bzr is 1.3.1-1
<fdv> ah
<fdv> Jc2k: unfortunately, this is a closed repo
<fdv> it's rather big, if that matters
<fdv> 1.5G
<fdv> took me about 1-1.5 hours to get to this point
<Jc2k> fdv: i converted a 2gb repo the other day ;D
<fdv> nice
<fdv> good to know it works
<Jc2k> http://bzr-mirror.gnome.org
<fdv> what's the difference between co and branch in this case?
<Jc2k> it was a guess, but jelmer is the expert
<jelmer> Jc2k: Nice, I wasn't aware of that :-)
<jelmer> Jc2k: (bzr-mirror.gnome.org)
<Jc2k> jelmer: my pet project :) its switched off right now, but i have a bot the issues a bzr pull in response to the svn-commits mailing list :)
<Jc2k> jelmer: (thats why i was interested in a speedy svn-import command :))
<fdv> beuno, Jc2k, jelmer: thanks for your help, I'll try with a newer bzr-svn
<jelmer> Jc2k: (-:
<Jc2k> jelmer: speaking of which i have a log...
<jelmer> Jc2k: What sort of log?
<fullermd> It's big, it's heavy, it's wood.
<Jc2k> jelmer: we were talking about bzr svn-import taking a long time to "top up" and existing clone of an svn repo
<Jc2k> jelmer: you asked for -Dtransport
<jelmer> Jc2k, ah, right
<jelmer> Jc2k, can you mail it to me? I'm heading out in a few minutes
<Jc2k> sure
<beuno> fullermd, Canonical should hire you just to stick around and comment, this is (odd, I know) the channel that makes me laugh the most
<fullermd> If you actually find my randomness funny, that should seriously worry you about your mental state   ;)
<fdv> jelmer: I still get the keyerror using 4.10 :p
<fdv> do I need to delete the cache or something?
<Jc2k> fdv: try bumping your bzr version as well
<fdv> Jc2k: I did, had to :)
<fdv> bzr-svn required >= 1.4
<fdv> I'm running 1.5 now
<Jc2k> ah, nm then ;D
<fdv> :)
<beuno> fullermd, well, I'd rather not go into details and enjoy it  :p
<nekohayo> hey there, I have some silly questions for you folks :)
<nekohayo> 1) is merging at the same time as other changes a bad idea?
<nekohayo> 2) what about merging and changing some of the lines that came from the merge?
<nekohayo> will these kind of actions break/corrupt history, or create a spatiotemporal void that will suck in anything in a radius of 30 km?
<pickscrape> Make sure you don't commit any anticode.
<statik> nekohayo, changing lines after the merge and before committing is fine. it's a great time to run tests and fix any code that did not merge correctly
<statik> nekohayo, i think it's better to commit or shelve any local changes that you have before merging in new stuff though
<nekohayo> statik: what do you mean by shelve?
<statik> nekohayo, the bzrtools plugin has a shelve command which allows you to set aside uncommitted changes
<nekohayo> statik: and won't changing lines right after merging (but before committing the merge) corrupt the thing, spurring conflicts all the time when you merge in other directions?
<beuno> nekohayo, not at all, I do that all the time. In fact, it's a requisite to solve conflicts
<fullermd> Now that said, I generally restrict myself to doing the minimum necessary to clean up conflicts right after merges.  Most of the times I've done more, I've wished later I did them in another rev.
<beuno> right, that's a better practice
<beuno> but doing so won't raise hell, if that's what you where aiming at
<fdv> hm. now it seems the co from svn comes further (with bzr 1.5 and bzr-svn 0.4.10), but there seems to be a bug somewhere as memory is just consumed, very quickly, until it's depleted the box' resources
<fdv> I'd think 2G memory and 3G swap should be enough :p
<Jc2k> fdv: there is a leak in the subversion python bindings
<Jc2k> fdv: what distro you running?
<Jc2k> (i have a deb for etch i could throw you)
<fdv> Jc2k: hardy heron
<Jc2k> really, wow...
<fdv> ?
<fdv> how's that wow? :)
<Jc2k> fdv: hardy has the fix.. that might even have been were i robbed the diff from when making my custom etch deb
<fdv> I guess it's the most mainstream distro around these days ;)
<Jc2k> fdv: so the wow was oh god, whats leaking now ;D
<fdv> aw
<fdv> hm..
<jelmer> I haven't backported all memory leak fixes from svn 1.5 into the hardy package
<fdv> I guess running this under valgrind would bring my box to a grinding halt...
<Jc2k> :) you really need to try subversion 1.5 if you want this right now..
<fdv> :p
<Jc2k> i wonder if it will play nice under jhbuild..
<fdv> is it unproblematic to run a 1.5 client against a 1.4 repo?
<fdv> guess so
<Jc2k> actually no, its build to allow that
<Jc2k> *built
<fdv> I hust remember having some issues in an early version with a local copy worked with with a newer version, after which the previous wouldn't work
<fdv> but that's of course locally
 * Jc2k tries to find a subversion 1.5 download to set up a jhbuild cage
<fdv> I still get the keyerror exception.. :p
<fdv> even after removing svn-cache
<fdv> jelmer: any ideas?
#bzr 2008-05-31
<lifeless> fdv: So svn has multiple disk formats like most vcs's, but unlike bzr it silently upgrades on you - which is why you couldn't use the older client after using the newer one
<rockstar> Anyone know why I would be getting "ValueError: I/O operation on closed file" while trying to branch from a launchpad branch?
<jam> rockstar: that is usually a secondary error
<jam> it means we are doing something like 'flush()' on a closed file
<jam> usually we get that after something else has gone wrong
<rockstar> jam, seems like I'm getting it trying to branch from all lp branches.  A friend of mine is having the same problem.
<jam> rockstar: what version of bzr, and what platform?
<rockstar> 1.5, on linux.
<rockstar> It's the same system I have launchpad.dev on
<jam> rockstar: have you tried running with '--no-plugins' to see if that fixes it?
<m3ga> ping lifeless
<lamalex> Hey pals, I'm having problems pushing to my LP branch
<beuno> lamalex, specifics?
<lamalex> LP has to use bzr push lp:~alexlauni/do/do-alauni, but that doesn't work due the http mkdir() erro
<lamalex> so I'm trying to do bzr push sftp://bazaar.launchpad.net/~alexlauni/do/do-alauni/
<beuno> lamalex, bzr launchpad-login yourlpid
<beuno> that will set it to use bzr+ssh
<lamalex> that's a beautiful thing
<beuno> ain't it?
<lamalex> now i have bzr: ERROR: Target directory lp:~alexlauni/do/do-alauni already exists, but does not have a valid .bzr directory. Supply --use-existing-dir to push there anyway
<lamalex> should I just use that switch?
<beuno> uhm, that's odd, but yes
<lamalex> heh
<lamalex> it's pushing. we
<lamalex> 'll see how it gos
<beuno> :)
<beuno> you're using bzr 1.3, right?
<lamalex> indeed
<lamalex> 1.3.1
<beuno> I believe newer versions do a better job at warning you about pushing without a lp-login set
<lamalex> are they in the bzr ppa?
<beuno> I'd recommend updating from the PPA (https://launchpad.net/~bzr/+archive)
<beuno> :)
<lamalex> :) great minds right?
<beuno> heheh, right
<dennda> Hi. I try to bzr ignore a Django settings.py file. I got this django project on several machines and the settings.py differs slightly on each host. I still want it to be version controlled per host but I don't want to sync it between the hosts. (And if that is not possible, just plain ignore it completely)
<dennda> However, bzr ignore settings.py gives me this:
<dennda> Warning: the following files are version controlled and match your ignore pattern:
<dennda> olympic/settings.py
<Peng> dennda: You're already versioning settings.py, so ignoring it does nothing.
<dennda> Peng: So how do I keep the file but disable versioning for it?
<Peng> dennda: You can't.
<Peng> dennda: You could commit to a separate branch with a default settings.py, then "bzr merge" it into each machine's branch.
<dennda> Ok what about removing the file with bzr remove, creating it again and ignoring it?
<dennda> I commit early and often, that'd just be a pain
<Peng> dennda: Sure, you could do that.
<dennda> Then I will
<dennda> brb, breakfast :)
<bob2> dennda: bzr rm --keep settings.py
<dennda> thanks bob2 and Peng. I hope it worked
<dennda> bob2: I did that locally, committed and pushed to a remote branch where it deleted not only the version control but the file itself, too!
<luks> bzr doesn't modify remote working trees
<luks> if you have a checkout there, you need to `bzr update`
<luks> er, wait
<luks> ignore the second line :)
<luks> it couldn't remove the file, because it doesn't touch remote working trees
<dennda> I did update and the file was gone
<luks> I think update would remove it only if it's identical to the versioned version
<luks> so bzr revert -r X settings.py
<Arby> I'm having a problem pushing to a branch. bzr push returns ERROR: Cannot lock LockDir(http://bazaar.launchpad.net/%7Ekubuntu-users/jockey/jockey-kde/.bzr/branch/lock): Transport operation not possible: http does not support mkdir()
<Arby> this seems to be a case of bug 156462
<ubottu> Launchpad bug 156462 in bzr ""cannot lock LockDir" on update over http" [Undecided,New] https://launchpad.net/bugs/156462
<Arby> I've tried all the things suggested in that thread
<Arby> without success
<Arby> can anyone suggest what I'm doing wrong
<luks> you can't push over http
<luks> either use sftp: or bzr+ssh: link, or bzr launchpad-login and then lp: link
<Arby> I've tried sftp and bzr+ssh both fail with Permission denied (publickey).
<Arby> but I do have a public key on launchpad
<Arby> I even tried to upload it again just to be sure
<luks> does 'sftp bazaar.launchpad.net' work?
<mwhudson> is it the same one as one the machine you're trying on? :)
<Arby> mwhudson: yes
<mwhudson> could this be a username issue?
<Arby> luks checking
<mwhudson> actually, i bet that's it
<Arby> luks: no it doesn't
<Arby> mwhudson: what is?
<mwhudson> Arby: what's your launchpad id?
<Arby> rbirnie
<mwhudson> does 'sftp rbirnie@bazaar.launchpad.net' work?
<Arby> checking
<Arby> mwhudson: yes it does
<mwhudson> Arby: cool
<Arby> so because my user id isn't the same as the owner of the branch it fails?
<luks> no, it's because your local username is not the same as your launchpad id
<Arby> although I joined the team that owns the branch
<Arby> ah ok
<mwhudson> this doesn't really have much to do with launchpad
<Arby> so what is the solution?
<luks> bzr push bzr+ssh://rbirnie@bazaar... should work
<Arby> trying
<Arby> victory :)
<Arby> is there a setting somewhere to prevent this happening in future?
<luks> .ssh/config
<luks> bzr launchpad-login and then use only lp: urls
<Arby> luks: sorry I don't understand. .ssh/config doesn't exist
<Arby> on this machine
<luks> create it, and add this:
<luks> host bazaar.launchpad.net
<luks>     User rbirnie
<luks> (.ssh/config is supposed to be ~/.ssh/config, just to be clear :))
<Arby> ok, thanks for the help :)
 * mwhudson attempts to be a mere user of launchpad, and fails
<mwhudson> spiv, jml: here?
<mwhudson> oh never mind
<philipp_> `bzr: ERROR: Transport error: Server refuses to fullfil the request` what does this mean? tried to do `bzr branch http://bzr.debian.org/apt/debian-sid apt-debian-sid`
<dato> philipp_: try bzr branch nosmart+http:://bzr.debian.org/...
<philipp_> k, this works, thanks
<philipp_> hm, this isn't documented in the man page
<dato> philipp_: maybe/probably because it's a bug in bzr
<philipp_> http://paste.debian.net/4760/ as is this?
<dato> philipp_: no, not that; you can't checkout over a read-only transport.
<philipp_> k, but a simple error message would be nice ;-)
<RainCT> Hi
<RainCT> Can someone help me? I'm getting this error: https://code.edge.launchpad.net/~revu-hackers/revu/trunk/ and I can't get it to work on LP in any way, but locally it works
<RainCT> (the guys in #launchpad couldn't help :()
<Peng> RainCT: Tried pushing over sftp?
<RainCT> Peng: yes
<RainCT> Peng: and also to lp:~rainct/+junk/test
<Peng> ...And he's also tried with bzr 1.3.1 and 1.5. Launchpad is still on 1.3, of course.
<RainCT> Peng: uhm.. weekend? :P
<Peng> RainCT: Yeah. Star Trek is on TV today!
<RainCT> Peng: heh. where?
<Peng> RainCT: Central Florida, U.S., North America, Earth, ... Local CW affiliate.
<Peng> RainCT: It's Star Trek TOS.
<RainCT> ah, thought it might be on german tv (as your surname is german) :P
<Peng> It is? I thought it was Scandinavian.
 * Peng shrugs.
<RainCT> heh well might be :P
<RainCT> s/is/looks ;)
<Peng> What's it mean in German?
<RainCT> Peng: Dunno, it might pretty well be Scandinavian :P. Â«NordÂ» is Â«NorthÂ» and about Â«hoffÂ» I'm not sure, Firefox says that it's correct but I don't know what it means (I first thought it's Â«courtyardÂ» but that's Â«hofÂ»)
<Peng> RainCT: I think it's supposed to mean "north house". http://www.answers.com/topic/nordhoff says it's North? German, "from Middle Low German nord- ânorthâ + hof âfarmsteadâ, âmanor farmâ".
<RainCT> ah, I was right then :)
<Peng> :)
<bjdooks> I'm trying a bzr push, using sftp, but after it asks for my password it just hanfs there and doesn't seem to be doing anything. anyone help?
<Peng> bjdooks: You're sure it's not just slow?
<bjdooks> ah, it just bombed out with a  Could not acquire lock LockDir(
<bjdooks> hmm, how do I clean out the lock?
<RainCT> bjdooks: bzr break-lock <branch url>
<RainCT> (where <branch url> is sftp://..., bzr+ssh:// or lp:...)
<bjdooks> right
<bjdooks> held by ben@ivanova on host ivanova [process #19691]
<bjdooks> locked 1731 hours, 31 minutes ago? [y/n]: y
<bjdooks> ffs, Could not acquire lock LockDir again
<bjdooks> hmm, deleting .bzr/repository/lock/held worked
<Peng> bjdooks: 1731 hours ago? You sure it's not still being used? ;)
<bjdooks> Peng: i think it was a failed session, my laptop doesn't usually get to stay on that long
<bjdooks> right, now to work out what completely broke sftp support on my desktop
<bjdooks> bzr: ERROR: exceptions.AttributeError: 'SSHSubprocess' object has no attribute 'get_name'
<Peng> bjdooks: That's been fixed.
<Peng> bjdooks: A recent release of Paramiko (1.7.3?) changed the API a bit, I think.
 * bjdooks wonders if debian has caught up yet
<bjdooks> hmm, downloading 65.6MB of updates...
<bjdooks> so far I like bzr far more than git
<Peng> 65.6 MB of updates to what?
<bjdooks> my debian machine... looks like that's fixed bzr
<beuno> hrm, more people seem to be getting "ValueError: I/O operation on closed file
<beuno> on LP...
<Peng> Yeah, on sys.stdout.
<beuno> Peng, any idea what triggers it?
<Peng> beuno: Writing to sys.stdout after it's been closed.
<Peng> Or, doing any other I/O operation, I suppose.
<RoAkSoAx> beuno, ok
<beuno> Peng, http://pastebin.ubuntu.com/16005/
<beuno> and http://pastebin.ubuntu.com/16006/
<RoAkSoAx> beuno, if you need more info, i just upgrade my system to the latest upgrades available for HH
<RoAkSoAx> including the upgrade fixing the ssh key vulnerabilities
<beuno> RoAkSoAx, could you try the checkout again, but with  --no-plugins?
<Peng> The warning and error are coming from the server.
<Peng> The client's plugins are irrelevant.
<beuno> yeah, which is odd considering it's LP
<Peng> I'm pretty sure that area of the code has been changed since 1.3.
<beuno> rockstar had the same error yesterday
<Peng> Like, the warning was removed, which would make the error go away.
<Peng> LP will upgrade their bzr installation soon.
<Peng> Anyway, I was gonna go 5 minutes ago.
<beuno> RoAkSoAx, can you try "bzr branch" instead of checkout?
<beuno> Peng, thanks  :)
<Peng> beuno: I got the same thing on a "bzr branch", but I thought it was because the branch is broken.
<RoAkSoAx> beuno, ok i will
<RoAkSoAx> same thing
<RainCT> <persia> I found it worked for me with http pull and bzr+ssh push, although it took a couple  tries.
<RoAkSoAx> http://pastebin.ubuntu.com/16053/
<RainCT> (persia, sistpoty and me have the same problem from paste 16005)
<beuno> ah, right, should would work
<Peng> The server-side forgot to unlock something, and a warning was emitted and it was automatically unlocked when it was garbage collected (which isn't done it anymore), but stdio had already been closed, so it tracebacked.
 * Peng wanders off.
<beuno> RoAkSoAx, bzr branch http://bazaar.launchpad.net/~planet-ubuntu/config/main planet-ubuntu
<RoAkSoAx> beuno, seems to be working now
<beuno> RoAkSoAx, good, you should be able to push back with bzr+ssh
<RoAkSoAx> ok thanks beuno :)
<beuno> RoAkSoAx, thank persia  :)
 * beuno reports the bug
<RoAkSoAx> beuno, how should i push it, bzr push bzr+ssh://yourusername@bazaar.launchpad.net/~planet-ubuntu/config/main  instead of doing a bzr commit?
<beuno> RoAkSoAx, you should commit first
<beuno> then, yes, exactly like that
<RoAkSoAx> ok thanks;)
<beuno> RoAkSoAx, np
<beuno> RoAkSoAx, bug #236380
<RoAkSoAx> beuno, ok cool ;)
<pygi> poolie, you around?
<Peng> push --remember so that you don't need to specify it.
<Peng> It's also good to pull over bzr+ssh...
<RoAkSoAx> beuno, http://pastebin.ubuntu.com/16058/
<RoAkSoAx> RainCT, how did you push to planet, somthing like this:  bzr push bzr+ssh://andreserl@bazaar.launchpad.net/~planet-ubuntu/config/main
<beuno> RoAkSoAx, try again
<RainCT> RoAkSoAx: I have the problems with another branch, but yes, that should be right
<RoAkSoAx> ok thanks guys :), really appreciate it :D
<beuno> RoAkSoAx, I was reconciling the branch to see if there where any problems
<RoAkSoAx> beuno, ok ;), it worked now thanks
<RoAkSoAx> well, thanks guys, I'm going to watch the Spain - PerÃº soccer match, bye all :)
<PriceChild> Hey there, this is a support channel, not just development right?
<beuno> PriceChild, yeap yeap
<PriceChild> Great :D Well I'm wondering whether this error: http://pastebin.ubuntu.com/16068/ is something I should be asking you guys for help with, or canonical to fix with launchpad? I am using 1.5.0-1~bazaar1~hardy1 from the bzr ppa on launchpad.net
<beuno> PriceChild, I reported that error a while ago, bug #236380
<beuno> it's a problem with bzr on LP
<beuno> the current workaround I can give you, is branch over http, and then push bzr bzr+ssh
<PriceChild> Thanks beuno. I upgraded to that ppa version because the one in hardy didn't work which was annoying.
<beuno> yeah, LP is still on 1.3, which might be what is triggering that bug
<RainCT> good night
<emgent> heya
<PriceChild> beuno: ok so i branched it, how do i commit it back to the right place? if i do bzr commit -m "message" it gets commited to the directory its in atm :)
<beuno> PriceChild, right, now that you've committed, you have to push your changes back with:  bzr push location
<beuno> (in location, use bzr+ssh URL)
<PriceChild> great, thanks
<beuno> PriceChild, you're welcome  :)
<PriceChild> *crosses fingers*
<PriceChild> tis looking good...
<pygi> PriceChild, you bugging people again? :D
<PriceChild> pygi: you know what I'm like :D
<PriceChild> launchpad is weird, said i pushed 29 minutes ago. *waits for planet.ubuntu/com to get updated*
<Daviey> PriceChild: you changed your head?
<Daviey> maybe your browser is caching the old one, i'm seeing a newish one
<beuno> PriceChild, the planet gets updated via a cronjob, so expect it to take a while
<PriceChild> Daviey: supposedly can take 2 hours to update
<PriceChild> what he said
<pygi> PriceChild, haven't I told you that having your head scrambled is a bad thing? :P
<PriceChild> Yay all done, thanks again beuno!
<beuno> PriceChild, :)
<PriceChild> pygi: shh :P
<pygi> PriceChild, it is rude to shhh people!
#bzr 2008-06-01
<nDuff> I was just talking to a git user who indicated he was turned off by bzr's branches-as-directories model. I'm curious -- has an alternate approach been introduced since I was last current, or is that still the only branching model from a UI perspective?
<Kamping_Kaiser> i think its the same
<sabdfl> nDuff: you can work differently, if you prefer
<sabdfl> you can have a shared repo which has all the revisions for all of your branches
<sabdfl> and "treeless" branches inside that. those are subdirectories, but just include the branch info, so they are basically invisible
<sabdfl> then, you can have a single checkout of one of the branches somewhere, which is where you work
<sabdfl> and you can "switch" that checkout from branch to branch
<sabdfl> when you switch, the working directory gets changed to reflect the tip of the branch you just switched to
<sabdfl> and then when you commit, the new revision goes into the shared repository, and metadata for it is added to the branch you are working on
<sabdfl> does that make sense? shout if i have not explained it well
<sabdfl> but this is one of the beauties of bzr - the pieces are orthogonal, so you can have a workflow that suits you
<sabdfl> much more easily than any of the other dvcs'
<cammoblammo> Umm, sabdfl, nDuff posted that abut eight hours ago. It's a pretty good explanation though, and I found it quite useful!
<sabdfl> cammoblammo: thank you! he's still logged in as nDuff so perhaps he'll spot the response later
<cammoblammo> ;-)
<timely> hello world
<timely> can someone help me get lost in bzr documentation?
<timely> alternatively, can i edit the bzr wiki w/o some magical bits?
<sabdfl> timely: you can easily do both, i think
<sabdfl> are you wanting to contribute to the docs or the wiki?
<timely> i don't really want to do either. but there are grammatical errors on http://bazaar-vcs.org/Integrating_with_Bazaar so i figure if it doesn't require lots of effort, i'm willing to make a wiki account to make some changes
<timely> i'm trying to write some perl based integration to 'dead bzr trees'
<timely> i.e. a file system copy of a bzr repository (where there may or may not be a valid or useful instance of bzr installed)
<timely> mostly, i need to be able to figure out how to generate links to what i guess is bzr web
<timely> although i have no idea what its formal name is
<timely> probably loggerhead actually, i guess
<timely> nice (503) http://www.lag.net/branches/loggerhead/loggerhead_dev/
<timely> (empty) http://www.lag.net/robey/code/loggerhead/
 * timely sighs
<TFKyle> timely: might want to look at the branches on launchpad
<timely> i
<timely> 'm there
<timely> i'm quite lost
<timely> all i want to know is
<timely> given (.bzr/*, path/filename) how to calculate a url for a "log view" pinned to path/filename for the version controlled by .bzr/* and an annotation view for the same
<timely> i do not intend to read 1000 branches of a project just to figure out there's no useful documentation :)
<timely> https://bugs.edge.launchpad.net/launchpad-bazaar/+bug/98826 seems to be what i want
<timely> although i can't figure out if the loggerhead i have available supports it
<timely> certainly the one i'm talking to is generating the other url format... which is amazingly unhelpful :(
<timely> anyway... do i need to do more than simply create a wiki account to edit that first url?
<timely> if not, i'll create an account and change it. otherwise, i'll stop considering
<timely> https://code.launchpad.net/loggerhead it says You can _browse the source code _for ...
<timely> is that part of loggerhead's content or is that launchpad itself being clever?
<jml> timely: the link from code.launchpad.net is generated by Launchpad.
<jml> timely: but maybe I'm misunderstanding the question?
<timely> the space after 'code' is underlined as part of the link
<timely> one doesn't typically do that. it's an error in the html
<jml> timely: right. that's a bug.
<timely> either because someone left a space in raw html, an input field, or in the generator
<timely> but i need to know which  :)
<jml> timely: I'm not sure why you need to know.
<timely> i only want to send one report to the right team :), but i will report it :)
<jml> timely: oh I can file the bug.
<timely> ok :)
<jml> timely: I'm on the relevant team :)
<jml> timely: https://bugs.launchpad.net/launchpad-bazaar/+bug/236452
<timely> :)
<timely> ok, so http://bazaar-vcs.org/Integrating_with_Bazaar Committing Changes
<timely> To commit only certain files, we need to provide a list of filenames which we want committing, eg:
<timely> should be  "we want committed" or "we want to commit"
<timely> fwiw, "e.g." should be spelled w/ <period>s (always)
<jml> timely: you should just be able to edit the wiki page.
<jml> timely: and yes I agree with both of your points.
 * timely tries to create an account
<timely> gah
<timely> oh brother
<timely> if i error in changing the wiki page, it clears all my changes and says "please specify a password"
<timely> how helpful...
 * timely tries to figure out what to make of "spread over itself"
<timely> it sounds like a harlot
<timely> distributed between itself (?)
<timely> Removing Files
<timely> You can remove multiple files at once.
<timely> what does "at once" mean?
<timely> does it mean "together" or "immediately"?
<jml> together.
<timely> originally i assumed the latter, but.. thanks
<jml> "at the same time"
<timely> should i take a lock on this url so that i don't collide with anyone else? :)
<jml> keep hitting preview.
<timely> i'm using TextEdit.app because my browser sucks :)
<jml> "This gives us a WorkingTree object, which has various methods spread over itself, and its parent classes MutableTree and Tree" could be rephrased to:
<timely> note that there's an instance of "its" that should be "it's" somewhere nearby (already fixed locally)
<timely> (this page clearly wasn't written by someone who cares about English :)
<jml> "This gives us a WorkingTree object, which has methods provided by itself and by its parent classes: MutableTree and Tree."
<timely> sold
<timely> You can rename one file to a different name
<timely> ... can i rename one file to the same name ? :~(
<jml> "You can change the name of a single file"
<timely> thanks
<timely> sorry, it's a lot easier for me to spot bugs than come up w/ proper fixes :(
<jml> timely: btw, looking at the changelog for the page, lots of changes are made by people who don't speak English as their first language.
<timely> fwiw, the document isn't sure if it's speaking in second or first person plural
<timely> (you can, we)
<timely> if you have a preference ...
<jml> timely: I'd default to "you", but just pick whatever you think is best.
<timely> you sounds fine, i'll do that later
<timely> active voice i presume?
<timely> actually,
 * timely goes back and start attacking we's
<jml> timely: standardizing on voice doesn't bother me so much. who cares as long as it sounds good.
<jml> but sure, active works.
<timely> gah.. note to self, watch out for misuse of a(n)
<timely> will preview tell me if i hit a conflict? :)
<timely> IMPORTANT: This should be avoided wherever possible, as it scales with the
<timely> length of history::
<timely> "scales" ... alternative suggestion? typically people think of "scales" as a positive thing
<timely> http://bazaar-vcs.org/Integrating_with_Bazaar?action=diff&rev2=34&rev1=33
<timely> i hope that's not too bad
<timely> sadly it doesn't really help me w/ my original problem... but :)
<timely> eww, loggerhead actually requires its own webserver?
<jml> timely: re 'scales': there's not enough info to suggest a replacement.
<jml> timely: "the time/memory/bandwidth this takes increases proportionally to the length of history."
<jml> timely: I don't know which one.
<jml> timely: re loggerhead: it runs it's own webserver but you don't have to present it to the wold
<jml> world, rather.
<jml> you can use Apache's ProxyPass features.
<timely> context was the performance behavior of "branch.revision_history()"
<timely> can it actually be bandwidth? i.e. could i be talking to a remote bzr?
<timely> increases proportionally is indeed better
<jml> timely: you definitely could be talking to a remote repository.
<jml> timely: branch = Branch.open('http://example.com/some/branch') works just fine.
<timely> so i guess i should copy your entire string... ok, when i'm done figuring out which bzrs i actually have locally, i'll worry about that
<jml> timely: oh that reminds me.
<jml> timely: using Python to interact with Bazaar will be faster, easier and more flexible than using Perl.
<timely> that's nice
<timely> sadly, this is just support for an existing tool
<jml> timely: I just thought I'd mention it :)
<timely> and i'm not going to teach myself python just to integrate with one vcs
<timely> which i will use almost never
 * timely nods
<sabdfl> timely: fwiw, you can use Bzr with most VCS's, if that makes it worth learning more Python
<timely> no
<timely> :)
<timely> for my day job, i use c++/js
<sabdfl> and which vcs there?
<timely> in my free time, i work on a fairly old and relatively stable tool (mxr.mozilla.org)
<timely> well, at times it's using hg, or git, or cvs, or svn, or bzr, or non vcs'd stuff
<timely> i think i have trees from p4
<timely> and typically the integration hooks aren't things that are really known or usefully knowable from most tools
<timely> since it's "where's your web ui" "how do i ask for blame" "how do i ask for log"
<timely> those are rarely usefully standardized (if ever)
<sabdfl> true
<timely> heck, in a lot of cases there's no link between the vcs and the web ui at all :0
<timely> as for pull commands, my standard cases don't use simple pulls
<timely> they use complicated (or very complicated) checkout scripts
<timely> sorry... i'm the edge case... i know most people do benefit from such hints...
<pygi> ok, quick question folks
<pygi> bzr: ERROR: Cannot lock LockDir(http://bazaar.launchpad.net/%7Elibburnia-team/libisofs/mainline/.bzr/repository/lock): Transport operation not possible: http does not support mkdir()
<pygi> when I try to push to lp:libisofs
<pygi> I also tried lp:///libisofs
<beuno> pygi, you need to run:  bzr launchpad-login username
<beuno> it's defaulting to http as you haven't set up a username  :)
 * timely presumes it needs  https
<sabdfl> it will switch to bzr+ssh when you have logged in, assuming you've setup an ssh key
<beuno> AFAIK, bzr 1.5 does a better job at explaining this. Are you using 1.3, pygi?
<pygi> beuno, on this machine, yes :)
 * sabdfl thinks we should push bzr 2.0 out to stable distros when it's baked
<pygi> sabdfl, beuno : thanks ;)
<beuno> sabdfl, at this rate, it sould be able to get into Lenny, and, well, I presume you'll be able to get it into Hardy as well  :)
<gour> pygi: opet se sreÄemo ;)
<pygi> gour, hehe :)
<timely> can i ask questions about loggerhead here? (again, i don't speak python)
<pygi> timely, you can try :)
<jml> timely: yeah, this is the best channel for loggerhead questions.
<timely> i read the README and made a loggerhead.conf
<timely> i did not run make because the README made no mention of it
<gour> pygi: kupih samsunga 204...prÅ¾i sve u 16. stara prÅ¾ilica mi izderala par cd/dvd-a
<timely> it did say to run start-loggerhead
<timely> File "./start-loggerhead.py", line 3, in ? ... ImportError: No module named pkg_resources
<pygi> sudo apt-get install python-pkg-resources ? :)
<timely> i don't own this computer (i never own computers), i did not configure or install bzr (although some random unknown version is installed), there are many random (unspecified/unknown) versions of python here
<timely> no :)
<beuno> timely, loggerhead has a set of dependencies which aren't very clearly layed out. You need turbogears and sqlite to start with
<beuno> let me check what else
<timely> keep in mind what i said. i don't own this box. that means i'm not and can not be root :)
<beuno> timely, ah, that may be a problem then  :)
<sabdfl> timely: then ask your admin to pop in here?
<timely> i'm not specifying the linux distribution (it is linux)
<timely> in general when things are installed by the admin, they make things worse, not better :)
<timely> so, if there are instructions for local install, i'll follow them :)
<timely> it's 2am, i'd hope he's sleeping :)
<beuno> timely, well, loggerhead is complicated enough to get working with root access, I suspect that with just local install, it may prove to be a challenge
<timely> ...
<beuno> we'de really like to trim down dependencies for it, but it currently has a set of performance issues which are more pressing
<timely> note: if i actually could get the admin here, i could just ask him to upgrade his loggerhead install :)
<timely> in which case... why would i bother setting it up in the first place? :)
<timely> also... something that needs root access doesn't exactly inspire trust :)
<pygi> beuno, he could install py and all the deps in   his home dir
<timely> [timeless@landfill mxr-test]$ which hg
<beuno> timely, there is another web interface for bzr: http://bazaar-vcs.org/WebInterface
<timely>  /home/timeless/bin/hg
<beuno> http://goffredo-baroncelli.homelinux.net/bazaar
<timely> beuno: ... the point of this is to integrate w/ existing things...
<timely> i suppose i could setup that one just to integrate w/ it
<beuno> it's basically a plugin for bzr, so it should work pretty much out of the box
<timely> but my target is integrating http://mxr-test.landfill.bugzilla.org/bugzilla-bzr/source/ with http://bzr.everythingsolved.com/bugzilla/trunk/changes
<beuno> interesting
<timely> otoh, there's also bugzillamozilla-bzr which doesn't seem to have any web ui
<timely> so i suppose i can simply run WebInterface for that and integrate w/ it first
<beuno> timely, there is some work going on in Loggerhead (I've been doing lots of it these past weeks), so it should be looking better very soon
<timely> maybe i should leave an email address and you can ping me when i should look again..
<timely> i was getting annoyed w/ hg and decided i'd look to see how hard integrating bzr would be
<timely> it doesn't seem promising :)
<beuno> timely, well, bzr does have an xml-output plugin, which is commonly used to integrate into different external tools
 * jml is going offline.
<timely> http://mxr-test.landfill.bugzilla.org/mozilla-central/source/xpcom/Makefile.in
<beuno> maybe that is worth looking at
<jml> timely: good luck with the integration.
<timely> the integration for hg is basically the "HG Log" and "HG Blame" links at the top
<timely> jml: thanks
<timely> beuno: how many output flavors does the plugin generate?
<timely> so far i've seen 2 different .bzr formats
<timely> and i have no faith in xml flavors
<timely> (i've also seen and support 2 .svn formats)
<beuno> timely, it doesn't relate to bzr's format, it works on a higher level
<timely> yes, but have you *changed* the xml it generates?
<timely> and will you change it *again*?
<timely> the wonderful thing about xml is that no one seems to care about not breaking compatibility
<timely> just like internal repo formats
<beuno> timely, it hasn't in at least 8 months, and, it's commonly used, so we're *very* careful not to
<timely> 8months? hah
<timely> the projects i work on are 10+years old :)
<timely> things that only change every 8months....
<timely> that'd set me back years :)
<beuno> I've been using it for over a year in integrating into a PHP aplication, and the Eclipse integration uses it too
<timely> but yeah, i understand... and if every month you say it hasn't changed in 8+n months, then eventually that's a good thing :)
<beuno> timely, well, the plugin is barely over a year old, so...
<timely> sorry, i'm jaded...
<beuno> heh
<beuno> you can always *not* upgrade and keep using the same format
<timely> nope
<timely> i don't control what other people use
<timely> i'm a middle person
<timely> if someone tries to use my tool, they'll use it w/ whichever version of other tools their distro provides
<timely> which on average will be *different* from the one i picked
<timely> and no. i don't want someone forking mxr
<timely> there are already way too many forks of lxr, thank you very much :)
<beuno> alright, well, what can we do to help you?
<timely> well... do most of these web uis accept the "global repo version" for any file path?
<timely> (minus the ones that seem to require some private id instead of a file path)
<timely> if so, how do i get that?
<timely> i really suspect all i need is that one identifier
<timely> (and a non sucky version of loggerhead, which seems to be something i'll have to sleep on)
<beuno> well, it uses file_ids, but it wouldn't be too hard for it to accept paths as well
<LarstiQ> which gets fun with history viewing, the path in _this_ version, or in _that_ version?
<timely> https://bugs.edge.launchpad.net/launchpad-bazaar/+bug/98826
<timely> LarstiQ: why is it fun?
<timely> i only ever have a single version of the repo in front of me
<beuno> if you'd like, you can drop me an email (or, to the public bzr list), with what you need, and I can try and fit it in
<beuno> LarstiQ, I think he just wants HEAD
<timely> a user says "<file here>" "<show me log> for it"
<timely> i'm not sure it's necessarily head
<timely> although i don't want to look up your definition of HEAD
<timely> but i can assure you that the repo will be in a state so whichever it is, the repo will know
<LarstiQ> timely: I don't know how mxr works, does it not do any navigating in history at all?
<timely> correct
<timely> it merely links to someone else who provides that
<timely> all it works on is a flat checkout of a <foopy>
<timely> how convoluted foopy may be depends on the checkout scripts
<timely> there might be a mix of .hg,.svn,.git,.bzr,CVS,.p4,nothing w/ random inconsistent versions for CVS and SVN
<LarstiQ> ugh
<LarstiQ> well, not your problem then.
<timely> right... it's not a problem
<timely> as long as i can get the identifier that defines the .bzr state for the directory containing the file
<timely> i'm perfectly happy
<timely> and i believe *that* shouldn't be so hard
<LarstiQ> right
 * timely presumes that bzr pull for an unmodified .bzr is functionally equivalent to cvs update for an unmodified CVS
<LarstiQ> timely: ignoring weird cvs update corner cases, yeah
<timely> then why didn't it work? ;-)
<LarstiQ> "just give me the same state as they have over there, kxthbye"
<timely> [timeless@landfill bugzilla]$ [ -d .bzr ] && bzr pull
<timely> bzr: ERROR: No pull location known or specified.
<LarstiQ> timely: I don't know, what is it not doing you expected it to do?
<LarstiQ> timely: right, as the error said
<timely> my cwd is the parent of http://mxr-test.landfill.bugzilla.org/bugzilla-bzr/source/.bzr/
<LarstiQ> timely: it doesn't know where to pull from
<timely> man says:
<timely>        bzr pull [LOCATION]
<timely>               Turn this branch into a mirror of another branch.
<timely> traditionally [] means optional
<timely> am i misreading man?
<LarstiQ> timely: it is optional if the pull location is remembered
<timely> http://mxr-test.landfill.bugzilla.org/bugzilla-bzr/source/.bzr/branch/bound
<timely> exists
<timely> and points to what i think is the right answer
<LarstiQ> timely: you're using a checkout?
<LarstiQ> timely: try 'bzr update' instead then
<timely> ok, that worked
<LarstiQ> if you're always using checkouts, stick with update
<LarstiQ> timely: just to have mentioned it, although you don't need it, if you do 'bzr pull <location>' once, it will remember that as the pull location.
<LarstiQ> timely: If you want to then once pull from somewhere else, 'bzr pull <location2>' will get data from location2 but still remember location1 as where it should normally pull from
<LarstiQ> timely: bzr pull <location2> --remember to override that
<timely> so what did i do wrong the first time such that it didn't remember?
<timely> also, does bzr update understand if it's talking to a tty?
<timely> specifically, i don't mind the output at the end where it says what merged, but i don't want the progress indicator since this is being redirected to a file
<beuno> timely, adding --quite should do the trick
<timely> --quiet / -q, i found that
<timely> but i kinda expect that to silence everything
<timely> oops
 * timely kicks self
 * timely has a slightly too greedy regexp
 * timely tries to figure out how to handle it
<LarstiQ> or you can use BZR_PROGRESS_BAR=tty,dummy,none,dots
<beuno> well, I'm off to bed again
<LarstiQ> beuno: sleep well
<beuno> timely, if you have any remaining questions/requests on loggerhead, don't hesitate to mail the list, or myself (argentina@gmail.com)
<LarstiQ> timely: why pull didn't have a pull location at first, you used a checkout instead of a standalone branch, which is a different model
<beuno> LarstiQ, thanks, and good to see you around here  :)
<LarstiQ> timely: if you were to 'bzr branch <foo>' instead of 'bzr checkout <foo>', it would have it's default pull location set
<LarstiQ> timely: if you try do pull in a checkout, it will instead run pull on the branch it is bound to
 * timely boggles
<timely> distributed rcs is too complicated for my tiny little mind
<timely> beuno: thanks,
<LarstiQ> timely: well, you're mixing centralized and decentralized workflows :)
<timely> well... i'm a readonly consumer
<timely> i should only ever have one upstream, and i just want the latest and greatest
<timely> oh, and i'm a robot, did i mention that?
<timely> thinking is really way too complicated for me :)
<LarstiQ> timely: right, so 'bzr checkout <upstream>' once, 'bzr update' always after that, should cover your use case perfectly.
<timely> right, which is probably why i used bzr checkout in the first place
<timely> stupid question. would it hurt bzr to suggest "did you mean bzr update" when i do bzr pull?
<timely> if this tool were an opensolaris tool, i suspect it'd have said that
<timely> note: that's a non interactive error, the user should be forced to type the correct thing at a new prompt
<LarstiQ> timely: maybe
<timely> in unrelated bits, can i demote a pull to a checkout?
<timely> since i think the second bzr repo i made was a branch instead of a checkout
<LarstiQ> timely: detecting the case where you're in a checkout and have no pull location would be doable. But what if the pull location _is_ set?
<LarstiQ> timely: you can convert a standalone branch into a checkout and vice versa with bind/unbind
<timely> i'm not sure what that means :)
<timely> (to the former)
<timely> (which doesn't mean i can't parse your English, just that i don't speak bzr)
<LarstiQ> timely: that means I'm not sure if suggesting to use update instead of pull is a good thing to try to do.
<timely> no, that part i understood
<timely> what i don't understand is what it means conceptually to have both a checkout and a pull source
<LarstiQ> timely: Ah.
<LarstiQ> timely: Are you sure you want to know this? It gets rather decentralized :)
<timely> i'll live, if it means i get a chance to convince you to improve the error reporting :)
<timely> all of the work i'm doing these days is decentralized
<LarstiQ> ok
<timely> but... i don't drink, so stop if it sounds like you'll force me to drink :)
<LarstiQ> timely: First, remembering a pull location or the bound branch is just storing data, that in itself doesn't change the behaviour.
<timely> "which behavior" :)
<LarstiQ> timely: right. The behaviour of it beign a standalone branch or a checkout.
<LarstiQ> timely: In a standalone branch, your workflow would be: branch once, pull/push after that, respectively to the remembered pull and push locations.
<LarstiQ> timely: in a checkout, your workflow would usually be to checkout once, or otherwise bind a standalone branch, and then use update/commit for sending over revisions.
<LarstiQ> timely: (obviously, in a standalone branch you also need to commit, but the act of sending it across the wire is decoupled into pull, whereas with a checkout a commit makes a new revision _and_ pushes it out to the master)
<LarstiQ> timely: Now, using pull in a checkout is also possible, but it doesn't do the same thing as in a standalone branch.
<LarstiQ> timely: pull in a checkout will update the branch it is bound to, as well as the local version
<LarstiQ> unless I've been gone too long and I'm severely mistaken
<LarstiQ> timely: as beuno said, I haven't been around in a while
 * timely missed that last bit by beuno
<timely> but ok :)
<LarstiQ> anyway
<LarstiQ> timely: I'm going to start my day in a couple of minutes, do you have enough information for now?
<timely> so pull in a checkout is kinda like changing branches (but potentially or likely changing repos which isn't something that i care about)
<timely> i  think it's a non issue
<timely> anyone doing pull in a plain checkout will get an error the first time
<timely> with a suggestion to do update
<timely> anyone who actively uses pull w/ a url "knows what they're doing"
<timely> and the next time they do a pull, they'll get what they want
<timely> however, anyone doing pull in a checkout w/o a url doesn't know what they're doing
<LarstiQ> I'm not so sure.
<timely> (i.e. me) and just wants an error w/ a suggestion
<LarstiQ> timely: it's perfectly legitimate to run pull without any arguments in a checkout.
<timely> but it errors!
<timely> that's what started this conversation :)
<LarstiQ> timely: only in this very specific case
<LarstiQ> timely: And as I said, that can be detected and warned about. But I fear there are more cases where someone doesn't know what they're doing and we can not detect it.
<timely> personally, my general view is that you should add warnings/errors where possible
<LarstiQ> timely: but yeah, I don't know.
<timely> instead of throwing up your hands and saying "we can't be perfect"
 * LarstiQ can't think this through right now.
<timely>    bzr pull [LOCATION]
<timely>            --remember                Remember the specified location as a
<timely>                                      default.
<LarstiQ> timely: but feel free to suggest it to someone who has actually been working on bzr lately :P
<timely> English nit: "how many defaults can bzr have for a single repo"?
<timely> "a default" ^
<LarstiQ> timely: unlimited
<LarstiQ> but I see what you're getting at.
<timely> good. because i really don't want to hear the explanation for your answer :)
<LarstiQ> there is no limited to the amount of branches in a repository ;P
<LarstiQ> I do think you meant to say branch, and in that case, it's not unlimited.
<LarstiQ> vcs lingo yay
<timely> i didn't say branch
<LarstiQ> right
<timely> oh
<LarstiQ> timely: and the default is on a per branch basis.
<timely> bah. i was trying to be so careful
<timely> i should have said .bzr/
<timely> would that have been any more or less ambiguous?
<LarstiQ> well, there is {.bzr/repository,foo/.bzr/branch} etc
<LarstiQ> timely: more ambiguous
<timely> gah.
<LarstiQ> timely: You find a .bzr in 3 locations: repositories, branches, and working trees.
<timely> i'll settle for you understanding what i meant and praying you'll find someone who can fix the docs to be less strange :)
<LarstiQ> you find 'a default' strange?
<timely> yes
<LarstiQ> I'm not native enough to do so.
<timely> normally you'd write "the default"
<timely> if you don't mean "the default" then you should write "the default for <x>"
<LarstiQ> right
<LarstiQ> that is possible
<timely> part of the definition or meaning of default is that it is the *one* that would happen
<LarstiQ> 'for this branch.'
<timely> it's supposed to be unique
<LarstiQ> timely: per thingy
<timely> so it isn't legal to say "a default"
<LarstiQ> eh, I disagree :)
<timely> because "a default" implies that there's more than one
<LarstiQ> but there is! In the context of stuff to remember for a branch.
<timely> pull in the context as "the default for the branch"
<LarstiQ> I can see your viewpoint, sure.
<LarstiQ> timely: and I wouldn't mind a patch for it, but I won't be doing it myself.
<timely> i'll write one if i can figure out how
<timely> do i checkout or branch ;-?
<LarstiQ> with that, I can help you.
<LarstiQ> timely: branch.
<timely> grr
<timely> ok, so much for me not teaching mxr about bzr branching
<LarstiQ> timely: you want to commit in this case
<LarstiQ> timely: you don't have access to upstream to do that.
<timely> gimme a bit, i need to switch computers to one which will have a different mxr and probably a different bzr
<LarstiQ> timely: a checkout is possible, but then you have to commit --local, or unbind
<timely> -bash: bzr: command not found
<timely> this is going to be so much fun
<LarstiQ> luckily, bzr works very well from source, no need to install
<timely> someone said the same thing about hg
<timely> they were wrong
<timely> python doesn't work very well from anywhere :)
<LarstiQ> hg needs to compile things
<timely> nah
<timely> the problem w/ hg was python include paths
<timely> nothing to do w/ building
<timely> everything to do w/ the fact that once it was built, it wouldn't run
<timely> c.f. loggerhead
<LarstiQ> Ok, no clue about that, I only know their diff algorithm is written in C.
 * timely shrugs
<timely> it's pluggable, but let's stick to bzr
<LarstiQ> timely: right
<timely> you can eat the runtime bridge when i come to it :)
<timely> https://launchpad.net/bzr/1.5/1.5/+download/bzr-1.5.tar.gz ?
<LarstiQ> timely: download source, unpack, possibly symlink or alias 'bzr' to unpacked-source/bzr, and go
<LarstiQ> timely: that should work I guess
<timely> 03:16:24 ERROR 303: See Other.
<timely> yeah right
<LarstiQ> timely: just to be sure, what python version do you have there?
<timely> Python 2.3.5 (#2, Oct 16 2006, 19:19:48)
<timely> :)
<LarstiQ> ugh
<LarstiQ> I'm afraid that won't really do.
<timely> i have python2.2 if you prefer ;-)
<LarstiQ> No, I prefer 3.0 ;P
<LarstiQ> Nah, 2.4 or 2.5
<timely> python2.4 maybe?
<timely> that i have
<timely> it isn't the default...
<timely> Python 2.4.4 (#2, Apr 29 2008, 08:45:14)
<timely> python3.0 is useful in that it isn't compatible w/ 2.x
<LarstiQ> is it in your PATH?
<LarstiQ> timely: right, I was joking
<timely> except of course, 2.5/2.4/2.3 aren't really compatible w/ eachother either
<LarstiQ> timely: it not being compatible is the exact reason of existance
<timely> each time someone tries to change the default, a half dozen apps break here
 * LarstiQ shrugs
<timely> yeah yeah
<timely> [sanjay]$ which python2.4 => /usr/bin/python2.4
<LarstiQ> I'm assuming /usr/bin is in your PATH :)
 * timely loves how python gave a timestamp but didn't mention a timezone
<timely> heh... for now anyway
<timely> until perl taint makes me take it away ;-)
<timely> so anyway... i got 303 which broke wget
<timely> which is um... cute
<LarstiQ> timely: my wget follows 303
<timely> oh
 * timely wonders if this is a shell problem
<LarstiQ> timely: https://launchpadlibrarian.net/14566578/bzr-1.5.tar.gz
<LarstiQ> try that
<timely> that works better
<LarstiQ> timely: got it unpacked?
<timely> ok, i am here: http://timeless.justdave.net/mxr-test/bzr/source/
<timely> ok, so... arg
 * timely sighs
 * timely tries to remember the syntax
<LarstiQ> doh
<LarstiQ> Location isn't specific to pull.
<LarstiQ> timely: http://timeless.justdave.net/mxr-test/bzr/source/bzrlib/option.py +538
<LarstiQ> timely: and http://timeless.justdave.net/mxr-test/bzr/source/bzrlib/builtins.py for the actual commands
<timely> fwiw, the search engine should work now :)
<LarstiQ> timely: you'll notice the 'remember' option being used in several commands
<timely> "the default for this command" ?
<LarstiQ> hmm, the default location for this command maybe
<LarstiQ> timely: nice to see LXR isn't actually as dead as a parrot as I thought.
<LarstiQ> timely: oh, it seems you could do a pull specific help if you really wanted to.
<LarstiQ> timely: ala http://timeless.justdave.net/mxr-test/bzr/source/bzrlib/builtins.py#4268
<LarstiQ> timely: to see that in action, look at 'bzr help send' or 'bzr help bundle' output
<timely> so um... real life calls
<timely> (quite literally actually)
<LarstiQ> yeah, here as well
<timely> well, i claim the global option was buggy
<timely> since 'a default' is never right :)
<timely> but we can do two changes
<timely> one "the default for this command" for global and something more specific for pull
<LarstiQ> right
<LarstiQ> your call :)
<timely> anyway, glad you aren't having trouble using mxr :)
 * LarstiQ used to use lxr
<timely> the name change was just to slightly reduce the confusion about how different we are from the other 2 forks
<timely> which are fairly dead and so far forked from us that well...
<timely> anyway, quickly. how do i build? :)
<LarstiQ> build what?
<LarstiQ> bzr? I don't :)
<LarstiQ> timely: assuming you've made the change, you should be able to immediately see the effect by invoking the bzr there
<LarstiQ> so; cd bzr-1.5; vim bzrlib/option.py; ./bzr help pull
<timely> yeah but um
<timely> oh
<timely> perfect
<timely> [sanjay]$ ./bzr status => bzr: ERROR: Not a branch: "/home/timeless/mxr-root/lxr-data/bzr/bzr/".
<LarstiQ> is that an unpacked tarball, or an actual bzr branch?
<timely> oh brother
<timely> unpacked
<timely> stupid stupid debian stupid stupid
<timely> tm
<LarstiQ> ah yes, that wouldn't be a branch :)
<timely> that would be useless
<LarstiQ> timely: well, you can send of a plain diff
<LarstiQ> or if you want actually get a copy of bzr in bzr :)
<timely> http://timeless.justdave.net/mxr-test/bzr/source/README?force=1#66
<LarstiQ> bzr get http://bazaar-vcs.org/bzr/bzr.dev for the latter
<timely> has a comma that doesn't belong
<LarstiQ> how so?
<timely> X or Y. A, B or C. OR A, B, or C. but NOT X, or Y.
<timely> btw, i had to fix mxr just to give you that link...
<LarstiQ> I see it as a bijzin and not a list.
<timely> bijzin?!
<LarstiQ> But hey, you're the English native speaker ;)
<LarstiQ> timely: no clue what that is called in English.
<LarstiQ> timely: read that as: I don't really care, but if you're willing to spend effort on things like that, I'm not stopping you.
<timely> ok :)
<timely> anyway, that's why i grab sources
<timely> if i'm going to make changes, i'll probably make lots
<LarstiQ> it costs more energy to argue for an alternative in my eyes correct reading than just accepting your patches :)
<timely> although whether i manage to upstream them is another story
<timely> i think you can find my tt forks on that mxr somewhere
 * timely hits the wiki warning that cloning bzr takes time
<LarstiQ> timely: can you manage from here? If so I'll get back to real life again.
<timely> yeah
<LarstiQ> k, see you later perhaps
<timely> only other question is how changes should be sent
<timely> some sort of thing showing 1000 commits, one commit per file
<timely> or one commit per style change for the repo
<timely> or one commit for the whole repo
<LarstiQ> one branch per topic
<LarstiQ> bzr send will roll all the commits up
<timely> do branches mean distinct parents of .bzr's?
<timely> or can i sorta commit into the same repo swapping branches as i go
<LarstiQ> timely: I think you're conflating repo and branch
<timely> dh is picky about non web served content that it thinks is "Backup"
<timely> to me, "repo" is something that contains something like .hg/ or .git/
<timely> my goal is to make sure i don't have to have 5 copies of the thing that holds a "clone" of upstream (because i hit space quotas)
<timely> and also to make sure i don't have to republish (to avoid hitting "not web content" dreamhost hosting rules)
<LarstiQ> every branch (.bzr/branch) that lives in a directory tree under a dir that has a .bzr/repository, will use _that_ .bzr/repository to store its revisions
<LarstiQ> timely: you'll find `bzr init-repo` helpful then
<LarstiQ> timely: but if you're doing documentation style changes, I'd fit all of that in one branch
<timely> ok
<timely> that simplifies matters :)
<LarstiQ> that is what I meant per topic, the topic being 'documentation style' in this case, or bug-12345 in another, or nested-trees feature, etc
<LarstiQ> timely: but why does dreamhost factor in?
<timely> well, each host i have has rules
<timely> my personal box runs 10.3.9
<timely> the usual rule is "nothing i want to do works there"
<timely> landfill.bugzilla.org's rule is "must be mozilla related" (bzr isn't)
<timely> dreamhost (timeless.justdave.net)
<timely> 's rule is "must be web content"
<timely> i have other boxes, most of them have rules "no free space available"
<LarstiQ> hmm.
 * LarstiQ just works on his laptop.
<timely> my laptop's rule is "for work purposes"
<timely> bzr doesn't fit there either ;-)
<timely> it also falls into "no free space available"
<LarstiQ> well, if that makes you happy.
<timely> (and probably doesn't have python)
<timely> oh, dunno about happy. but it is life :)
<timely> happy is going to the beach, which is what i'll do now :)
<LarstiQ> timely: ok, ciao
<timely> oh, how do i set my committer name?
<LarstiQ> bzr whoami 'Wouter van Heyst <larstiq@..'
<timely>     ~/.bazaar/bazaar.conf [DEFAULT] email=... ?
<LarstiQ> or that
<timely> timeless.justdave.net FTP <timeless@sanjay>
<timely> is not what i want to be :)
<LarstiQ> timely: you can set your committer id per branch, ~/.bazaar/bazaar.conf will have the default
<LarstiQ> So, run 'bzr whoami <foo>' from outside a branch, and it will set the default
<timely> oh well
 * timely manually created the file
<LarstiQ> and it turns out also from inside, ah well
<LarstiQ> --branch to set it locally instead of globally
<LarstiQ> aaaanyway
<LarstiQ> timely: you can check what it is with `bzr whoami`
<timely> ok. first commit done
<timely> beach!
<LarstiQ> mind fuck festival!
<LarstiQ> http://mindfuckmondays.com/ for other people in the area of Den Haag
 * LarstiQ is gone
<Pieter> Hey all. I did some repository size benchmarks on repos with full history (http://vcscompare.blogspot.com/2008/06/git-mercurial-bazaar-repository-size.html) instead of just a tarball import as done on the benchmark page.
<Pieter> I think this is a lot more realistic benchmark than done at http://bazaar-vcs.org/Benchmarks/SpaceEfficiency. Perhaps you should update the website?
<bob2> might want to post that to the list
<gour> interesting results...
<gour> there is some room for improvement in bzr, it seems
<bob2> did increasing the window size help git much?
<Pieter> I did some benches on that.. when you go from 10 to 50 you can get a 2x improvements
<Pieter> 50 to 100 perhaps another 2x
<Pieter> but after that not much improvement
<gour> Pieter: which repo format you use for bzr?
<Pieter>     repository: Packs containing knits without subtree support
<pygi> poolie, around perhaps in any change? :)
<pygi> chance*
<adaran> hey everyone
<adaran> is there any document that someone can point me to that explains the "philosophy" (not ideology) behind bazaar?
<adaran> all i can find at the moment are howtos, tutorials and other stuff =/
<rockstar> Does this error make any sense to anyone?  http://pastebin.com/m483b7ade
<cody-somerville> rockstar, try breaking the lock manually?
<jumpkick> what do people usually use for the <name> portion of their branch name?  trunk? main?
<Pilky> jumpkick: you mean the main development branch? we use dev for our open source project, for my personal projects I haven't settled on one yet
<rockstar> cody-somerville, break lock doesn't fix it.  Tried that already
<beuno> rockstar, it's a bug between bzr versions (you're probably using 1.5, and LP has 1.3)
<beuno> rockstar, https://bugs.edge.launchpad.net/bzr/+bug/236380
<rockstar> beuno, wierd.  So why can I branch from some projects, and no others?
<beuno> rockstar, I'm not sure yet, it has something to do with the way the smart server handles it
<beuno> you can, as a workaround, branch using http, and then push with bzr+ssh
<rockstar> beuno, ah, alright, that makes sense.
<xif> Hi!
<xif> I have a few questions about Bazaar.
<xif> First of all, what's the best way to get the current revision of a repository?
<Pilky> the revision number?
<Pilky> bzr revno
<xif> yeah
<Pilky> though you can only get the revision of a branch, not a repository
<xif> Pilky: yeah, `bzr revno` seems to be the thing
<xif> (that's what I want, really :)
<xif> btw, is there a nice way of doing this from Python?
<xif> (just curious)
<Pilky> that I wouldn't know
<luks_> b.last_revision()[0]
<luks_> or [1], not sure
<luks_> (where b is a Branch instance)
 * xif nods
<luks_> er, or maybe b.last_revision_info()
<xif> thanks. another question: there were significant changes in the format of the actual files storing the bzr data over the last several version, right?
<luks_> but it's definitely one of those :)
<beuno> xif, http://bazaar-vcs.org/Integrating_with_Bazaar  may be fun to loot at
<beuno> xif, there hasn't been any changes since 0.92
<beuno> so it's been very stable for some time now
<xif> yeah, unfortunately, the latest for Gutsy is still 0.90
<beuno> xif, PPA's are your friend
<beuno> https://launchpad.net/~bzr/+archive
<xif> so there might be some chance of some members of the team needing to interact with 0.90 branches
<xif> what would happen if someone tries to negotiate a 0.90-created branch with 1.5?
<beuno> well, they wouldn't be able to, I guess
<xif> OK, is there a chance of a silent failure?
<xif> i.e. corrupting a branch?
<beuno> but, the improvements since 0.90 justify the upgrade
<luks_> what? current bzr supports all older formats
<beuno> no, it should be explicit about the bzr not understanding the format
<LarstiQ> beuno: ehm, 1.5 reading 0.90 should be fine?
<beuno> luks_, but not the other way around
<LarstiQ> right, right
<beuno> ah, right
<beuno> sorry
<beuno> xif, listen to the more-awake people  ^
<xif> hehe
 * Pilky hands beuno some coffee
<xif> OK, so if 1.5 pulls data from 0.90, it would in fact convert it to the new format?
<luks_> no, it would use the old format
<LarstiQ> xif: it can pull from an old branch into a new one, or if you freshly branch, it should use the old format iirc
<beuno> yeah, I still use a few branches on LP that haven't been upgraded, and it's transparent
<xif> LarstiQ, luks: OK, but it seems even in that case, there shouldn't be any problems.
<xif> of course, it would be best if everyone made sure to use 1.5
<xif> but corruptions or fatal errors trying to pull/push data shouldn't occur, according to you.
<luks> definitely not
<xif> thanks a lot :)
<luks> either it will tell you it doesn't support that format, or it will work well
<xif> what were the changes 0.90 => 0.92 btw?
<gour> @localtime gour
<gour> igc: hi, i just updated 'darcs-support' bug with some new & interesting info
<timelyx> hello world
<timelyx> in bzr rel notes there's a reference to "Tortise" i'm assuming it means Tortoise am i wrong?
<fperez> Howdy, I have a question regarding how to do what the abandoned 'bzr graft' plugin did... Anyone who might be able to help?
<fperez> URL for graft: http://spacepants.org/src/bzrgraft
<timelyx> indeed, it's a typo :)
<Pieter> fperez: have you tried the bzr-rebase plugin?
<fperez> Pieter: yup, unsuccessfully so far...
<fperez> The problem is that the two branches are chronologically contiguous, but one was started 'from scratch' with no history.
<fperez> Rebase won't let me do it because it detects no common parents.
<fperez> I'll give a bit more detail now: I'm the lead of the ipython project, and we recently switched from svn to bzr.
<fperez> When testing the switch, our SVN server was having memory problems and launchpad could never complete a full download of the svn history to start working from.
<fperez> So one of the ipython devs just made an initial bzr import with zero svn history and uploaded that  to launchpad, so we could see if we liked the workflow.
<fperez> Now we're happy and we want to fully abandon the svn support, but we'd like to bring the old history in (years) and merge it with the recent work done in bzr (3 months).
<fperez> So bzr-graft sounds exactly made for this, but unfortunately it doesn't load in current bzr.
<fperez> I don't have the time to basically rewrite graft, so I was wondering if an alternative solution exists.  If I'm mis-using rebase (I'm no expert) I'll be happy to try again.  I can give details of the problems I'm seeing.
<LarstiQ> fperez: oef
<LarstiQ> fperez: I'd write to the list about this.
<fperez> OK, that was my next move to try just now.  I was just wondering if I was missing something obvious that a guru could quickly spot. Thanks.
<LarstiQ> it's not something that I'd immediately know how to approach
<fperez> No problem, I appreciate the feedback.  bzr-graft is intended to do *precisely* this, so it's a shame it has bitrotted.  But I just don't have the time to resurrect it for a one-off effort.  It would be great if that plugin was maintained in the core: the code looked actually pretty small, so I'm sure for someone who knows the bzr API it would be easy work.
 * timelyx frowns
<timelyx> is there a difference between ``a``, 'a', and "a" in the README files of bzr?
<Peng> The files are ReST, or however it's capitalized. I think ``a`` means <code/>, and the others are meaningless.
<timelyx> thanks
<timelyx> did bzr pick en-gb for all content? and is en-us content considered buggy?
 * timelyx frowns
<timelyx> robert collins /looked/ like an en-gb er
<timelyx>      generalises the ``exclude_suite_by_re`` function. (Robert Collins)
<timelyx>      randomized copy of the input suite. (Robert Collins)
 * timelyx will need to get an en-gb dict
<Peng> Canonical is in the U.K., and I think many of the developers are Australian.
<timelyx> ok
<schierbeck> hi guys
<timelyx> does bzr have a concept of a 'teste'?
<pickscrape> I'm just trying to get the diffstat plugin working. It's using diff_cmd_helper, which was removed in r3410 (apparently deprecated before 1.1)
<pickscrape> Anyone know what I might use in place of it?
<LarstiQ> pickscrape: DiffTree? Have a look at the call chain for cmd_diff from bzrlib/builtins.py
<pickscrape> LarstiQ: thanks. (my first foray into bzrlib, this)
<LarstiQ> pickscrape: you're welcome
<LarstiQ> pickscrape: alternatively, use gannotate to find out what replaced diff_cmd_helper around the same time it got removed
<LarstiQ> or at deprecation time probably
<pickscrape> Hmm, would I be right in thinking that if a function name starts with an underscore it's considered 'private' and shouldn't be called from within plugins?
<pickscrape> It was deprecated in 3072.1.1, and all functions added in that revision are underscored. I'm going to look at the code that was calling it for clues...
<LarstiQ> pickscrape: yes, you are right
<pickscrape> Aha! I've got it working! (I think)
<pickscrape> Any idea if this is sensible? show_diff_trees(bzrdir.open_branch().basis_tree(), bzrdir.open_workingtree(), out, file_list)
<pickscrape> It's the ï»¿bzrdir.open_branch().basis_tree() part that I dug up myself, and may be completely incorrect
<poolie> hello
<beuno> morning poolie
#bzr 2009-05-25
<davidstrauss> Glenjamin: still having that move problem?
<Glenjamin> nah, i figured it out
<Glenjamin> although i reckon there's scope to make bazaar smarter about moving directories
<Glenjamin> the short version is that you cant move things into a non-versioned directory
<Glenjamin> so dir1 => dir2/dir3 doesnt just work
<igc> morning
<davidstrauss> What's the status of bzr-tools vs. bzr-1.15?
<davidstrauss> nevermind
<gutworth> lifeless: hi
<AfC> Why would bzr (talking to Launchpad) have to do ~ 300 kB of data to transmit a single revision with about 1 lines of changed code in it?
<bob2> recent branch format?
<AfC> bob2: certainly
<AfC> It's been the same for each of several single revision pulls over the last few days.
<AfC> I don't normally interact with Launchpad (or use http), so this is all a bit of a surprise.
<AfC> But that's where the contributor put their branch, so {shrug}
<AfC> I have the opportunity to enjoy the experience.
<krisfremen> is there a way for bzr log to only show the log for the last revision?
<gutworth> bzr log --limit 1
<krisfremen> thanks gutworth
<igc> krisfremen: bzr log -r-1 will do the trick as well
 * igc lunch
<krisfremen> hmm, indeed
<krisfremen> thanks
<profchaos> I have some problem getting the latest from a launchpad bzr branch.  I have the error pasted at http://dpaste.com/hold/47393/ any directions?
<bob2> profchaos: double check that link
<bob2> profchaos: if that is the right one, it's unrelated to bzr, but you need to install cdbs (and build-essential and fakeroot and anything else listed in the Build-dep line in debian/control)
<profchaos> I'm new to bzr, i might well be wrong
<bob2> I mean, check the link to see if it is the one you meant to paste, since it'z not a bzr problem :)
<profchaos> yes that's my paste for sure
<Quozl> odd, what was the command line of that paste?
 * bob2 guesses bzr-buildpackage
<profchaos> ./debian/rules get-orig-source LOCAL_BRANCH=../upstream/chromium-browser.svn
<Quozl> apt-get build-dep?
<bob2> only if the package is in Debian (and has the same build-deps)
<Quozl> agreed.
<profchaos> I'm not sure i was trying to follow https://wiki.edubuntu.org/Chromium/Build
<Quozl> ... interesting ... then why ask in #bzr?  ;-}
<profchaos> I'm just trying to get the current source from lp:chromium-browser
<bob2> I don't think that command produced that error
<bob2> more likely the next one
<profchaos> @bob2 normally, how do we get the latest of a bzr launchpad branch?
<bob2> what?
<bob2> 'bzr branch lp:whatever'
<profchaos> let me try that now
<bob2> qanyway, if the instructions don't work, best to contact the people who wrote them
<Quozl> yeah, the instructions obviously don't work on your system.
<profchaos> @bob2, bzr branch lp:chromium-browser seemed to work. it copied some files to my system now, but i see just a couple of files in the target folder.
<bob2> as above
<bob2> bzr got you the files you asked for - anything beyond that is up to the scripts you're running
<bob2> it could potentially bea problem in bzr-buildpackage, but you'd need to pastebin your shell session
<profchaos> okay, let me check what else has gone wrong
<profchaos> thanks anyways
<profchaos> ls
<lifeless> guhi
<bob2> lifeless: back to work
<igc> hi lifeless - morning!
<lifeless> hi
<lifeless> we should have sprint stuff happening in  a few hours at most
* jml changed the topic of #bzr to: Bazaar version control system | 1.15final released 22 May, 2009 | http://bazaar-vcs.org | http://irclogs.ubuntu.com/ | http://planet.bazaar-vcs.org/ | Sprinting in Barcelona
<mwhudson> Peng: of course, what we need is a generic transport-to-http adapter :) :)
<Youssef> Hi All
<Youssef> I have a question
<GaryvdM> Hi Youssef
<Youssef> it is about the bzr add command
<Youssef> check this
<Youssef> === modified file 'index.html'
<Youssef> --- index.html  2009-05-13 11:38:13 +0000
<Youssef> +++ index.html  2009-05-22 19:18:00 +0000
<Youssef> @@ -1,1 +1,2 @@
<Youssef>  Hello World!!!
<Youssef> +"I'm a new line"
<Youssef> what does mean @@ -1,1 +1,2 @@
<Peng_> mwhudson: Serving a remote branch would be terribly inefficient, though.
<bob2> Youssef: it's a diff
<Youssef> yes but
<mwhudson> Peng_: pfff, such a boring objection
<Peng_> Youssef: That line shows the location of the change in the file.
<bob2> Youssef: it is indicating where in the file the edit is (line 1, in this case)
<Youssef> but i see -1,1 +1,2
<Peng_> mwhudson: :D
<Peng_> Youssef: And?
<Youssef> precisly what is it
<bob2> Youssef: http://www.artima.com/weblogs/viewpost.jsp?thread=164293
<Youssef> bob2: Thanks
<Youssef> guys im making a user guide of bzr for windows in french
<Youssef> im contributing in hehe
<igc> bbiab
 * igc dinner - bbl
<GaryvdM> beuno: Got logerhead branched. ./serve-branches works. What was the other was to serve?
<beuno> GaryvdM, ./start-loggerhead
<beuno> but it's complicated
<mwhudson> and the fix is 'bzr rm'
<beuno> :)
<beuno> soon
<beuno> maybe this sprint
<beuno> after this session
<beuno> I'm hiding in the bzr room
<beuno> find me a good place to hide
<mwhudson> yeah, good luck with that
<mwhudson> you can probably go behind the screen
<GaryvdM> beuno: so ./server-branches is what I should use?
<beuno> GaryvdM, yes
<igc> bbiab
<mwhudson> beuno: how outrageously booked are you today?
<beuno> mwhudson, I'm on my way NOW
<mwhudson> beuno: that's not actually an answer to my question :)
<beuno> mwhudson, I will try to spend 50% of my time with you guys
<beuno> at least 50%
<mwhudson> beuno: cool
<johnf> abentley: ping
<poolie> hi igc?
<poolie> igc: notes from our session in here http://bazaar.launchpad.net/~bzr/bzr/devnotes/changes
<johnf> LarstiQ: ping
<gkahla> hey folks - is bzr a good candidate for a small workgroup managing a set of OpenOffice.org documents and some maps in .jpg? I'm interested in how it deals w/ blobs.
<Peng_> gkahla: Current disk formats do line-based deltas, so storage efficiency might not be ideal, but it will work fine.
<Peng_> gkahla: Aside from that, you obviously won't get the benefit of looking at diffs, and merges will be more manual, but you can do it.
<gkahla> Peng-  it'll be a 4 ~ 5 person group, so merges are not critical
<gkahla> i'll just smack the appropriate person with a hammer
<gkahla> so long as I could "roll back" to a previous version of a given .odt, that's really all the functionality I need at this point.
<gkahla> thanks for the feedback, Peng
<jml> poolie: commit & push please
<gkahla> thx folks - later
<mwhudson> poolie: M-x insert-table >:)
<johnf> lifeless: Just kept my side of the bargain. Patch for ppa.txt and tools/packaging/* just emailed
<igc> poolie: thanks
<igc> poolie, lifeless: I'm heading off for the night
<jelmer> Hi Ian
<jelmer> igc: g'night
<igc> I've emailed the list with what I'm working on in case anyone wants to tweak those
<jelmer> I think poolie and lifeless are still at lunch
<igc> hi jelmer. How are you?
<jelmer> Good! Sorry to hear you couldn't make it to the sprint.
<igc> jelmer: me too! It would have been great to catch up
<igc> jelmer: hope you're enjoying the sprint. I'll be back tomorrow. night
<jelmer> igc: gnight
<johnf> abentley: you back?
<LarstiQ> johnf: pong
<johnf> LarstiQ: will you have time to do create bzr-svn packages?
<LarstiQ> johnf: there is a new bzr-svn version?
 * LarstiQ looks at announce
<johnf> LarstiQ: I didn't see an annouonce but there is one on the web page
<johnf> 0.6.1
<LarstiQ> johnf: it seems so
<LarstiQ> jelmer: did you intentionally not announce bzr-svn 0.6.1 on bazaar-announce?
<LarstiQ> johnf: I can do it in ~5 hours
<LarstiQ> (start on it that is)
<johnf> cool. I'm waiting on abentley to surface again so we can get a bzrtools release as well
<LarstiQ> johnf: isn't everyone at UDS?
<johnf> yes I think so
<LarstiQ> except for us ;)
 * fullermd is currently hacking around the missing bzrtools...
<GaryvdM> http://projects.serverzen.com/pm/p/cluemapper/wiki/ClueBzrServer
<lifeless> poolie: ciao; leaving you my double-adapter as I recall your second power adapter doesn't fit the wall sockets.
 * lifeless -> door
<spirov92> hi guys, I've been looking at this: http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#team-collaboration-distributed-style Which workflow do you think is recommended for web development?
<spirov92> btw hi KX
<spirov92> if I merge a feature branch into the trunk branch, can I delete the folder with the feature branch?
<Peng_> spirov92: If you want to. I don't, though.
<bialix> helmer: hi
<bialix> sorry
<bialix> jelmer: hi
<bialix> I've branched svn repo from http://projects.serverzen.com/pm/p/cluemapper/browser/ClueBzrServer/trunk
<bialix> I can see the log of the branch
<bialix> but when I'm trying to see diff I've got: NoSuchRevision: KnitPackRepository('file:///C:/Temp/ClueBzrServer/trunk/.bzr/repository/') has no revision rocky@serverzen.com-20090226184017-m3cemyrz487uxhg3
<bialix> jelmer: is it known problem or?
<GaryvdM> Hi bialix
<Peng_> How should integration branches be used? When you want to, uh, integrate a branch, should you merge or pull it?
<Peng_> ISTM both are used by you guys.
<Peng_> What about "merge --pull"?
<LarstiQ> Peng_: merge --pull is a shortcut for 'bzr pull. Oh, it failed, bzr merge.'
<LarstiQ> Peng_: or 'bzr pull. It worked' in the other case
<LarstiQ> Peng_: integrating will mean, I think, in most cases that the branches are diverged, which would mean merge
<servilio> hi! is there a way to preserve the executable bit when committing to a subversion repository?
<jml> servilio: you mean, using bzr-svn?
<Peng_> LarstiQ: On a slow-paced project, they may not be diverged.
<servilio> jml: yes, using bzr-svn
<LarstiQ> Peng_: ok, so what is your definition of an integration branch?
<fullermd> The complement to a differentiation branch.  Duh.
<Peng_> LarstiQ: I dunno. I've never used one. That's why I'm curious! :D
<Peng_> Heh.
<Peng_> Yes, that's a better answer.
<LarstiQ> fullermd: and indeed, it is!
 * fullermd is full of smart answers.  Or smart _something_ answers, anyway...
<LarstiQ> to multiple differentation branches though.
<ronny> yo
<LarstiQ> Peng_: afaik/imo integration becomes interesting when there are multiple differentiation branches you want to incorporate.
<ronny> anyone got a quick programmatic way to create a workdir with branch/repo
<LarstiQ> Peng_: at the start one of them might not be diverged, but after that all of them are.
<LarstiQ> ronny: bzrdir.sprout?
<Peng_> Ah.
<LarstiQ> ronny: or BzrDir.create_branch_convenience?
<ronny> LarstiQ: thats new, isnt it? its in my system
<ronny> LarstiQ: something like that
<ronny> LarstiQ: im just getting started with anyvc's repo/branch stuff
<LarstiQ> ronny: lots of the creating/copying of different kind of bzr objects happens in bzrlib/bzrdir.py
<Peng_> Eh, I'm interested in integration branches because I'd like to make final tweaks to other peoples' branches, without putting them in the top level of history, and using one branch for it would be easier. :D
<ronny> LarstiQ: the first looks cry terrrible complicated
<LarstiQ> ronny: it is for if you have a bzrdir you want to branch of off (hence, sprouting a branch)
<ronny> LarstiQ: i want to make a new one
<ronny> ie create a fresh branch
<LarstiQ> ronny: import bzrlib.bzrdir; bzrlib.bzrdir.BzrDir.create_branch_convenience('/tmp/new-branch')
<LarstiQ> Peng_: 'top level of history'?
<ronny> hmm
 * LarstiQ goes get some dinner
<ronny> LarstiQ: ok, got it now, thanks
<ronny> hmm, still the apis make me cry
<Peng_> LarstiQ: "bzr log -n 1"
<LarstiQ> Peng_: hmm.
<LarstiQ> Peng_: in some branch your tweaks will be there. Which one do you envision them not being?
<LarstiQ> ronny: especially bzrdir has grown gnarly bits, yes
<LarstiQ> ronny: I suppose your anyvc design will be close to what you'd like the interface to be?
<Peng_> LarstiQ: What do you mean?
<LarstiQ> Peng_: I'm not clear on what you're aiming to do :)
<Peng_> Ehh.
<LarstiQ> Peng_: if you say mirror brisbane-core, and then do a commit on top of that, yours will be the toplevel commit there
<LarstiQ> so, there then has to be another branch you merge that into for it not to be?
<Peng_> I want to merge other peoples' branches into the trunk of whatever without polluting the "log -n 1" history with my random review bits and NEWS stuff.
<Peng_> I can make a branch of the other person's branch to do that, but it would be less hassle and overhead to just re-use one.
<LarstiQ> ah
<LarstiQ> Peng_: I see what you mean now.
<ronny> LarstiQ: i'll try to get anyvc close to a nice interface
<LarstiQ> Peng_: I don't know if there is a better term for that, but I'd call it a review branch or somesuch
<ronny> LarstiQ: i will publish it as explicitly unstable api, then iterate till im nice with it
<LarstiQ> ronny: alternatively, if you can articulate what makes you cry, maybe that can serve as input to reworking things
 * LarstiQ nods at ronny 
<LarstiQ> ronny:  I do hope it will converge :)
<ronny> LarstiQ: mostly the amount of  words in method names, and the java-style layout of things
<ronny> LarstiQ: its python, start to embrace that already
<LarstiQ> ronny: it is python afaik
<Peng_> LarstiQ: OK, that term makes sense. What's an integration branch, then?
<LarstiQ> Peng_: an analogue to the -mm linux tree
<Peng_> Ehh.
<Peng_> What about in the bzr project?
<LarstiQ> ronny: in my experience with both, bzr code style looks nothing like java
<ronny> LarstiQ: it still reminds me of many java patterns
<LarstiQ> ronny: ok, since I don't see that, can you point out an example and how you would write it?
<LarstiQ> Peng_: a branch that collects various other branches
<LarstiQ> Peng_: say the old hpss one
<LarstiQ> Peng_: trunk/bzr.dev also fit the integration bill, except (I) normally reserve that naming explicitly for non-trunk/pre-trunk staging
<Peng_> Okay.
<LarstiQ> Peng_: the key as fullermd joked, is to bring together various topical pieces of work.
 * Peng_ nods.
<ronny> LarstiQ: not sure, bascially get many of the classmethod/staticmethod factories out to some simple paces
<ronny> LarstiQ: i'll know better after a few onyvc iterations
<ronny> *anyvc
<LarstiQ> ronny: ok
<ronny> LarstiQ: im kinda scared by the amount of factories
<LarstiQ> there are a lot of interfitting parts
<ronny> LarstiQ: imho the api is just one order of magnitude too big, hg is a lot closer to what i consider good size of the api
<Peng_> Thanks for the info, LarstiQ. :)
<ronny> well and git is close to what i consider reasons to stab people
<fullermd> Who needs reasons?
<ronny> people that like to act by reason
<ronny> needing 3 subprocess calls and lots of guessing what they could have meant with those character combinations just for getting complete enough status data is well - generating hate
<LarstiQ> ronny: what are you invoking with subprocess?
<LarstiQ> surely git can't be that convoluted?
<LarstiQ> I hope?
<ronny> LarstiQ: ls-tree -r head, ls-files -c -<some more> and ls-files -<some others>
<ronny> LarstiQ: i need workdir, index and tree data to infer status
<ronny> LarstiQ: git is a major pain
<Peng_> bzr-git?
<Peng_> Or dulwich directly?
<LarstiQ> ronny: right, as Peng_ said, would working with the datastructures directly be less painful?
<ronny> Peng_: dulwich is incomplete for the task
<ronny> and semms to be weird
<ronny> +bzr-git
<ronny> LarstiQ: also bzr isnt supposed to become a mandatory dependency
<LarstiQ> ronny: I agree. If I implied it should that is not what I intended.
<ronny> LarstiQ: well, also supporting the vcs implementations of bzr is probably a good thing
<ronny> but its not supposed to be the main backend implemenations for other vcs's
<ronny> more like nice to have fallbacks
<LarstiQ> ah ok
<vxnick> is there any way I can store the revno in a file, preferably with a hook? I'm guessing a post_commit hook wouldn't work as the revno file would then be outside the current revision?
<vxnick> I use bzr-upload once committed if that makes any difference
<pygi> hi hi
<pygi> ronny: you're again talking about anyvc?
<ronny> pygi: yeah, finally started with the repository/history stuff
<ronny> after some killing fun with git
<LarstiQ> vxnick: `bzr version-info`?
<Peng_> vxnick: Looking for svn-like keywords?
<vxnick> LarstiQ: ideally I'd like to do it as part of the commit so bzr-upload uploads it to the server with the rest of the changes
<vxnick> Peng_: that's a good point, there's a plugin for that isn't there?
<Peng_> vxnick: Yep.
<LarstiQ> vxnick: hmm hmm, I guess bzr-upload might have/need support for a processing step prior to deployment
<vxnick> slightly annoying as it uploads a .bzr-upload-revid file, but that doesn't contain the revno >.<
<LarstiQ> vxnick: it has the revid though ;P
<vxnick> true, but I need the revno for various bits
<ronny> hmm
<vxnick> clients prefer a nice readable number ;)
<ronny> anyone aware of a quick way to ask for the amount of revisions in a branch
<LarstiQ> ronny: mainline, or all?
<ronny> LarstiQ: all
<ronny> LarstiQ: im not not sure if i should like or hate the mainline feature
<LarstiQ> ronny: like ;)
<ronny> LarstiQ: its your right to like it, its mine to evaluate before i decide how much i hate it
 * LarstiQ nods
<ronny> hmm
<LarstiQ> ronny: I seriously dislike not having it in hg/git
<ronny> LarstiQ: im wondering if i sould ad it to anyvc
<ronny> it a adapter that views mainlines and pushes merges/branches kind of away
<Peng_> Quick in what way? Counting the number of revisions would probably be a full-history operation.
<ronny> Peng_: in hg its O(1)
<ronny> in svn its O(1)
<ronny> in git/bzr i might have to cache
<LarstiQ> are you sure about svn, now that it has some form of merging?
<Peng_> How's it O(1) in svn?
<ronny> LarstiQ: svn still has linear revision numbers
<LarstiQ> ronny: not entirely
<Peng_> Sure, the current revno is the total number of revisions in the repo, but not the current branch.
<LarstiQ> ronny: you can switch heads away from branches in svn
<LarstiQ> ronny: but still include revisions as merged
<LarstiQ> that aren'y linearly visible in svn log
<ronny> oh damn
<ronny> hmm, svn really does everything to suck in hellish ways
<LarstiQ> ronny: I'll give you it doesn't occur much, since svn itself can't really display it nicely
<Peng_> ronny: Well duh. What kind of successor would it be to CVS otherwise? :D
 * LarstiQ stares at the thunder and hailstorm outside.
<ronny> hmm
<ronny> i'll certainly use subvertpy for my svn stuff tho
<LarstiQ> aronny: len(branch.repository.get_ancestry(branch.last_revision())
<LarstiQ> ronny: quite a bit slower than branch.last_revision_info()
<ronny> LarstiQ: will that make a list?
<LarstiQ> ronny: yeah
<ronny> ew
<ronny> hmm
<ronny> seems like hg is the only one able to give me O(1) there
<LarstiQ> last_revision_info() on the other hand will read a number from disk
<LarstiQ> and is O(1)
<ronny> hmm, waht is last_revision_info?
<LarstiQ> ronny: revid, revno tuple
<LarstiQ> oh, other order
<LarstiQ> ronny: so yeah, mainline
<ronny> hmk
<ronny> hmm, well, hg is better at whole repo ops
<ronny> mainlines would be expensive there
<LarstiQ> ronny: yeah, hg's repository plays a role more on the frontlines
<ronny> hmm, i developed a general preference for hg, it does things more simple and faster
<LarstiQ> there is something to be said for that
 * LarstiQ still has to get to grips with it's ui
<ronny> some things about mq are a bit unfortunate, but thats about it
<ronny> hg's codebase it a lot better for getting into it than bzr's
<jelmer> ronny: hi
<jelmer> ronny: what's weird about dulwich?
<LarstiQ> I think he meant bzr-git is weird
<jelmer> ah, ok
<ronny> jelmer: dulwich is pretty ok, just not yet ready for my needs
<ronny> jelmer: bzr-git is well, wkinda weird
<LarstiQ> ronny: weird for anyvc to use? (I'd agree on principal) or weird in general? (I don't know the code)
<pygi> hi jelmer, poolie
<pygi> others :)
<ronny> LarstiQ: weird in general, when i last tried it with bzr it was all weird
<LarstiQ> ronny: k
<LarstiQ> hi jelmer, pygi, poolie1
<LarstiQ> this was the first day?
<pygi> LarstiQ: yup
<LarstiQ> how was it?
<pygi> pretty good, I even got some work done :P
<pygi> too bad windows is so broken, so there are all sorta weird bugs :-/
<poolie1> hello LarstiQ, it was good
<LarstiQ> pygi, poolie1: good to hear
 * LarstiQ wouldn't mind a blog post ;)
<pygi> LarstiQ: I think poolie microblogged everything
<pygi> does that counts? :p
<Peng_> Oh? URL?
<LarstiQ> pygi: maybe if I knew where to find that :P
<Peng_> (Eh, I guess that's what the search pages are for.)
<pygi> LarstiQ: http://twitter.com/sourcefrog
<LarstiQ> pygi: thanks. I wonder if I could fit this into identi.ca somehow
<pygi> LarstiQ: he also has an identi.ca acc :P
<Peng_> http://identi.ca/sourcefrog fwiw
 * LarstiQ subscribed
<LarstiQ> sigh, I botched that slightly
 * LarstiQ goes to bed
<jelmer> ronny: ah, right
<jelmer> ronny: bzr-git is about as weird as hg-git I would expect :-)
<jelmer> ronny: The working tree status update stuff will be introduced at some point, when I get around to improving the speed of "bzr st"
 * knielsen hopes this bug doesn't mean our trees are corrupted: https://bugs.launchpad.net/bzr/+bug/375898
<ubottu> Ubuntu bug 375898 in bzr "bzr merge fails: bzr: ERROR: No final name for trans_id 'new-1'" [Undecided,New]
<jelmer> knielsen: I think I have seen that bug report before somewhere
<ronny> jelmer: not sure, hg git seems to do fine as it doesnt enable support for git workdirs/repos, just communication to them
<ronny> at least thats my understanding
<jelmer> ronny: How is that less weird though/
<jelmer> ?
<ronny> jelmer: the really weird behaviour i kinda saw was when running bzr commands within a git dir, i cant recall it atm and i wont reinstall
<ronny> hmm
<ronny> is there a way to use bzrdir create_branch_convience and get a branch back?
<ronny> or should i just add an extra open_containing?
<igc> morning
<jelmer> hi Ian
#bzr 2009-05-26
<GaryvdM> Hi igc
<igc> hi jelmer, GaryvdM
 * igc lunch
<LarstiQ> ronny: create_branch_convenience returns the branch as a result
<ronny> LarstiQ: then something is weird, i got none, let me check again what i did break
<ronny> ok, pdb sucks
<mwhudson> LarstiQ: i guess you're not here at uds?
<LarstiQ> mwhudson: correctly guessed.
<mwhudson> boo
<LarstiQ> mwhudson: I will be at EuroPython fwiw.
<LarstiQ> mwhudson: yeah :/
<mwhudson> i won't, but oh well
<LarstiQ> mwhudson: what would be the next intersection point?
<ronny> LarstiQ: ok , pretty much found the issue - pdb wont print bzr branches when typing them in, wraping str/repr around kinda fixes it
 * LarstiQ blinks at ronny 
<LarstiQ> ronny: the print fine in ipython, I wonder what pdb is doing?
<mwhudson> LarstiQ: coming to lca? :)
<ronny> no idea, defered finding the issue
<LarstiQ> mwhudson: eh, I'll take it into consideration, will have to look for travel sponsorship I guess :)
<mwhudson> yeah, that's the problem
 * igc dinner
<LarstiQ> igc: eet smakelijk
<mwhudson> i guess there will be other bzr sprints
<ronny> LarstiQ: ok, pdb itself is pretty much broken, and nothing to easy fix
<LarstiQ> mwhudson: yeah
<LarstiQ> ronny: does ipdb fare any better?
<ronny> LarstiQ: no idea, afair thats not in py.test
<LarstiQ> ronny: something like --enter-pdb-on-error?
<ronny> yes
<LarstiQ> right, probably not then
<hsn_> you guys are working on versioned properties aka editable commit messages?
<jelmer> hsn_, I'm not aware of anybody actively working on it, but there are some vague plans for it
<mwhudson> jelmer: could mrevell and i get you to write a little paragraph on why bzr-get kernel imports don't work yet?
<mwhudson> (for the launchpad blog)
<jelmer> mwhudson: sure
<mwhudson> jelmer: thanks
<mwhudson> jelmer: email it to me?
<jelmer> igc, hi
<jelmer> mwhudson, I hope evolution cooperates long enough for that to be possible :-)
<mwhudson> jelmer: heh
<mwhudson> jelmer: you can sms it to me if that doesn't work? :)
<igc> hi jelmer
<igc> hi mwhudson
<mwhudson> hi ig
<mwhudson> c
<jelmer> igc: Thanks for the send review; I think I might've read more into your original review after seeing bzrlib.version_info
<igc> jelmer: yeah - sorry for the multiple round trips
<igc> jelmer: btw, is there an easy way for me to benchmark your bencode revision stuff?
<igc> I could fastimport OOo again but I was wondering if there was a quicker script for just converting the revisions?
<jelmer> igc, No worries
<lifeless> igc: to microbenchmark the revisions, use the serializer interface directly
<mwhudson> beuno:
<awilkins> jelmer: Would a fastimport that produces a bzr-svn compatible branch be feasible
<igc> hi lifeless, sure
<awilkins> jelmer: The bzr-svn behaviour of holding a whole revision in memory requires some heavy iron for some repositories
<poolie> hello
<igc> awilkins: in theory, yes
<igc> it's doesn't yet though
<igc> awilkins: I'm pretty sure the fast-import code is designed though so that the rev-ids could be bzr-svn compatible (if we added some way of enabling that)
<igc> hi poolie
 * igc bbl - time to get the kids to bed :-)
<jelmer> awilkins, It shouldn't actually keep the contents of the revision in history
<igc> night all
<poolie> night igc
<ronny> hi
<ronny> is there any simple way to get the workingtree of a branch in case them sharing the same path?
<jelmer> they share a container
<jelmer> You can use something like b.bzrdir.open_workingtree()
<ronny> jelmer: oh, intresting, that should do
<jelmer> ronny, it'll raise bzrlib.errors.NoWorkingTree if there's no working tree present
<ronny> jelmer: the vast differences in terms of separation betwen repo/branches/workdirs and the different sets of syncronisation are still making headaches for me
<ronny> i end up with the issue of lacking a coherent way to create light/heavy checkouts from local/remote locations for all of the vcs's
<awilkins> ronny: If it's any help, I'm using the following ; a .repo folder with the repository in, a `list` file, and then I can synch to the svn stuff by doing  ; for B in `cat list` ; bzr pull -d $B/trunk svn+http://server.com/svn/$B/trunk ; done
<awilkins> ronny: Then I branch each trunk so it has a sibling, local
<awilkins> And take lightweight checkouts of those local branches
<ronny> awilkins: what do you think the context is?
<awilkins> Context?
<awilkins> ronny: Your comment above at 1450
<ronny> awilkins: but im not talking about bzr/bzr-svn
<awilkins> ronny: Fair enough
<mrevell> hey jelmer, were you able to look at that paragraph for the Launchpad blog post?
<beuno> mwhudson, ping
<jelmer> mrevell, Sorry, I forgot about it. Michael just reminded me about it and I'm working on it now
<mrevell> ah thanks :)
<bialix> jelmer: hi
<jelmer> Hi bialix
<bialix> may I ask about some strange bzr-svn behavior?
<jelmer> bialix: sure, np
<bialix> I've tried to catch you yesterday
<bialix> I've branched svn repo from http://projects.serverzen.com/pm/p/cluemapper/browser/ClueBzrServer/trunk
<bialix> I can see the log of the branch
<bialix> but when I'm trying to see diff I've got: NoSuchRevision: KnitPackRepository('file:///C:/Temp/ClueBzrServer/trunk/.bzr/repository/') has no revision rocky@serverzen.com-20090226184017-m3cemyrz487uxhg3
<bialix> this svn repo contains bzr branches inside
<bialix> or used bzr-svn to interact with
<bialix> I see many ghost merges
<bialix> does I branch trunk in wrong way?
<bialix> I'm using bzr 1.14 (for Windows) with bzr-svn 0.5.4
<bialix> jelmer: ^
<jelmer> bialix, That URL doesn't actually work for me, are you sure it contains a Subversion repository?
<bialix> I've used this command: bzr get https://dev.serverzen.com/svn/cluemapper/ClueBzrServer/trunk
<bialix> the first URL is Trac site URL
<jelmer> bialix, I think this may be a bug that's fixed in 0.6.1
<bialix> entire svn repo root at https://dev.serverzen.com/svn/cluemapper/
<jelmer> bialix, At least, branching that URL works fine here
<bialix> branching is OK
<bialix> try to run bzr diff -c8
<bialix> in your copy
<bialix> of that branch
<bialix> does it work for you?
<jelmer> bialix, that breaks here as well and is a bug in Bazaar dealing with diffing ghosts
<jelmer> there's an open bug report about it I think
<LarstiQ> bialix: does branching the bzr branch work?
<LarstiQ> bialix: and or running `bzr reconcile`?
<bialix> but... it seems this ghost revisions were created with bzr and then pushed back to svn repo
<bialix> LarstiQ: hi
<LarstiQ> bialix: if they bork, I think I know which bug it is
<LarstiQ> a rather elusive one :/
<bialix> LarstiQ: what do you mean by: "does branching the bzr branch work?"
<LarstiQ> bialix: 'bzr branch svn:/// foo; bzr branch foo test'
<bialix> yes, this works
<LarstiQ> bah :)
 * LarstiQ hoped to have found a way to reproduce a bug of his
<bialix> try yourself. there is only 15 revisions
<jelmer> LarstiQ, it's a known bug, where bzr diff tries to get the file mtime of a ghost text
<jelmer> LarstiQ, different from the one you and Ted Gould have been hitting
<bialix> jelmer: but why there is ghost?
<LarstiQ> jelmer: k
<bialix> jelmer: run bzr log --show-ids
<jelmer> bialix, There are ghosts because there have been pushes into svn with just the mainline, not the merged revisions.
<bialix> it looks like these revisions have pushed using bzr-svn
<jelmer> bialix, Sure
<poolie> lifeless: are you home now?
<bialix> perhaps I don;t understand how bzr-svn push works
<jelmer> bialix: So, if you use "bzr push" from bzr-svn and have "push_merged_revisions = False" it only pushes the revisions on the mainline into the branch you're pushing into
<bialix> jelmer: branching entire project with command: bzr get https://dev.serverzen.com/svn/cluemapper/ClueBzrServer
<jelmer> bialix, so the right hand side revisions end up as ghosts if you later try to get them out again
<bialix> this one does not have ghosts
<jelmer> bialix: This is all expected behaviour
<jelmer> bialix, except that Bazaar doesn't handle the ghost case very well in diff
<jelmer> but that would also happen in other situations in which we end up with ghosts
<jelmer> it's nothing to do with bzr-svn
<bialix> jelmer: I think there is something strange
<bialix> these revisions ARE in the svn repo
<bialix> I've just get entire project with trunk-branches-tags and now I don't have this error
<bialix> it looks for me that when I get only trunk bzr-svn does not try to get corresponding merged revisions from branches/
<bialix> looks like bzr-svn round-trip breaks somewhere in the middle
<jelmer> bialix, in that case there's two bugs here, one in bzr and one in bzr-svn
<jelmer> bzr-svn missing revisions during fetch
<bialix> maybe
<bialix> you're the master of bzr-svn, not me
<bialix> I hope you understand what's going on better than me
<bialix> maybe it's another use case for colocated branches
<jelmer> How are colocated branches related to this?
<bialix> pull all related branches from svn repo at once, maybe
<bialix> GaryvdM around?
<GaryvdM> Hi bialix
<bialix> hi Gary
<bialix> I found that qlog does not show ghost merged revisions in revision properties. Is it right?
<GaryvdM> Done the log -> diff changes. Just doing some testing before I push.
<jelmer> bialix, pull is already supposed to pull in all merged revisions
<GaryvdM> bialix: I have never found a way to create a branch with ghosts, so I've never been able to test how it behaves.
<bialix> GaryvdM: try this: bzr get https://dev.serverzen.com/svn/cluemapper/ClueBzrServer/trunk
<bialix> and then compare output of bzr log --show-ids and qlog
 * GaryvdM installs bzr-svn
<bialix> jelmer: so it's a bug in bzr-svn then
<awilkins> bialix: Is cluemapper a SNOMED-CT product?
<bialix> GaryvdM: I can push to lp
<bialix> awilkins: I don't know, saw the link from Gary yesterday
<GaryvdM> don't worry - allready branching.
<bialix> http://projects.serverzen.com/pm/p/cluemapper
<bialix> awilkins: ^
 * awilkins looks
<awilkins> Ok then, no it isn't
<awilkins> Sorry, we have this thing called CLUE
<awilkins> And mapping is a logical thing to do with the stuff it manages
<jelmer> bialix, trying to verify that now
 * bialix waves
<jelmer> GaryvdM, bzr revert -rtag:bzr-svn-0.5.4
<mwhudson> james_w: jml is looking for you
<james_w> mwhudson: room 12
<mwhudson> jml has now run away, damn him
<james_w> damn him indeed
<poolie> estella damm
<GaryvdM> pygi: http://sourceforge.net/project/showfiles.php?group_id=121075&package_id=132255
<LarstiQ> poolie: ah, found the barcelona beers? :)
<pygi> poolie: the icons are working :p
<hsn_> what command is used for setting parent branch?
<poolie> pygi: yay
<LarstiQ> hsn_: `bzr pull --remember parent/url`
<hsn_> LarstiQ: thanks
<trondn> Hi folks :)
<trondn> is there any speed improvements planned for the "bzr log -v" command??? currently it takes 7 minutes on a branch from lp:drizzle on my 2.4ghz quad core box (with 4gb ram)...
<poolie> trondn: it should be much faster in the development-rich-root format
<trondn> poolie: can I convert my repository to this format?
<trondn> the reason I ask is because I need it for OpenGrok (see http://src.opensolaris.org/source if you want to see it in action)... I need to get the complete list of files in each revision along with the commit message...
<poolie> trondn: yes, but there are two caveats: this format is still in beta for a 2.0 release later, so there will be bugs
<poolie> and the conversion takes some time
<poolie> like hours, for a large branch
<poolie> also, there are some log improvements coming up soon
<poolie> even for other formats, so just using 1.15 may help
<trondn> poolie: I'm running 1.15 already :)
<trondn> great to know!
<trondn> Right now this is the biggest problem I have with bazaar :-)
<poolie> trondn: so this is just a readonly mirror?
<poolie> then i'd definitely recommend upgrading
<poolie> you can still pull from lp:maria
<poolie> i mean lp:drizzle
<poolie> and we'd like to hear your feedback
<trondn> poolie: Yeah, the browsing will be from a readonly mirror :-)
<trondn> poolie: I am currently using it (opengrok) to index mercurial repositories with over 76 gb disk footprint on src.opensolaris.org. I would like to have the same search options on the source I am working on from launchpad (btw. I love the complete integration of everything on lp!! nice work :) )
<poolie> thanks!
<schmichael> how do i get diff (preferably colorized somehow) output in vim when i'm writing a commit message?
<fullermd> Well, the colorizing would be vim's turf.
<fullermd> But try ci --show-diff
<schmichael> fullermd: cool thanks, anyway to make --show-diff the default behavior of ci?
<fullermd> I have it aliased.
<schmichael> seems setting filetype=diff or filetype=<lang> in vim pretties it up a bit, wonder how to make that automatic
<fullermd> au BufEnter bzr_log.* <whatever>
<schmichael> fullermd: i owe you a beer ;-)
<schmichael> thanks
 * fullermd has his uses   8-}
<rindolf> Hi all.
<rindolf> What is the equivalent of svn export for http://bzr.savannah.gnu.org/r/gnash/trunk ?
<rindolf> I want a snapshot of the sources. Don't care about the history.
<schmichael> rindolf: bzr export dest http://bzr.savannah.gnu.org/r/gnash/trunk
<rindolf> schmichael: thanks!
<rindolf> schmichael: is bzr export like that faster than doing bzr branch?
<LarstiQ> rindolf: I haven't looked at it, but I can imagine a worst case in which it's slower than bzr branch
<LarstiQ> rindolf: so, I wouldn't place faith in statements about it's speed without backing it up with some evidence
<rindolf> LarstiQ: ah.
<LarstiQ> rindolf: exporting a revision tree is not a usecase the storage is optimized for
<schmichael> rindolf: yeah, bzr repos are compressed so they might actually be signficantly smaller than the working copy if the project has little history and easily compressed files (i think ;) )
<LarstiQ> rindolf: test it I say! :)
<rindolf> LarstiQ: I'm trying to download a gnash snapshot.
<rindolf> I gave up on bzr branch because it took so long.
<rindolf> But bzr export downloaded 167408KB so far
<schmichael> damn!
<emmajane> beuno, ping!
<emmajane> beuno, http://wiki.services.openoffice.org/wiki/Renaissance/Design_Proposals_for_%E2%80%9CAccessing_Functionality%E2%80%9D <--- usability testing for OOo
<Peng_> mwhudson or beuno: ping
<mwhudson> Peng_: hi, about to go to sleep; send email
<Peng_> mwhudson: D'oh. One quick question? :D
<Peng_> mwhudson: Anyway, good night. :)
<mwhudson> Peng_: ok
<Peng_> mwhudson: The "bzr serve" registry landed in bzr.dev. Do you want to keep the code to override cmd_serve for a few months?
<Peng_> Or can we break compatibility now?
<mwhudson> hmm
<mwhudson> don't konw
<mwhudson> ask beuno :)
 * mwhudson zzzz
<Peng_> mwhudson: Okay. :)
<lifeless> Peng_: delete it; label the release as requiring a minimum bzr
<Peng_> lifeless: Sure, but backwards compatibility is nice, and no extra effort.
<lifeless> Peng_: you did ask :)
<LarstiQ> imo, I'd raise the minimum bzr version after there is another release of bzr
<Peng_> lifeless: :P
<lifeless> LarstiQ: sure, I have no strong opinion
 * LarstiQ nods
<LarstiQ> lifeless: my condolences btw
<lifeless> LarstiQ: thanks
<Peng_> Oh, that's right. My condolences as well, lifeless.
<lifeless> Peng_: thanks
<cellofellow> how do I enable the bazaar nautilus integration? I have bzr-gtk installed.
<robey> hey guys... my coworker is getting an OOPS for any "bzr branch lp:(anything)"
<robey> and i do too... is launchpad down or something?
<Peng_> robey: It's read-only for maintanence right now.
<robey> yeah the website says that, but even "branch" fails
<Peng_> I guess the XML-RPC server didn't take it well.
<robey> i'm hoping there's something simple we're missing cuz this is his first impression of bzr after i've been promoting it for months, and he has the rage
<robey> it looks completely broken :(
<Peng_> Launchpad looks completely broken, not bzr.
<robey> i doubt he cares about that distinction... oh well. :(  thanks
<cellofellow> robey: too bad for your friend. Have any local branches he can branch?
<dash> so give him a non-launchpad url
<Peng_> Looks like bazaar.lp is down as well.
<robey> it's something hosted on launchpad, and launchpad only seems to advertise the lp: names these days... i couldn't find any page that divulged the real url
<cellofellow> robey: but maybe you could use `bzr serve` and he branch from your copy.
<Peng_> Like I said, bazaar.lp is down anyway.
<robey> i've never fetched that project
<cellofellow> ah
<robey> nevermind, i think the damage is done. thanks for helping tho.
<Peng_> Oh, good, lp: URLs work again. Though bzr+ssh://bazaar.lp.net doesn't.
<Peng_> ...Which makes sense if it's read-only, I guess...
<cellofellow> too bad robey is gone
<Peng_> robey's friend isn't very patient
<cellofellow> :(
#bzr 2009-05-27
<evn> i'm trying to use git-serve and get the following error
<evn> ~ $ bzr git
<evn> No module named foreign
<evn> on Bazaar (bzr) 1.13.1
<evn> where does the 'foreign' package live?
<evn> :-(
<evn> anyone?
<emmajane> evn, This was part of jelmer's branch and apparently it was rolled into the main bzr, but I'm just going on past log files.
<emmajane> http://irclogs.ubuntu.com/2009/02/06/%23bzr.html
<emmajane> evn, the same thing was true in March as well.
<emmajane> http://irclogs.ubuntu.com/2009/03/09/%23bzr.html
<evn> i have a more recent version of bzr than that so it should be there, right?
<emmajane> evn, "should be" but also "doesn't appear to be"
<evn> should i try to downgrade bzr?
<emmajane> I don't know what the right answer is, sorry.
<emmajane> Previously the right answer has been to (1) use bzr.dev or (2) jelmer's PPA.
<emmajane> I don't know if either of those are still true though.
<evn> hrm
<evn> i have the latest bzr from macports
<emmajane> You have the latest "released" bzr, this isn't the same as the "development" verison.
<evn> oh
<Peng_> 1.13.1 isn't the latest release anyway.
<emmajane> I *think* jelmer is at UDS this week (in Spain) so you could try again tomorrow.
<emmajane> Unless Peng_ happens to know the right answer. ;)
<evn> should i try to get https://launchpad.net/bzr/bzr.dev
<evn> ?
<evn> or would 1.15 have what i need
<Peng_> I don't know.
<emmajane> http://bazaar-vcs.org/BzrForeignBranches/Git/Server
<evn> yeah, that's what i'm trying to use
<emmajane> evn, Have you read through the page and followed all the links?
<evn> yeah
<evn> i installed dulwich
<evn> and git-serve as a plugin
<emmajane> When I read that page I don't see anything that says, "This is available in bzr as of version X."
<emmajane> So I would assume that you have to use the development version that is referenced near the top.
 * Peng_ goes /away
<evn> lp:~johncarr/bzr-git/git-serve ?
<evn> that's the plugin, not an actual version of bzr
<emmajane> evn, Your best bet is to try and catch jelmer tomorrow.
<evn> ok
<emmajane> He was around today off and on until about two hours ago.
<evn> i installed bzr 1.15 and now i get
<evn> Unable to load plugin 'rebase'. It requested API version (1, 13, 0) of module <module 'bzrlib' from '/opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/bzrlib/__init__.pyc'> but the minimum exported version is (1, 15, 0), and the maximum is (1, 15, 0)
<evn> oh nm
<evn> it still says No module named foreign
<evn> giving up for today
<LaserJock> anybody know specifically what Launchpad is using for git imports?
<johnf> Interesting bug. If anyone ever complains they can't add a directory containing a directory called objects then it could be because of bzr-git #380818
<wgrant> LaserJock: bzr-git
<kfogel> Anyone here used bzr-search plugin?  I just did (in the plugin's own directory) 'bzr index' followed by 'bzr search string_that_is_definitely_in_a_file_here', and it claimed no hits.
<Peng_> I have used bzr-search, but I can't help much.
<Peng_> Does .bzr/bzr-search look populated?
<Peng_> Are you sure about the search string? Try something dumb, like "for". What about suggestions?
<kfogel> Peng_: yes, it's there, and has stuff in it.
<kfogel> Peng_: got it.
<kfogel> Peng_: PEBKAC
<Peng_> Okay.
<mwhudson> jelmer: https://code.edge.launchpad.net/~vcs-imports/mnemosyne-proj/maemosyne
<pygi> GaryvdM: pass the lp:~mario-danic/bzr/bzr-win branch to villa :)
 * igc dinner
<pygi> vila: greetings :p
<vila> pygi: Haaaaaa, finally I link the nick and the human being ! :)
<pygi> vila: hahahhaha :D
<pygi> vila: lp:~mario-danic/bzr/bzr-win will be the branch for the win installer automation stuff
<vila> pygi: yeah !
<pygi> mvo: poke
<johnf> abentley: ping
<abentley> pong
<johnf> abentley: any chance of a bzrtools release for 1.15
<johnf> or isn't one needed/
<johnf> ?
<abentley> There should be a release for 1.15.
<abentley> johnf: I'll do it tonight.
<johnf> thanks could you ping me when your done so I can roll it out to the PPA
<abentley> johnf: Okay.
<johnf> So if I emailed a patch for merging and it's in budle buggy and someone has commented on it with some small changes. What is the process for for fixing the patch. Do I just reply to the email from bundle buggy with a new patch?
<konnertz> hi, is it possible to have ehmm... three(?) repos "in a row"?
<Peng_> konnertz: What do you mean?
<mwhudson> jelmer: http://launchpadlibrarian.net/27200360/gitorious-trunk-log.txt <- thoughts?
<Peng_> johnf: If it was just bb:tweak, you can resubmit the fixed patch, or perhaps someone will fix it up while merging it.
<Peng_> mwhudson: G'morning. :)
<konnertz> i mean i develop a web framework useful for my company but also for me (and maybe others), atm i use svn on my root server
<konnertz> but i should make it accessible to alle coworkers asap
<johnf> Peng_: as in just send a brand new email? Won't that create two merge requests?
<konnertz> but i want to continue working also at home and on laptop
<Peng_> johnf: Yes, send a reply. It will create a new merge request, but I think they'll be sort of linked. Anyway, the (minimal) administrative overhead of that is exactly why sometimes the person merging it will take care of it.
<konnertz> so where should be the central repo? Or is this a misconception?
<johnf> Peng_: Ok it's just a tweak for spelling and a branch name so I'll leave it
<Peng_> konnertz: Bazaar is a DVCS. You don't /need/ a central repo. If you want one, you can put it wherever you want.
<konnertz> Are all repos equally? And can changes be merged from A to B or from B to C and also from C to A ??
<LarstiQ> Peng_, johnf: if the old patch is in the ancestry of the new one, they'll be subsumed into one by BB
<Peng_> konnertz: Yes.
<konnertz> Peng, okay.
<johnf> LarstiQ: ahh ok cool
<kfogel> jelmer: http://paste.lisp.org/display/80898   -- a 'bzr search' error on a package you are familiar with.
<konnertz> so just another question pls to get into it again - i already setup two test projects some weeks ago and tried the basics, ...
<konnertz> To start the first repo, i could start it on my local box, right?
<konnertz> what cmd pls for my needs of decentral VC?
<Peng_> konnertz: You can start it wherever you want.
<Peng_> konnertz: Read the tutorial. :)
<pygi> Guest52322: :p
<pygi> hiding :D
<Guest52322> whoops
<jelmer> mwhudson, I can reproduce that bit unfortunately
<jelmer> mwhudson, Do you have some easy way to file bugs from failed vcs imports ?
 * jelmer wonders if gitorious is perhaps running a custom server
<awilkins> .join ##csharp
<awilkins> oops
<awilkins> Any loom gurus here?
<awilkins> I was just thinking ; do looms have to be 2-dimensional (a stack of branches) ; could you have levels that fan out
<fullermd> A stack isn't 2-dimensional   :p
<awilkins> fullermd: Well, they are stacks of 1-dimensional things
<awilkins> fullermd: So I was thinking that was 2-d
<awilkins> Stacks of linked lists (or DAGs)
<awilkins> The problem I was thinking about was the maintaining-a-development-branch-with-multiple-patches-to-the-trunk
<awilkins> Where you want each patch branch to be distinct and separate so that you can submit it for merging independantly
<awilkins> but also want your development branch to hold them all
<ronny> how can i get the tip revision of a branch, i cant find it in the branch api
<awilkins> ronny: Get revision -1 ?
<ronny> awilkins: but what api is for getting the revisions, i only found sometihng for trees
<awilkins> ronny: Not sure about that
<awilkins> http://imagebin.org/50545  ;
<ronny> oh, looks like hg's pbranch
<mwhudson> ronny: branch.last_revision() ?
<awilkins> It sounds just like what loom is for, maybe I'm just not grokking it
 * awilkins wonders if there's a qloom
<ronny> mwhudson: that gives the id, now im in search of a way to get a revision object
<ronny> i did get one over a cahin of other things that is probably tooooo complicated
<ronny> oh.found it
<mwhudson> ronny: b.repository.get_revision(b.last_revision())
<ronny> wt.branch.repository.get_revision(wd.last_revision())
<ronny> hmm, and now to figure a way to do push/pull from the api
<Peng_> Not to be an ass, but has everyone forgotten about https://code.edge.launchpad.net/loggerhead/+activereviews ? There are several things up for review.
<Peng_> I'm not demanding you review them or anything. I just want to be sure they're on the radar somewhere.
<mwhudson> Peng_: UDS!!@!@!!one!
<Peng_> mwhudson: As an outsider, UDS seems terribly unproductive. Development has shut down. You're not just playing video games, are you? :P
<mwhudson> heh
<mwhudson> no
<ronny> how would i go about invalidating a branch/repository instance in case the on-disk data got changed
<mwhudson> ronny: if you don't read lock, the disk gets consulted each time (i think)
<ronny> mwhudson: i did a push, and it didnt seem to change
<LarstiQ> ronny: .lock_read,write() and .unlock()
<awilkins> ronny: Was the push over a remote transport?
<LarstiQ> awilkins: that would be a ondisk tree state you're thinking of, not the Branch/Repository objects in python?
<awilkins> LarstiQ: Yes
<LarstiQ> ronny: if I do in ipython; b.last_revision(); *push outside*; b.last_revision(), the two revisions are different
<ronny> hmm, same process here
<ronny> part of the unittests, using different instances to the same data
<LarstiQ> are you sure you're  pushing to the underlying branch, not somewhere else?
<LarstiQ> if you are, I'm out of ideas without seeing the code
<ronny> LarstiQ: its the same branch i push to, but not the same branch instance
<ronny> currentlyim in an iteration of adding some crap to anyvc
 * LarstiQ nods
<LarstiQ> I literally did: import bzrlib.branch; b = bzrlib.branch.Branch.open('/tmp/foo'); b.last_revision(); b.last_revision()
<LarstiQ> and for the pushing, bzr branch /tmp/foo; cd foo; bzr ci -m 1 --unchanged; bzr push /tmp/foo
<ronny> unittest is the default_head one in http://paste.pocoo.org/show/119370 and the bzr repo code is http://paste.pocoo.org/show/119374
<LarstiQ> ah, but it doesn't invalidate if it didn't start at the null-revision, hmm
<ronny> ignore the bad api, its still in the early iterations where i try to add stuff, and make simple tests work
<ronny> it needs a good deal of more iterations
<ronny> LarstiQ: so any idea what i can do?
<LarstiQ> ronny: not yet, looking still
<LarstiQ> ronny: some things seem to have changed since last I looked
<ronny> hmm, darn
<LarstiQ> GAH I'm stupid
 * LarstiQ was checking the wrong branch
<pygi> vila: sidney won't come I guess
<LarstiQ> now that the universe works again like I think it does, back to looking at anyvc code
<LarstiQ> ronny: the assert head.message=="test commit" fails?
<vila> pygi: lokks like so, we should hunt him tomorrow :)
<ronny> LarstiQ: no, after the push from the workdir it doesnt have new revision
<pygi> vila: we have to be here tomorrow as well? xD
<LarstiQ> ronny: wd.repository.push() ?
<ronny> in my case workdir = separate branch
<ronny> that push seems to work fine, but te repo wont get the change
<LarstiQ> what is wd.repository.branch.get_parent() ?
<ronny> hmm, ok, the push seems to fail
<ronny> LarstiQ: hmm, a string, but somehow i failed to get a propper bool value for repository
<igc> night all
<LarstiQ> night ian
<ronny> LarstiQ: so, the bzr test passes now
<LarstiQ> ronny: yay :)
<ronny> LarstiQ: i just did the same for hg and it took vastly less time to implement
<LarstiQ> ronny: how much of that is because you already know hg better?
<ronny> LarstiQ: hg lacks much indirection, so there is much less to figure
<mwhudson> what does an exit code of 4 mean for bzr?
<mwhudson> and is having this exit code at all a new thing?
<ronny> brb
<beuno> Peng_, thanks for the review
<replicant> is the fastest repository format 1.9 ?
<beuno> Peng_, what should I do with the serve-fix branches then?
<james_w> mwhudson: EXIT_INTERNAL_ERROR = 4
<mwhudson> ah
<mwhudson> soooooooooooooooooommmmmmmmmmmething is breaaaaaaaaaaaaaaking
<mwhudson> then
<mwhudson> (i love integration tests)
<james_w> maybe your keyboard?
<mwhudson> heh
<jml> :D
<mwhudson> i also love testsuites that take multiple hours
<jml> bzr defines constants for those things?
<jml> We should heck of use those.
<mwhudson> beuno: review the branch i guess :)
<mwhudson> yeah
<james_w> bzrlib.errors
<jml> james_w: why aren't you in the bzr room with all of the cool people?
<james_w> jml: I am in the etckeeper room with the extra cool bzr people
<jml> ahh.
<jml> good idea.
<OllieR> is it possible to suppress the bzr ouput for comands like bzr add ?
<james_w> bzr add -q
<OllieR> james_w: ty
<james_w> it won't be completely silent though
<OllieR> better than nothing, just doing an add over ssh on a large branch takes far too long due to slow downloads of all the files
<nadavoid> I'd like to use a command like "bzr push sftp://your.name@example.com/~/public_html/myproject"
<nadavoid> My username at the sftp server has an @ or a % in it.  I can log in using either.
<mwhudson> Peng: hello, please land that branch :)
<Peng_> mwhudson: Which branch?
<mwhudson> the one i just reviewed
<nadavoid> I can successfully SFTP in using serveradmin@example.com and serveradmin%example.com.
 * mwhudson is running out of battery and brain at fairly similar rates
<nadavoid> But when I try bzr push with those usernames, I get access denied.
<nadavoid> It's like the % gets converted to something else.
<nadavoid> Any suggestions on what I can try? (so I can bzr push to an sftp server using a username that has a % in it.)
<Peng_> mwhudson: Thanks for the review.
<mwhudson> Peng_: np
<Peng_> landed
<Peng_> Will I bother to add NEWS? :P
<mwhudson> ah yeah NEW
<mwhudson> S
<mwhudson> Peng_: can't you use url_to_local_path to detect local paths in https://code.edge.launchpad.net/~mnordhoff/loggerhead/dont-suggest-serving-remote-branches/+merge/6758
<Peng_> Eh, I added NEWS.
<Peng_> mwhudson: Yeah, I could. Like I wrote, I don't know the right way to do it, so I just picked what looked simplest.
<mwhudson> it seems more principled somehow
<Peng_> It bothers me a little because the local path isn't actually *needed*, so it'd just be generated and discarded.
<mwhudson> yeah
 * mwhudson approves the branch
<mwhudson> Peng_: have you tested that https://code.edge.launchpad.net/~mnordhoff/loggerhead/dont-suggest-serving-remote-branches/+merge/6758 basically works?
<Peng_> mwhudson: Yes. I don't know *why* setting served_url to None disables the suggestion, but it does. I'd test it again before landing it.
<mwhudson> i added the served_url is None hides the suggestion thing
<mwhudson> for launchpad
<mwhudson> Peng_: actually
<mwhudson> Peng_: i meant to ask about the transport registry branch :)
<fullermd> nadavoid: Try urlencoding it.  @ = %40 I believe.
<Peng_> mwhudson: Oooh. Yes.
<nadavoid> fullermd: thanks. I'll try that.
 * mwhudson reviews that one too
<nadavoid> fullermd: would something like an escape character be needed? like \@ ?
 * mwhudson vanishes in a puff of beer
<Peng_> Cue Firefox crashing before I check LP again.
<danigm> Hi all, I'm trying to setup a bzr server to use with bzr+ssh. I create a group bzr and all users that can create branchs are in that group. I have a directory /bzr with user root and group bzr. An user can create a branch in that dir but any other can write over it. How can I set up for group write permission?
<LarstiQ> danigm: setgid, or what I prefer, setfacl
<danigm> LarstiQ: and how can I do it? I try chmod 2770 to /bzr and all directory created had the same group, but not writable
<LarstiQ> danigm: chmod g+s
<danigm> LarstiQ: I have this, but new files isn't writable
<danigm> by group
<LarstiQ> danigm: then I advise to make use of posix acls
<LarstiQ> danigm: `setfacl -m group:bzr:rwx  /srv/bzr` and `setfacl -m default:group:bzr:rwx /srv/bzr`
<LarstiQ> danigm: is what I did
<danigm> LarstiQ: ok, I'll try it
<Peng_> mwhudson: Thanks for all of the reviews. :)
<nadavoid> fullermd: urlencoding the @ as %40 in my username worked perfectly for me.
<nadavoid> fullermd: thanks again.
<LarstiQ> fullermd: could you file a bug on that?
<LarstiQ> ehm
<LarstiQ> s/fullermd/nadavoid/
<nadavoid> LarstiQ: uh, sure. where?
<LarstiQ> nadavoid: https://bugs.edge.launchpad.net/bzr/+filebug
<nadavoid> LarstiQ: ok. I'll do that. Let ask a couple questions about what some valid sftp urls "should" be then...
<nadavoid> This is obviously valid: sftp://your.name@example.com/~/public_html/myproject
<LarstiQ> yes
<nadavoid> This has an added %: sftp://your%name@example.com/~/public_html/myproject
<nadavoid> And this has an added @: sftp://your@name@example.com/~/public_html/myproject
<nadavoid> Should both of those last two work?
<LarstiQ> I think the client should handle them better than it does now, wether they're valid sftp urls or not.
<LarstiQ> vila: you might now better ^^?
<nadavoid> I don't know better. ;) I'll go ahead and mention both, and let the bzr devs sort out how it should be handled.
 * LarstiQ nods
<vila> Well, aliasing ~ to user home directory is not really standard AFAIK, a single % is definitly not standard, it should be escaped as well as the @
<vila> Now, there has been discussions about being a bit more tolerant as far as bzr is concerned,
<vila> so we indeed support ~, I seem to remember a patch about better supporting the @ without forcing it to be escaped, but the % will still be a problem
<nadavoid> vila: I'd be happy if that was mentioned in the getting started guide "If your username has an @ or a % in it, be sure to enter it escaped as %40 or %25."
<vila> nadavoid: patches welcome :)
<vila> nadavoid: there is also the question about whether we should include std66 in the documentation...
<nadavoid> Looks like this is already being addressed as a "bug" https://bugs.edge.launchpad.net/bzr/+bug/215059
<ubottu> Ubuntu bug 215059 in bzr "Cannot push if login is an e-mail address" [High,Fix released]
<nadavoid> mentioning std66 might be good in the full documentation, but probably not in the 5-minute quickstart.
<nadavoid> vila: How would I submit a patch for the 5-minute quickstart?
<nadavoid> http://doc.bazaar-vcs.org/bzr.dev/en/mini-tutorial/index.html
<vila> nadavoid: search for the doc/en/mini-tutorial directory in the sources
<nadavoid> ok.
<danigm> which users use bzr serve?
<LarstiQ> danigm: everyone using bzr+ssh://
<nadavoid> vila: then I create a patch, and attach it to a bug report?
<vila> nadavoid: we prefer merge proposals on launchpad.net, see doc/en/developers/HACKING.txt
<LarstiQ> nadavoid: Preferably use Launchpad to suggest merging your branch, or use `bzr send` to send a merge directive to the mailing list.
<nadavoid> OK. I might give that a try. Thanks for the suggestions.
<danigm> with bzr serve anyone can write in my server, and with bzr+ssh I can share branchs because acl is too instrusive
<LarstiQ> danigm: I'm not sure what you mean?
<danigm> LarstiQ: I'm trying to launch bzr serve, but with that it not needded to put your user and password to create or modify a branch
<danigm> I can create a branch without a user
<danigm> And I don't want that
<LarstiQ> danigm: if you run it standalone (ie, bzr://) and you supply --allow-writes, then yes, anyone can write branches
<danigm> LarstiQ: It's possible to launch standalone with write support for only users?
<LarstiQ> danigm: you could have a look at http://projects.serverzen.com/pm/p/cluemapper/wiki/ClueBzrServer
<danigm> LarstiQ: finally I use acl and it works
<LarstiQ> danigm: glad to hear
<axxman> Has anyone had trouble getting apache to allow access to the .bzr/branches/format file? It seems to just be unwilling to show any file named "format" for some reason...
<ronny> sup
<ronny> Guest12468: jelmer: is there any eta for when dulwich can read git status information? im kinda pissed off cause i need 3 subprocess calls
<ronny> (wd, inex and tree=
<jelmer> ronny, So, "git status" is a bit ambiguous. I'm likely to implement whatever bzr-git needs soon, what is the data that you need exactly?
<jelmer> ronny, Whatever bzr-git needs to yield the results required for "bzr status" that is
<ronny> jelmer: so it will be semilar to iter_changes from bzr branches?
<jelmer> ronny: Not similar, it'll be something that makes sense in the git model
<jelmer> but what I will put in is driven by bzr-git, basically
<ronny> jelmer: the index is a huge pain
<ronny> at least dulwich is really great for dealing with the history
<ronny> jelmer: is writing objects already in somewhere, my very light skimming of the api didnt reveal something like that
<jelmer> ronny: Is there any chance I could get you to describe the API of the function you're looking for?
<jelmer> ronny, That way I can make sure whatever I'll implement is sufficient for what you need
<ronny> jelmer: im in early stages of evolving how i get metadata access in anyvc
<jelmer> ronny, dulwich can write new commits, based on an index object and an object store
<ronny> jelmer: so no entirely in memory commit builder yet?
<ronny> jelmer: anyway, my needs for workdir states is partially collected in http://bitbucket.org/RonnyPfannschmidt/anyvc/src/tip/anyvc/metadata.py
<jelmer> ronny, (an object store being one of the parts of a repository)
<ronny> there is some other crap in i tought that would be usefull (but i was wrong)
<jelmer> ronny: In memory commit building is possible
<ronny> im not entirely sure if a single string is enough tho
<ronny> jelmer: my current translation of bzr workdir states is kinda messy tho
<ronny> http://bitbucket.org/RonnyPfannschmidt/anyvc/src/tip/anyvc/workdir/bzr.py#cl-54 screams fragile
<ronny> if anyone wants to review/give hints - please now ;P
<mwhudson> jelmer: hello
<mwhudson> jelmer: https://code.edge.launchpad.net/~vcs-imports/live-helper/trunk <- failing git import
<jelmer> mwhudson: hey
<mwhudson> jelmer: https://code.edge.launchpad.net/~vcs-imports/vlc/master <- initial import succeeded, update filed
<mwhudson> failed
<jelmer> mwhudson, If I recall correctly the first I fixed recently in bzr-git
<mwhudson> jelmer: ok
<jelmer> it's an issue that occurs when there are directories that are turned into files or the other way around
<Peng_> jelmer: Oh hi. You misuse lstrip in a couple places in bzr-svn. "food".lstrip("of") -> "d", but you're trying to use it to strip off "of" exactly.
<mwhudson> ah right, that would explain the error a bit
<jelmer> Peng_, Ah, darn
<jelmer> Peng_, Thanks
<emmajane> jelmer, did evn track you down today?
<jelmer> mwhudson, Do you know whether the original vlc import gave any warnings about incorrect modes/commit messages with funny characters?
<jelmer> emmajane: I'm not sure actually, do you know what his fullname is?
<emmajane> jelmer, it was in IRC last night. Question about git/bzr integration and a foreign something not being found.
<mwhudson> jelmer: http://launchpadlibrarian.net/27212948/vlc-master-log.txt <- doesn't look like it, not 110% sure warnings would show up there
<Peng_> jelmer: fwiw, all uses of rstrip and strip are okay.
<mwhudson> jelmer: but yeah it looks like that issue
<emmajane> jelmer, they were trying to follow: http://bazaar-vcs.org/BzrForeignBranches/Git/Server but running into problems.
<mwhudson> jelmer: given that it's vlc, i bet it's commiter names or something
<mwhudson> (lots of french people)
<jelmer> Did you just say that French people cause import errors?
<mwhudson> well
<jelmer> emmajane: No, in that case I haven't talked to them
<mwhudson> they have funny foreign mucky characters in their names
<jelmer> emmajane: Are they here at UDS, do you know?
<emmajane> jelmer, Not as far as I know.
<emmajane> jelmer, it was a question in IRC last night.
<jelmer> emmajane: Ah, sorry
<jelmer> mwhudson, Is that log basically whatever ends up in .bzr.log ? If so, warnings should be in there
<emmajane> jelmer, If they're back tonight in my time zone (North America) is there a specific branch I should point them at to make those instructions work?
<mwhudson> jelmer: it's the stderr, with a somewhat customized uifactory
<jelmer> emmajane: I fixed up the server side implementation yesterday, so unfortunately it'll only work with bzr-git trunk, dulwich trunk and bzr.dev
<jelmer> emmajane: With those three branches, it should be a matter of running "bzr serve --git"
<emmajane> ok
<emmajane> jelmer, if I updated that wiki page to list those three branches could you take a look and make sure what i wrote is true?
<jelmer> emmajane: the BzrForeignBranches/Git/Server one ?
<emmajane> yeah
<jelmer> emmajane, I don't see any changes there
 * emmajane grins. *if* I haven't done them yet.
<emmajane> I just opened the edit page. ;)
<jelmer> Argh
<jelmer> Sorry, my brain is half-asleep :-)
<emmajane> assok.
<emmajane> half a sec and I'll get them written up.
<emmajane> https://code.edge.launchpad.net/~bzr/bzr-git/trunk <--- that's the plugin, right?
<jelmer> emmajane, yep
<emmajane> I'm just trying to figure out what the URLs are for those bzr-git trunk, dulwichi trunk and bzr.dev
<jelmer> emmajane: Dulwich is at http://people.samba.org/bzr/jelmer/dulwich/trunk, bzr.dev is at http://bazaar-vcs.org/bzr/bzr.dev
<emmajane> thanks.
<emmajane> http://bazaar-vcs.org/BzrForeignBranches/Git/Server
<emmajane> updated.
<emmajane> diff here: http://bazaar-vcs.org/BzrForeignBranches/Git/Server?action=diff&rev2=11&rev1=9
<jelmer> emmajane, Thanks, that looks good
<emmajane> \o/
<emmajane> jelmer, I'm amazed you're still awake after the brain fry of UDS. :)
<jelmer> emmajane, Only half :-) But yeah, UDS is quite intense.
<jelmer> I wonder how the Canonical folks deal with 2 weeks of this :-)
<emmajane> jelmer, they're the ones who are already asleep. ;)
<mwhudson> jelmer: badly
<ronny> jelmer: i think the state for git can only be expressed in some kind of tuple, cause the index gets in the way
<jelmer> evn, hi
<evn> oh hey
<jseabold> Hello all, I am relatively new to DVCS and bzr and was wondering if someone might help me out.
<jseabold> I have a working directory that has a different push branch, parent branch, and submit branch.
<jseabold> The push branch is my branch (which I just pushed to from another computer), how do I update the working directory on my other computer with these changes?
<jelmer> evn, emmajane mentioned you were trying to set up bzr-git serve the other day?
<jseabold> bzr update told me I was at the newest revision.
<evn> yeah...it can't find the 'foreign' module
<emmajane> jelmer, thanks :)
<emmajane> jelmer, you rock!
<evn> jelmer: http://pastie.org/491990
<mwhudson> evn: you need a newer bzr, i bet
<jelmer> evn: In order to run the server you need the latest development versions of bzr/bzr-git/dulwich
<jelmer> evn: see also http://bazaar-vcs.org/BzrForeignBranches/Git/Server
<evn> i installed dulwich
<evn> oh that page looks changed
<evn> at least from what i saw yesterday
<evn> i will try it
<bob2> jseabold: if the push was successful, 'bzr up' should update the working copy
<yacoob> hello there.
<yacoob> If I say "bzr ignore '*.pyc'", how come "bzr add *" is still adding those?
<maxb> yacoob: Probably because your shell expands * into an explicit list of files, so it looks to bzr as if you're explicitly telling it to
<mneptok> yacoob: don't quote *
<mneptok> bzr ignore *.pyc
<fullermd> No, you probably want to quote it...
<yacoob> mneptok, no, that's not what I want. I want to ignore ALL .pyc files, and if I don't quote it, shell will expand it and add only specific files
<yacoob> maxb, so explicit bzr add doesn't follow ignore rules? ok.
<yacoob> (they disappeared from bzr status... so that's a good sign :)
<Peng_> yacoob: That's correct. Explicitly adding things overrides ignore rules.
#bzr 2009-05-28
<MTecknology> How do I apply a diff file to a branch?
<bob2> did the diff come from bzr?
<MTecknology> ya
<bob2> why the diff then?
<bob2> instead of using bzr merge or producing a bundle?
<MTecknology> somebody else generated a few diff files and never pushed a branch to let me do a merge with
<bob2> can you ask them to produce a bundle instead?
<bob2> if not, just apply with 'patch'
<MTecknology> how do I apply w/ that command?
<MTecknology> I know there's multiple files changes with each patch file
<Peng_> The person should really generate bundles. With bundles, you'd then use "bzr merge path/to/whatever.bundle"
<MTecknology> I already asked them to
<MTecknology> they won't
<MTecknology> nvm... I figured it out
<jseabold> bob2: I have pushed from my home computer which was revision 1726, then I pushed from work which was 1727, both show up on launchpad, but when I try bzr up it says at newest revision 1726
<jseabold> bob2: maybe I should just try to get the branch again from launchpad?
<GaryvdM> jelmer:http://en.wikipedia.org/wiki/AFB_Hoedspruit
<jelmer> 'evening Bob
<lifeless> hi jelmer
<jelmer> Hi lifeless
<jelmer> How are things?
<lifeless> as well as can be expected
<jseabold> bob2: sorry to bother, but I just had another look at it, and I think it's because when I started the other working directory at work I used "bzr branch" then pushed back to the original place rather than "bzr checkout"
<jseabold> does that sound possible?
<evn> Bazaar (bzr) 1.16dev
<evn> how do i start git-serve now?
<bob2> jseabold: checkout and branch do mostly the same thing
<jseabold> bob2: Hmm, I just tried both and the branch command said "Branched revision(s) 1727" and checkout didn't return any message, so I thought maybe that was the difference.
<evn> jelmer: ^
<jelmer> evn, bzr serve --git
<evn> it appears to work
<evn> should it output anything?
<jelmer> evn, no, not at the moment
<evn> fatal: http://localhost/info/refs not found: did you run git update-server-info on the server?
<evn> is it on some specific port?
<bob2> jseabold: sorry, not sure where you ran these things etc
<evn> oh, something happened
<evn> http://pastie.org/492184
<jseabold> bob2: Right, oh well.  Thanks for the help, but I've got to run.  I'm sure I'll be back if I keep running into this problem...
<jelmer> evn, not sure what's happening there. Any chance you can file a bug?
<jelmer> I don't have time to look into it now unfortunately
<evn> sure...where
<jelmer> launchpad.net/bzr-git
<evn> ok
<jelmer> I don't have time to look into it atm, time for sleep
<jelmer> g'night
<evn> thanks
<evn> https://bugs.launchpad.net/bzr-git/+bug/381143
<ubottu> Ubuntu bug 381143 in bzr-git "bzr serve --git creates an absolute URL with a transport on OS X and then complains about it" [Undecided,New]
<evn> hello there, bot
<Peng_> ubottu isn't a bot, just a really fast typer. :)
<ubottu> Error: I am only a bot, please don't think I'm intelligent :)
<Peng_> ubottu: Not helping!
<ubottu> Sorry, I don't know anything about Not helping!
<Peng_> :(
<GarveyPatrickD> ubottu: Help
<ubottu> Hi! I'm #bzr's favorite infobot, you can search my brain yourself at http://ubottu.com/factoids.cgi - Usage info: http://wiki.ubuntu.com/UbuntuBots
<GarveyPatrickD> What does it respond to?
<igc> morning
<Peng_> G'morning!
<nadavoid> I've used bzr push sftp://[stuff] and connected and apparantly succeeded. But it didn't do what I thought it would.  It crated a repository (.bzr directory) on the sftp server, but it didn't publish an actual files there.  What do I need to do to publish the actual files that I'm working with?
<nadavoid> In other words, I currently end up with *only* the .bzr directory being created on the server.
<bob2> 'bzr checkout'
<bob2> then the 'update after push' plugin
<bob2>  ( https://launchpad.net/bzr-push-and-update/ )
<nadavoid> bob2: that looks perfect. thank you very much!
<nadavoid> bob2: should I delete the .bzr directory I just created, before I try what you suggested?
<bob2> no
<mib_y3onohsi> Having trouble setting ACLs for shared repositories
<mib_y3onohsi> Anyone with such knowledge?
<nadavoid> I've done 'bzr push sftp://[stuff]' --- now I can't get 'bzr checkout' to work. I've tried several variations of the command.
<nadavoid> I want 'bzr checkout' to put the actual files on the server.
<nadavoid> 'bzr checkout alone doesn't do it.
<nadavoid> I've also tried 'bzr checkout ./ sftp://username@server/~/path/to/directory' but that gives me this error: "ERROR: File exists: 'path/to/directory/.bzr': Failure: unable to mkdir"
<nadavoid> I tried that exact same command after deleting .bzr directory on the server, but that failed too. (I forget the error message on that one.)
<bob2> don't do any of that, aside from the first 'push'
<bob2> https://launchpad.net/bzr-push-and-update/
<nadavoid> oh. so I just install the plugin, then do 'bzr push' again?
<bob2> don't know
<lifeless> nadavoid: you'll need to install the plugin, ssh to the server, run 'bzr checkout .' in the directory in question, and then when you push it should just work
<nadavoid> lifeless: bzr isn't installed on the server. Would that prevent me from doing what you say?
<lifeless> yes
<nadavoid> bummer.
<lifeless> nadavoid: if you just want a copy of the code on the server, get the upload plugin instead
<lifeless> it it designed for web publishing and such
<nadavoid> lifeless: that would work if I'm wanting to regularly make updates?
<nadavoid> I want to have a local copy of php code, and push it out to live sites occasionally.
<lifeless> nadavoid: thats what bzr-upload is designed for
<nadavoid> ok, great. now I just have to figure out how to get it installed properly.
<ronny> anyone aware of any invocation rites to get jelmer here ?
<lifeless> he should be on soon, he is in spain at a sprint at the moment
<ronny> lifeless: ah, i see, im tinkerning with adding some higher level api's to dulwich, want to discuss before starting implementing
<BasicOSX> poolie: ping? I
<BasicOSX> I'm not sure I understand your response on the ML.  following release doc I did 'make dist' and it succeeded.
<beuno> Peng_, ping
<ronny> jelmer: are there any plans to make the dulwich apis more nice for walking trees/commit graphs
<ronny> currently many things about objects give me object id's, when another objects might have been convient
<poolie> BasicOSX: hello
<poolie> i'll re-read it
<poolie> igc: hello, if you're here
<poolie> hello lifeless
<poolie> lifeless:  is there a "scroll to bottom" key in irssi?
<jelmer> ronny, Hi
<jelmer> ronny, I'm not sure what the best approach is there
<jelmer> ronny, The Bazaar graph utility functions are generic enough that they're usable for git as well, but I'm not sure if I want to maintain a copy of them in Git
<jelmer> igc, ping
<ronny> jelmer: i can probably deal with the graph walking fine, but walking the trees could be a bit more convient
<poolie> BasicOSX: answered; hth
<jelmer> ronny: What sort of functions are you looking for exactly? Walking the contents of the full tree?
<jelmer> ronny, Just iterating over all entries in a trees works fine for me, there's also a function that can lookup a path
<ronny> jelmer: im mostly looking for apis that give me objects instead of object-id's
<jelmer> ronny: If you have an object id it's a matter of repo[object-id] to get at the object
<ronny> jelmer: im not exactly sure on it yet, i'll implement a prototype in anyvc
<jelmer> ronny: Retrieving the object immediately from tree is going to be slow if you don't actually need the object
<ronny> jelmer: yes, but that step of indirection feels inconvient, i have to take care of the repo, the object, the id's , lost of things to track i dont directly care about
<jelmer> ronny: dulwich can provide a function that returns an iterator over tuples of data in the tree, but you have no ability to skip any data in the tree
<poolie> igc: great performance patches
<ronny> jelmer: i'll build what i think that could work nice and will let you review that for suckage points
<jelmer> ronny, would that help?
<ronny> jelmer: im not yet sure on my exact neesds, anyvc's history stuff is still rather small
<jelmer> mwhudson: is the vlc import still failing?
<mwhudson> jelmer: i don't know, let's look
<mwhudson> jelmer: yes: https://code.edge.launchpad.net/~vcs-imports/vlc/master
<wam> Hi, I use bzr 1.15 and want to use something like svn externals. I read all about nested trees and I think that's what I want. But it doesn't work. I always end up with a error message "ERROR: Cannot join myproject. Trees have the same root id".
<wam> I'm developing zope and have a directory "src" where my projects are. They're all their own repositories. Now I want to have a "root" repositry that fetches them all plus some config files for the whole project when I co it.
<wam> Am I misunderstanding the "nested trees"?
<mwhudson> wam: you are aware nested trees are very alpha-ish right?
<mwhudson> wam: but that sounds like the trees you are joining are not in a format that supports such
<wam> mwhudson: should they all be rich-root?
<wam> mwhudson: I didn't know that they're alpha ;) But I really need that feature...
<abentley> beuno: Would you like to work on some more user stories?
<mwhudson> wam: oh look! abentley is here
<wam> ;)
<wam> abentley: could you guide me to a working nested tree setup? I already have a directory with several repositories and would like to join them all to a global repository for the whole project.
<mwhudson> wam: maybe you could use scmproj (google) for now?
<wam> mwhudson: didn't know that. /me looks
<abentley> wam: nested-by-reference is not in a usable state.  If you want to combine your trees into a single tree, you can use the merge-into plugin.
<wam> abentley: thanks, I'll have a look
<abentley> wam: If you want the trees to remain separate, scmproj is probably the best choice.
<wam> abentley: that was the intention. So scmproj will match.
<igc> ping poolie, jelmer
<igc> hi guys - was at dinner previously
<igc> I've got 10-20 minutes before I need to get the kids into bed if you need to chat about anything
<pygi> igc: they're in a session I think
<igc> thanks pygi
 * igc bbl
<nedosa> question: i've made more than a few changes in my own branch, which I now want to merge back to the trunk, but re-shuffle the commits into more logical segments
<nedosa> so i've tried to generate a diff from the common ancestor between my branch and the trunk, which i then want to apply to the trunk and then proceed like that
<bob2> bzr-rebase
<bob2> but think about whether it really matters to you or not
<nedosa> oh i see
<nedosa> i ran into problems with creation of new directories and moving files, it doesn't seem to be cleanly supported by the diff,patch combo
<lifeless> poolie: dunno, never looked for it
<jelmer> LarstiQ, ping
<LarstiQ> jelmer: pong
<jelmer> LarstiQ, are you still able to reproduce bug 336749 with newer versions of bzr/bzr-svn, with fresh clones?
<ubottu> Launchpad bug 336749 in bzr-svn "reconcile raises a KeyError on a fresh branch" [Undecided,Invalid] https://launchpad.net/bugs/336749
<LarstiQ> jelmer: how new?
<jelmer> LarstiQ, like, 0.6.1
<LarstiQ> jelmer: should I wipe the cache?
<jelmer> LarstiQ, yeah
 * LarstiQ reruns the sequnce
<jelmer> LarstiQ, you also might want to install python-tdb at the same time (should give a faster and smaller cache)
<LarstiQ> jelmer: I'm a bit leary of tdb yet
<LarstiQ> it's still a very fresh change, see things like bug 381270
<ubottu> Launchpad bug 381270 in bzr-svn "Debian packaging doesn't declare minium python-tdb version" [Undecided,New] https://launchpad.net/bugs/381270
<jelmer> Ah, I should be using tdb.Tdb probably
<LarstiQ> jelmer: I started packaging 0.6.1 as you see, I hope that's ok
<jelmer> LarstiQ, more than ok :-) Thanks for doing that
<LarstiQ> jelmer: feel free to prewarn/prod me on irc around a release so the debs can be done even faster ;)
<jelmer> LarstiQ, will do :-)
<LarstiQ> hmm, the bzr check https:// trips an assertion
<LarstiQ> jelmer: bzr branch https://../spitfire; cd spitfire; bzr reconcile -> similar backtrace, same KeyError
<jelmer> LarstiQ, but what about branch?
<jelmer> LarstiQ, That's the main one we looked at tbh
<LarstiQ> hmm, I can't find the tdb cache to remove
<jelmer> Should be somewhere in ~/.cache/bazaar/svn if you have xdg
<LarstiQ> check
 * LarstiQ removes
<LarstiQ> jelmer: the second branch completes
 * LarstiQ tries log
<LarstiQ> seems to work too
<jelmer> LarstiQ, Ok, so reconcile is the main thing that's remaining?
<LarstiQ> jelmer: so far, yes
<LarstiQ> beuno: could you test the hardy bzr-svn 0.6.1 package in the (main and beta have the same) ppa?
<beuno> LarstiQ, will do in ah hour or two
<LarstiQ> cool
<visik7> hi
<visik7> I've a repository I want to give access to only a subdir is it possible '
<visik7> ?
<LarstiQ> visik7: if with repository you mean branch, no.
<visik7> yes sorry a branch
<visik7> neither with views ?
<LarstiQ> I very much doubt that.
<LarstiQ> visik7: you could split it into different branches though.
<visik7> LarstiQ:  how ?
<awilkins> lifeless: Ping?
<danigm> Hi all
<danigm> It's possible to define an alias similar to launchad plugin "lp"?
 * awilkins thinks the answer is in your question
<GaryvdM> danigm: such as in another plugin, yes
<danigm> GaryvdM: but it's needed to add another plugin? is not possible to do it changing a configuration file?
<GaryvdM> No
<GaryvdM> You may be interested in the bookmark plugin?
<danigm> GaryvdM: ok, I will look it
<fullermd> Damnit.  So now all my preferences and subscriptions and login and everything on the wiki is gone off to la-la land?
<emmajane> fullermd, because of the LP signon?
<fullermd> Yeah.
<emmajane> I remember I was still subscribed to /a/ page, but I don't remember if I've been getting updates.
<SamB> hmm ?
<emmajane> huh. maybe not though (according to my UserPreferences page)
<poolie> hello emmajane
<emmajane> poolie, hey :)
<SamB> they should have had it email everyone a thingy to migrate their preferences to their LP account ...
<emmajane> fullermd, Yeah, I lied. I have no subscriptions either.
<emmajane> SamB, I have no recollection of receiving such an email...
<SamB> I said "maybe they should have"
<SamB> indicating that they didn't
<fullermd> Better would be to just let me migrate the account...
<emmajane> SamB, ahhh. I missed the part where you didn't type "maybe" ;)
<SamB> oh, oops
<SamB> fullermd: that's what I mean -- should have emailed you a link to do just that
<SamB> or a blob of text or something
<emmajane> poolie, did you stick around for UDS?
<emmajane> SamB, that's *way* too logical to give users choice. :)
<SamB> emmajane: what, you would prefer it try to migrate to a launchpad account with the same email and, if none existed, just drop everything ?
<poolie> emmacjane, yes, i did
<SamB> I mean, you might have used say naesten+bzrwiki@gmail.com or something -- presumably you wouldn't have that listed in your launchpad account ;-)
<emmajane> SamB, I'm just agreeing with fullermd that it's rude to lose user data/preferences. :)
<emmajane> poolie, excellent. :)
<SamB> now that you've alerted me to this issue, I have resubscribed to http://bazaar-vcs.org/GitStyleBranches
<SamB> which is probably the only thing I was subscribed to
<SamB> speaking of which, does anyone have any criticisms for that page?
<ronny> jelmer: you got some code somewhere that  helps viewing svn history as reasonable graph?
<jelmer> ronny, How do you mean?
<jelmer> ronny, subversion is mostly left hand side revisions and cherrypicks
<ronny> jelmer: i have no idea what you mean by that
<emmajane> SamB, I don't understand what it's about....
<SamB> ronny: I'm afraid bzr-svn doesn't use svn mergeinfo as well as it could :-(
<jelmer> ronny, revisions in subversion don't have more than one parent
<jelmer> SamB, ?
<ronny> bascially i just want to try to make the stuff in branches/tags/trunk look as dag-ish as possible
<SamB> jelmer: well, you COULD try to check if all of the revisions since a branch point have been merged ...
<jelmer> SamB, that'll help only a few users at a performance cost
<SamB> jelmer: and probably just make them grumpier ;-)
<SamB> yes
<jelmer> SamB, supporting mergeinfo that way is pointless until bzr itself supports proper cherrypicking tracking
<SamB> but it sounds like it's what ronny was hoping for
<jelmer> SamB, no, it's unrelated - we weren't talking about bzr-svn
<SamB> well, I mean, ronny seems to be looking for code that does basically that
<jelmer> SamB, no, because that's unrelated to a dag
<SamB> jelmer: I don't see how it's unrelated!
<ronny> hmm, svn history is not exactly coercable into a dag
<jelmer> ronny, afaik you're looking for svn repository layout code right?
<ronny> jelmer: mostly
<SamB> ronny: yeah, looking at git-svn's graphs in gitk is always so depressing :-(
<ronny> jelmer: i wantto have a remotely reasonable log
<jelmer> ronny, there's nothing like that in subvertpy
<ronny> jelmer: i know that already, just wondered if you had something about that somewhere else
<ronny> hmm, time to play with remoteaccess
<jelmer> ronny, bzr-svn does that sort of analysis
<ronny> i need to get at least the commit message of the "head" revision
<emmajane> SamB, I took a look at your wiki page. It needs more of an introduction. I don't understand what it's describing at this point.
<jelmer> ronny: So, RemoteAccess.get_log will get you linear history information just like "svn log"
<SamB> emmajane: yeah. I seem to have thought so too ... but couldn't figure out what to say
<SamB> at least, judging by the thing I have in brackets at the top
<emmajane> SamB, adding a useful heading to the very-very top would be a good start. :)
<emmajane> SamB, try just telling me here what it's about and then cheat and copy and paste it into the doc.
<ronny> jelmer: are there any examples to get the last revision that commited to trunk?
<SamB> well, it's supposed to be about how to keep several branches around but use them all with the same working directory
<emmajane> SamB, cool!
<jelmer> ronny, see examples/ra_log.py
<SamB> sort of like when you use branches with git
<emmajane> SamB, how about: Creating a working directory
<emmajane> and then: This page explains how to set up a working directory that contains multiple branches. This will be familiar to those who've used Git in the past and are migrating to Bazaar.
<SamB> emmajane: well, it can't actually *contain* the branches
<SamB> at least, I don't know how it can
<emmajane> (although who've to should be expanded as it's harder for ESL readers)
<ronny> jelmer: doesnt looke exactly what i want, im goign to try figuring
<ronny> jelmer: in case of doubt, i have to take the latest from_rev inside the first callback and run a second one?
<jelmer> ronny, that's exactly what you were mentioning except that it iterates all revisions from 0 to the latest rather than the other way around
<jelmer> and you need to pass limit=1 if you need just one
<emmajane> SamB, no?
<emmajane> SamB, I thought that was the whole point: shared repo for multiple branches?
<SamB> emmajane: yeah
<SamB> but unlike git, the branches aren't inside the working directory
<SamB> not without ColocatedBranches, anyway
<emmajane> SamB, great, so go ahead and adjust what I've typed to make it right for your doc.
<SamB> emmajane: okay, I didn't change much
<SamB> except I basically rewrote the heading
<emmajane> great.
<emmajane> SamB, It would also be most excellent to get rid of the (instructions in brackets). They're sort of confusing as written.
<jelmer> Are you talking about the GitStyleBranches spec? That should probably be folded into the ColocatedBranches one
<emmajane> specifically: [Again, the cd commands are kinda ridiculous here -- maybe I should use another way of indicating where each step is to be done?]
<emmajane> jelmer, http://bazaar-vcs.org/GitStyleBranches
<emmajane> that's the page I'm looking at.
<SamB> jelmer: it's not a spec!
<SamB> it's a tutorial thingy
<jelmer> ah, sorry
<jelmer> never mind me then
<emmajane> jelmer, :)
<emmajane> jelmer, I always mind you! :)
<SamB> I like to live only very slightly in the future ;-)
<emmajane> SamB, I often live in the past. :)
<SamB> (which is to say, in bzr.dev rather than the release)
<SamB> and sometimes I don't upgrade and end up in the past
<emmajane> SamB, what does the heading, "What They Said" mean?
<emmajane> SamB, do you mean, "Background information" ?
<SamB> emmajane: hmm, yeah, that was the next thing I wanted to change
<SamB> hmm, yeah, that sounds like a much better heading there
<emmajane> SamB, for the actual step by step instructions I like to have detailed information on what I'm about to do and then what I type at the command line.
<ronny> jelmer: btw, ever experimented if greenlets turn may turn the svn log into a generator?
<jelmer> ronny: it seems a bit heavyweight to depend on greenlets for that sort of thing, it would mean subvertpy would have to depend on them
<ronny> jelmer: im trying to figure hout how to wrap it, so it will fallback to a thread
<emmajane> SamB, and where possible I like to expand commands (e.g. the shortcut on mv. Not everyone knows about curly braces...I've been using *nix for over six years and just found out about it last year.)
<jelmer> ronny: bzr-svn also has some functionality that can do that, using a simple helper thread
<emmajane> SamB, You can probably also get rid of the cd $FOO and cd .. commands. Just explain to people in words which directory they need to be in before issuing the relevant command.
<emmajane> I've made it in life! lifeless asked me to be his facebook friend. :)
<igc> night all
<Guest> Hello, is it possible to make bzr ignore symlinks?
<Guest2022> I mean, how do I create a general rule into .bzrignore to make it ignore all symlinks
<Guest2022> no one?
<fullermd> I'm pretty sure there isn't one.  .bzrignore just takes paths.
<Guest2022> thanks
<mib_dzx78e79> Anyone with knowledge of ACLs?
<mib_9ju1c2mf> Can anyone assist with a permission issue?
<lifeless> awilkins: pong
<mib_l3vtwtue> What is the best way to set up a shared repository among several users on a single machine?
<emmajane> Created a standalone tree (format: pack-0.92) <--- that's a nice touch.
<emmajane> takes some of the magic out of init.
<Peng_> beuno: pong, ish
#bzr 2009-05-29
<mkanat> I'm getting this when trying to upgrade to the newest loggerhead: bzr: ERROR: KnitPackRepository('file:///home/mkanat/loggerhead/.bzr/repository/')
<mkanat> is not compatible with
<mkanat> KnitPackRepository('http://bazaar.launchpad.net/%7Eloggerhead-team/loggerhead/trunk-rich/.bzr/repository/')
<mkanat> I had to upgrade my local repo to a rich-root-pack. The error message was pretty unclear. Thankfully the URL was helpful! :-)
<mkanat> Okay, so I figured all that out on my own. :-)
<mkanat> Later, folks!
<igc> morning
 * igc lunch
<gotgenes> Is anyone still working on bzr GTK?
<j^> hi, a question, i have two bzr repositories (created from two svn repositories) one is a fork of the other, so i know at which point it was forked from the other project, i want to merge them to get the common history. is that possible how would it do that, trying bzr merge -r 0..HEAD it will move all directories in the repository root and add new once
<rowinggolfer> hello.
<rowinggolfer> what do I  do about this?
<rowinggolfer> bzr: ERROR: bzrlib.errors.TooManyConcurrentRequests: The medium '<bzrlib.smart.medium.SmartSSHClientMedium object at 0x20bf310>' has reached its concurrent request limit. Be sure to finish_writing and finish_reading on the currently open request.
<hmeland> j^: The two svn repositories have different UUIDs, right?  If so, bzr's revision IDs will be different even for revisions that are identical (i.e. from before the fork), making merging difficult at best.
<Peng_> rowinggolfer: That error message is really useless -- it could be caused by anything, like a segfault. You'll need to provide more details. What details exactly I'm not sure.
<hmeland> You might have more luck managing such a merge within git, which I understand use a revision's content to establish that revision's identity.
<j^> hmeland, yes two svn servers, but in the end i want history of repository1 + repository2 i know at which point they are  the same, i can also just take repository1 up to the revision they are the same and add repository2 if thats possible
<lifeless> j^ I'd use bzr-svn to get r1 imported, then tailor to finish the job
<hmeland> j^: I guess you could rebase the post-fork revisions from repo 1 onto the fork-point revision from repo 2 (or vice versa), but the file-ids in the two branches are likely different.
<hmeland> ...unless bzr-svn has some nifty option to derive file-ids from another tree, like "bzr add --file-ids-from"?
<rowinggolfer> Peng - my network went down during the commit.
<rowinggolfer> hang on... I'll pastebin the entire thing
<rowinggolfer> http://pastebin.ubuntu.com/183497/
<rowinggolfer> Peng_ you'll note I tried to unlock and check stuff also.
<rowinggolfer> so any ideas?
<rowinggolfer> bzr check of both the local and remote branches are error free.
<rowinggolfer> but bzr push gives me
<rowinggolfer> Using saved location: bzr+ssh://rowinggolfer@bazaar.launchpad.net/~rowinggolfer/rowinggolfer/trunk/
<rowinggolfer> bzr: ERROR: Permission denied: "/~rowinggolfer/rowinggolfer/trunk"
<rowinggolfer> is that a lock issue?
<rowinggolfer> or a problem with the launchpad server?
<hmeland> I'd guess the latter.
<hmeland> You could of course try "bzr break-lock".
<rowinggolfer> I have done that.
<Peng_> A bad lock shouldn't result in permission errors. :\
<Peng_> rowinggolfer: "bzr break-lock bzr+ssh://rowinggolfer@bazaar.launchpad.net/~rowinggolfer/rowinggolfer/trunk/"?
<Peng_> rowinggolfer: No projected called "rowinggolfer" exists. That's probably the source of your error.
<Peng_> Err, project*
<rowinggolfer> hmmm.
<rowinggolfer> 98 previous commits with the same credentials.
<Peng_> rowinggolfer: FWIW, there's a decent chance that your original TooManyConcurrentRequests error has been fixed in a newer version.
<Peng_> rowinggolfer: 98 commits to a project called "rowinggolfer"?
<rowinggolfer> the project is called openmolar
<rowinggolfer> I am confused also.
<rowinggolfer> ah, you're looking at line 85... I tried that given the odd url coming back at me
<rowinggolfer> for some reason... the save location is wrong.
<rowinggolfer> how the hell has that happened?
<rowinggolfer> problem solved.
<jelmer> msg nickserv identify 8596jrv
<jelmer> crap
<Peng_> You should type it in a non-channel tab, just to be safe.
<pygi> jelmer: lol
 * jelmer sighs
<jelmer> time to change my nickserv password...
<Peng_> I commend you for your non-horrible password, though.
<Peng_> Unlike mine..
<pygi> beuno: hi
<pygi> me and jelmer had some talk about loggerhead serving branches
<pygi> and we have two feature suggestions:
<pygi> smartserver integration and per-branch authorization functionality
<bialix> what is "bzr pony"?
<poolie_> bialix: hello
<bialix> hi poolie
<poolie_> it's a silly expression for "I want everything" -- http://www.google.es/search?q="want+a+pony"
<poolie_> i can trim it
<LarstiQ> gotgenes: yes
<LarstiQ> oh hmm, was scrolled up
<bialix> poolie: I'm still can got it re bzr
<bialix> can't
<fullermd> Wait, my copy of bzr.dev doesn't have a pony   :(
<Peng_> I missed ponies?!
<bialix> it seems so
<poolie_> it just means "i want every feature"
<poolie_> it's not a very helpful statement, just something andrew? said here
<poolie_> thanks for reading them though!
<poolie_> it's pretty rough
<Peng_> I want Bazaar to churn butter like git does!
<bialix> I want it all, I want it now? Queen
<fullermd> git churns butter?  That explains the smell...
<Peng_> Oddly enough, it can only churn butter on Windows.
<Peng_> On *nix, it just gets all dried out and creepy.
<bialix> pollie_: perhaps I'm very curious person
<poolie_> :)
<bialix> poolie: is there some announce of upcoming public release of lp?
<bialix> I mean some semi-official article?
<bialix> address book is interesting idea
<bialix> pollie,jam: thx for talking with Gary about QBzr. His new idea is really fresh move.
<LarstiQ> bialix: where did you encounter that pony?
 * LarstiQ briefly checked mail, planet and identi.ca
<bialix> http://doc.bazaar-vcs.org/devnotes/wishlist.html
<bialix> i wanna pony as well
<LarstiQ> ah
<LarstiQ> thanks
<awilkins> lifeless: Ping?
<lifeless> awilkins: pong
<vadi21> Would bzr-gtk be updated in the bzr ppa sometime? It's not working with the current version in it for a pair of days
<Pilky> are the docs for bzrlib linked to from the site the most up to date or is there a more up to date set that aren't quite as patchy in the bzr repo?
<lifeless> -> au
<Pilky> lifeless: you're one of the bzr devs right?
<Peng_> Pilky: Yes.
<Peng_> Unless you're a troll, in which case lifeless who? :D
<Pilky> lol
<Pilky> I'm trying to figure out how the hell committing works in bzrlib
<Pilky> I mean, I understand how to commit from the integrating with bzr document
<Peng_> You could follow cmd_commit from bzrlib/builtins.py
<Pilky> but the commit method on mutabletree isn't documented and it looks like the arguments are got from the commit class
<Pilky> Peng_: it's not as much finding out how as finding out what arguments committing takes
<Peng_> Sorry, I don't know anything.
<Pilky> i.e. This isn't documented: http://starship.python.net/crew/mwh/bzrlibapi/bzrlib.mutabletree.MutableTree.html#commit
<Pilky> this is: http://starship.python.net/crew/mwh/bzrlibapi/bzrlib.commit.Commit.html#commit
<Pilky> but it seems when committing the former is used
#bzr 2009-05-30
<vadi21> Would bzr-gtk be updated in the bzr ppa sometime? It's not working with the current version in it for a pair of days
<cloudbook> hello, I have a simple question about using bzr on Mac OS X.  Anyone can help?
<BasicOSX> I pretend to use osx, what can I attempt to answer?
<Kamping_Kaiser> ho hum. no bzr-git in Debian. I thought there was :/ *will have to check the ppa*
<Kamping_Kaiser> should I report bugs in Debians bzr/bzr-git in bugs.debian or launchpad? I was about to send it to bugs.debian, then noticed the 'please file in launchpad' in the backtrace message
<Kamping_Kaiser> i'll file in debian, it can be forwarded if needed.
<lifeless> Kamping_Kaiser: generally speaking, if its an upstream bug, file it upstream
<lifeless> Kamping_Kaiser: only bugs that are debian specific are useful to file in the debian bugtracker
<Kamping_Kaiser> fair cop.
<Kamping_Kaiser> well, its in debians. i'll put it upstream next time. :)
<vadi2> Would bzr-gtk be updated in the bzr ppa sometime? It's not working with the current version in it for a pair of days
<vadi2> ÐÑÑ
<xnox> Hello =D is there a 1.15 installer for Leopard? In download's area I can only see 1.15rc1 for Tiger....
<AnAnt> Hello, a question about bzr builddeb
<AnAnt> if I close a launchpad bug in debian/changelog, then I do a: bzr ci
<AnAnt> will that automatically do --fixes=lp:<bug num>
<AnAnt> ?
<LarstiQ> I doubt it.
<LarstiQ> wonder how to exactly approach that
<LarstiQ> AnAnt: something like that sounds like a cool feature though :)
<LarstiQ> james_w: ^^
<james_w> damn, missed him
<james_w> LarstiQ: I would actually love to add that feature. I sent a mail to the list a couple of months ago with a proposed design for a new pre-commit hook that would allow it to happen
<LarstiQ> james_w: bzr list, because the current pre-commit hook design doesn't allow it?
<james_w> yeah
<LarstiQ> ok
<james_w> or at least doesn't allow it to be done well
<LarstiQ> right
<LarstiQ> james_w: are you going to be at EuroPython?
<james_w> unfortunately not
<james_w> I thought I was, but something else came up
<LarstiQ> aw :(
<james_w> yeah
<james_w> would have been great to see you again
 * LarstiQ nods
#bzr 2009-05-31
<jelmer> lifeless, subunit was accepted into sid
<TheJosh1337> Hi I have a quick question about bazaar. How can I set up access control for my bazaar repository? I am running the repo on a server, and I want control on who can commit to what branches.
<mwhudson> TheJosh1337: bazaar doesn't get into that business itself
<mwhudson> TheJosh1337: one option is using unix accounts and ssh
<TheJosh1337> can I write a plugin?
<TheJosh1337> it's currently going through bzr://
<mwhudson> yes, you can
<mwhudson> it's probably not super easy though
<TheJosh1337> All I want is for each user to have as many branches as they want
<TheJosh1337> but they can only commit to their branches.
<TheJosh1337> with the branch name containing the user name (e.g., /TheJosh/sandbox for TheJosh's 'sandbox' branch
<mwhudson> but you don't want to create a unix account for each user?
<TheJosh1337> I could do that
<mwhudson> it's a bit sucky, but that's easiest for now
<TheJosh1337> although the plan is that the users will only be able to commit to their branch(es)
<mwhudson> well sure
<TheJosh1337> then a web tool will allow merging of branches into trunk
<mwhudson> so use unix permissions
<TheJosh1337> so the user accounts are only on the web tool.
<mwhudson> i.e. create /code/Bob that's owned by bob anx rwxr--r--
<mwhudson> there are bits and pieces in launchpad we should probably factor out and open source to make this easier
<TheJosh1337> so my web tool has to create a unix account on the server for every user account created, and set the correct permissions as well, correct
<mwhudson> but, well, that takes time
<mwhudson> ah i see
<TheJosh1337> see I want to do something slightly radical. I want to allow anyone with an account commit access to trunk straight away
<TheJosh1337> as long as they go through a branch, and as long as the code compiles
<mwhudson> you can play tricks with ~/.ssh/authorized_keys to avoid creating an actual account for each user
<TheJosh1337> kinda like wikipedia - it doesn't make sense, but it works
<mwhudson> TheJosh1337: have you seen pqm?
<TheJosh1337> Yeah
<mwhudson> that allows an email driven way of doing what you want
<TheJosh1337> but I couldn't find any useful docs
<TheJosh1337> like how to install or set up or anything like that
<TheJosh1337> and for a anyone-can-commit system to work it has to be easy to use - really easy to use
<TheJosh1337> wikipedia wouldn't work if it wasn't brain-dead easy to use
<TheJosh1337> mwhudson, ill look into hooks, to begin with I only have to prevent commits to trunk, that should be fairly easy I hope.
<TheJosh1337> thanks
<nekohayo> anyone has a recording or slides of "Plans for Bazaar after 2.0" from UDS 2009?
<cellofellow> I have a Bazaar branch I just made that has an Audacity project with nearly 2:30 hours of audio in it. It's about 2.6 GB and has 2679 files in it. I've already put it in a regular branch but was thinking it would be better to put it into a repository, though I'm not sure the best route to go with that.
<cellofellow> Should I use the --no-trees option?
<cellofellow> can I move the already existing branch into a shared repo or do I have to branch it in?
<nekohayo> hey there, is it me or the bzr-gtk packages are broken with bazaar 1.15?
<pygi> nekohayo: define broken?
<nekohayo> pygi: bzr viz doesn't start, neither does olive
<pygi> nekohayo: what's the traceback?
<nekohayo> Unable to load plugin 'gtk'. It requested API version (1, 13, 0) of module <module 'bzrlib' from '/usr/lib/python2.6/dist-packages/bzrlib/__init__.pyc'> but the minimum exported version is (1, 15, 0), and the maximum is (1, 15, 0)
<pygi> pastie pls
<nekohayo> that's all of it
<pygi> nekohayo: moment :P
<pygi> bzr-gtk comaintainer is in the next room
<pygi> but he's busy :-/
<pygi> hmmm
<nekohayo> seems like there's a version mismatch
<pygi> nekohayo: are you using bzr checkout of bzr-gtk?
<nekohayo> nah, just the PPA
<pygi> nekohayo: could you try the bzr checkout pls?
<pygi> we'll get better at keeping it up to date, I know :p
<nekohayo> don't quite know how to do that :)
<nekohayo> well if it's just a matter of the bzr-gtk package not being yet updated in the archive..
<nekohayo> I guess I can simply wait for it to appear?
<pygi> nekohayo: yes :)
<pygi> nekohayo: I think the thing is that there isn't yet a new release :P
<pygi> I'll bug szi tomorrow
<pygi> nekohayo: I think we'll get a bit more better at bzr-gtk after this week
<pygi> :)
<nekohayo> pygi: ah, why is that? :)
<pygi> nekohayo: we had some discussions about bzr-gtk specifically during bazaar sprint
<nekohayo> at UDS?
<nekohayo> any way for a simple user like me to have access to stuff that was discussed, or presentations such as "Plans for Bazaar after 2.0" ?
<pygi> nekohayo: yes
<pygi> uhm, there are some notes, but unfortunately its just a list of things for discussion from monday
<pygi> some updates were sent during UDS to the mailing list
<pygi> but I guess most are still expected
<nekohayo> I vaguely heard someone raving about that "Plans for Bazaar after 2.0" talk on planet gnome, but couldn't find it
<pygi> uh? Not sure, I didn't follow planet gnome  really
<pygi> I was busy with windows stuff :-/
<nekohayo> :]
<nekohayo> it was quite hard to spot
<nekohayo> in the middle of a list of bullet points
<LarstiQ> nekohayo: not featured in planet.bazaar-vcs.org?
<nekohayo> LarstiQ: nope, haven't seen that there
<nekohayo> and the post in question on p.g.o. is http://bloc.eurion.net/archives/2009/uds-2009/
<nekohayo> which briefly mentions 2.0, but no details
<LarstiQ> hah
<LarstiQ> nekohayo: that is just a reference to the `bzr rocks` command
<nekohayo> well with a session title like that, I'm still interested in those "plans after 2.0"
<LarstiQ> nekohayo: http://doc.bazaar-vcs.org/devnotes/wishlist.html is a brief list
<LarstiQ> nekohayo: you can look at other documents in that dir for more of an idea
<nekohayo> cool
<pygi> nekohayo: I think there will be a lot work on UI
<pygi> and the plan is to have one stable and one development format in the entire 2.0 cycle
<nekohayo> you mean, olive/nautilus will be usable? :P
<pygi> some of the plans also include merging qt/gtk logic behind GUIs
<pygi> nekohayo: I meant UI of the "bzr"
<nekohayo> oh
<pygi> nekohayo: why is say olive not usable?
<nekohayo> well my general impression from having used it a while ago is that it's not feature-complete, and not much attention/love is given to it because the devs are busy with other things?
<pygi> nekohayo: specifics specifics
 * nekohayo finds his bug list
<pygi> if you could write a detailed mail to the mailing list, that would be great for example
<nekohayo> well I think this is part of it: https://bugs.launchpad.net/bzr-gtk/+bugs
<nekohayo> the bugs don't seem to be fixed much or the app doesn't "feel" maintained, but this is just a subjective, personal perception
<pygi> nekohayo: that's true, I admit it
<nekohayo> but I do understand the time/workforce constraints
<nekohayo> over time I just got accustomed to using bzr on the command line and not hoping for olive or nautilus integration, basically :|
<pygi> nekohayo: I really really really hope that will change
<nekohayo> me too :)
<nekohayo> but I have no idea when it will happen?
<pygi> nekohayo: this year :p
<nekohayo> I remember about 5-10 bug reports I did back 1-2 years ago on olive AND bzr-gtk (because there was some kind of mess regarding their status in launchpad)
<nekohayo> and I even provided patches which sat there for months
<nekohayo> (for basic 1-2 lines stuff)
<pygi> nekohayo: ok, if you'll have patches now I'll process them in like a week at most :p
<nekohayo> that kinda depressed me ;)
<nekohayo> nice
<pygi> unless they're 10000lines :P
<pygi> nekohayo: so when can I expect patches? :D
<ronny> whats the 1.14 format and whats the relation to brisbane-core?
<fullermd> None, 1.14 adds a WT format for the IO filters.
<pygi> ronny: and 1.14 release added a brisbane core as --development-rich-root
<ronny> pygi: does that mean the on-disk structures will be stable now?
<pygi> ronny: if you're thinking of 2.x having a stable format, then yes
#bzr 2010-05-31
<exarkun> Done, https://bugs.launchpad.net/bzr/+bug/587692
<ubot5> Launchpad bug 587692 in Bazaar "Sometimes "bzr version-info" doesn't complete (affected: 1, heat: 0)" [Undecided,New]
<igc1> morning all
<poolie> hi all, igc
<spiv> Good morning.
<poolie> hi there spiv
<poolie> what fabulous adventures will you have today?
<spiv> Finishing the patch(es) for allowing bzr-builder to merge just debian/ dirs from parallel imports, I hope!
<poolie> nice
<lifeless> back
<poolie> hi there lifeless
<lifeless> hiya
<poolie> hi
<poolie> re high bugs
<poolie> if you want to strike while the iron's hot and fix it, feel free
<poolie> but it's not as critical as some others
<duffyd> poolie: hi
<duffyd> poolie: was just talking to lifeless on #nzpug re. finding a good hotel in brisbane
<duffyd> poolie: he thought you might have some suggestions :)
<lifeless> poolie: I really feel that if we allow things to slip, they stay slipped; the broken windows theory of code maintenance
<lifeless> poolie: in particular I was expecting/hoping parthm would pick it up with the priority I'd set it, as he's slowly getting deeper and deeper in.
<lifeless> duffyd: also wikitravel if you haven't looked there already ?
<duffyd> lifeless: oh ta
<poolie> re broken windows, i sympathize but the important thing is to fix them, making all bugs high won't help
<lifeless> thats true
<lifeless> I feel that regressions should be equal to the highest priority open bug, in essence
<lifeless> I know you don't feel that way, and I don't understand why, yet.
<poolie> lifeless, if "regression" means "used to work, now doesn't"
<poolie> then, i agree it's an interesting thing to track
<poolie> i don't think it jumps to the top of the queue
<poolie> if somebody picks up a copy of bzr today and hits say 5 bugs
<poolie> the fact that one of them was once working and the other was not is not super important
<poolie> in a sense if you have too many of them, then it seems that your quality process is not very controlled
<lifeless> thats true too
<poolie> either you're lacking tests or people are careless
<lifeless> Doing them first, always, should either be a small time fraction (and ok) or a burden and thus make it clear you have a problem earlier in the process
<lifeless> I think its these two things that keep me coming back to this and not accepting the 'at any point in time, what is the most useful improvement to work on' argument
<lifeless> I think thats a great argument when choosing new stuff to make good
<lifeless> but not for choosing how to deal with things that we've permitted to slip [through whatever reason]
<poolie> i think saying 'we will throttle the amount of new work by not starting any while there are regressions open' would be ok
<lifeless> I expect that to add more latency to addressing regressions than I'd like us to achieve.
<lifeless> anyone got python2.4 handy ?
<spiv> I seem to still have it installed.
<lifeless> can you do from email import Message ?
<spiv> Yep.
<lifeless> cool, thanks
<anders_> hi guys.
<anders_> I want to use cherrypicking, but I hope it can merge with history information. How can I do?
<poolie> sorry, we don't do that at the moment
<anders_> Why not?
<poolie> sorry, what's you question precisely?
<anders_> I think it is a valuable function.
<poolie> i agree
<anders_> Is there any plans to implement it?
<poolie> at the moment bzr doesn't track history for cherrypicks
<poolie> we'd like to implement it
<poolie> there is a bug you can subscribe to
<anders_> Poolie, thank you.
<lifeless> poolie: so you suggested tagging regressions; did I miss ail about that ?
<poolie> i didn't send mail about it yet
<lifeless> kk
<poolie> you can
<lifeless> ok
<poolie> i think the issue of where they should be prioritized is interesting but also one i don't want to spend much time on atm
<poolie> weapons free to fix them on demand
<lifeless> :P
<poolie> by which i mean, as they come up
<lifeless> I'm interested in that, but not in chasing  it if noone else is; so I won't ask you to spend much time on the priority discussion, but I will kick one off on the list, unless thats a concern for you
<lifeless> poolie: you expressed concerns about dirstate2's complexity
<lifeless> poolie: can you be a little more detailed ?
<poolie> i did-
<poolie> not right now but i do want to go back and reply in that thread
<lifeless> ok
<poolie> i'm not totally trolling in asking
<poolie> why fix this now rather than fixing regressions?
<poolie> most of the bugs in dirstate have been there since it was first done
<lifeless> its my fault its like this
<lifeless> ok, thats a shallow answer
<lifeless> uhm
<poolie> no, it's a reasonable answer
<lifeless> on regressions, I have a complex of feelings there
<lifeless> tied into the cost of accepting contributions I guess
<poolie> it's complex for me too
<poolie> for me at least marking them is a start
<lifeless> dirstate2 has a few interesting things
<lifeless>  - if its not ready when we do 3, we don't get it for X more years
<lifeless> (per Mark and changing formats)
<lifeless>  - it affects a great number of users in varying ways, and is, I think, causing bzr explorer and tortoise-bzr users particular pain on windows
<lifeless>  - I really want emacs folk to be happy
<poolie> i'd really like to see it fixed too
<poolie> i was using gannotate the other day and it bit me
<poolie> if we can finish it soon for 2.2 that would be good
<poolie> i guess i'm mostly concerned about being able to deal with the fallout
<poolie> - getting proper review for it, not rubberstamps
<lifeless> oh, and one more thing - its in-stock inventory at the moment
<poolie> - and whether it takes too much attention away from udd and other kinds of bugs
<lifeless> something I abhor
<poolie> mm
<poolie> i don't want the fix for it to stuff more things into the pipeline than will fit, or to cause it to be overloaded as we deal with fallout
<poolie> otherwise, i agree
<lifeless> agreed
<lifeless> Note that dirstate2 is a very specific thing
<lifeless> its not a new dirstate serialiser, for instance
<lifeless> John would like to see more work done on what-is-stored-where, and so would I, but I think that that sort of thing is very high risk.
<lifeless> OTOH doing that might make the overall design simpler. So we should talk next Monday briefly about that.
<wgrant> So, mgiuca is trying to sign the contributor agreement, but the link on http://www.canonical.com/contributors is broken.
<lifeless> ugh
<poolie> oops
<poolie> well, it's a very attractive 404
<poolie> though not really the attitude you'd expect mark to take :)
<lifeless> I'll file a bug
<poolie> k
<poolie> https://bugs.edge.launchpad.net/ubuntu-website-content/+filebug
<lifeless> yes
<wgrant> The latest copy I have is of 2.4, but 2.5 appears to be the real latest. Is there another copy of that floating around somewhere?
<lifeless> http://www.canonical.com/files/Canonical%20Contributor%20Agreement,%20ver%202.5.pdf gives a 403
<poolie> i have 2.5 here
<lifeless> bug 587755
<ubot5> Launchpad bug 587755 in ubuntu-website-content "Contributor Agreement PDF link on http://www.canonical.com/contributors is broken (affected: 1, heat: 0)" [Undecided,New] https://launchpad.net/bugs/587755
<poolie> wgrant, http://sourcefrog.net/tmp/1y/Canonical%20Contributor%20Agreement,%20ver%202.5.pdf
<wgrant> poolie: Pointed him to it. Thanks.
<frion> so I run bzr branch lp:dcplusplus, download the patch posted at http://launchpadlibrarian.net/49406269/plugins.patch , and when I run "bzr patch plugins.patch" I get "bzr: ERROR: Error invoking patch: Invalid argument"
<frion> this is with bzr 2.1.1; why might this be happening?
<poolie> frion, hm, there's no other details about which argument was invalid?
<poolie> maybe something in ~/.bzr.log?
<frion> the only Google result for anything similar is http://www.mail-archive.com/leo-editor@googlegroups.com/msg06411.html and that sort of gives up on the actual cause (it suggests using an external patch tool)
<frion> oh, didn't check, but no, not displayed, regardless of being in verbose mode or no
<poolie> is this on linux?
<frion> Windows
<parthm> hello. i noticed that the imports in bzrlib.status and bzrlib.ignores are not lazy. is this intentional or just that no one has gotten around to doing it? i benchmarked (time) 'bzr st' with/without lazy and performance seems the same.
<frion> Looking for .bzr.log actually, now.
<spiv> frion: bzr --version should tell you
<frion> spiv: ah, yup
<spiv> frion: or just repeat the command with -Derror to force it to show the full traceback, i.e. "bzr -Derror patch plugins.patch"
<frion> got the traceback already in the log
<frion> http://pastebin.com/4NMfXjLF
<frion> Still no obvious information on which argument is invalid, as far as I can tell
<poolie> frion is this on linux?
<poolie> sorry,
<poolie> just saw your message
<poolie> parthm, not sure off hand
<poolie> if there's no comment explaining why they have to be non-lazy then there's probably no good reason
<poolie> try adding stuff to test_import_tarrif
<spiv> frion: it seems that trying to start a 'patch' subprocess is failing, perhaps simply because you don't have an executable called 'patch' on your PATH?
<parthm> poolie: thanks. will look at it. if there are no problems i will make it lazy as i am doing some imports.
<spiv> parthm, poolie: or perhaps because there's no observed benefit to making them lazy?
<poolie> right
<frion> ah, that's not internal to the standalone release? the first "patch" in the path seems to be in the strawberry Perl directory, though I don't know if that's a sufficient GNU patch
<poolie> parthm, also, perhaps some can just be removed altogether
<poolie> which is better
<spiv> mwhudson's branch of pyflakes can spot unused imports (even when lazy_imports are used)
<parthm> poolie: will check that too.
<frion> ah that's also the only "patch" in the path
<spiv> (FWIW, pyflakes doesn't warn about any unused imports for status.py or ignores.py for me)
<spiv> I'm a little surprised that bzrtool's patch command calls out to an external patch tool, I would have thought bzrlib has most of that functionality builtin already.
<frion> and without that in the path, it fails with some 'can't invoke patch' message, so obviously it's trying and failing and for whatever reason Perl's patch.exe isn't sufficient
<frion> it does seem to be buildable from bzr's core functionality
<poolie> lifeless, reading your diff now
<poolie> for dirstate2
<lifeless> poolie: thanks
<lifeless> I'm about to cook dinner
<lifeless> then I'll be back for a bit
<parthm> For a test case I need to put junk into $BZR_HOME/ignore. This seems to fail http://pastebin.com/V2VC2cBk
<parthm> Am I doing something wrong?
<poolie> i don't think so, but perhaps this is not a testcaseintempdir and needs to be?
<parthm> poolie: This is TestCaseWithTransport. I checked the hierarchy, it derives from TestCaseInTempDir
<poolie> sorry i don't know then
<poolie> ah, maybe the code that creates ~/.bazaar has not run?
<spiv> parthm: where are you doing this?
<parthm> spiv: bzrlib.tests.blackbox.test_status.TestStatus
<spiv> parthm: I mean, at what point in the test?  In a test method, or overriding setUp, or?
<parthm> spiv: oh. Its a test method.
<parthm> I want to add junk into .bazaar/ignore and then run_bzr
<spiv> Ok, so that seems reasonable.  So I guess there's no .bazaar set up for soem reason, did something change there recently?
<spiv> Hmm, I'm probably getting confused with the whoami change.
<parthm> spiv: looking at tests/__init__.py there does seem to be code but it doesn't seem to be working. http://pastebin.com/RxVxpJz1
<parthm> spiv: whoami change touch EMAIL env variable and nothing else so I don't think it should matter.
<spiv> parthm: I think perhaps you have a wrong assumption about when .bazaar/ignores is created
<spiv> parthm: look at get_user_ignores()
<spiv> parthm: it has the code that does the "try open that file, if it doesn't exist create it"
<parthm> spiv: I am opening it in write more but the creation is failing ... http://pastebin.com/V2VC2cBk ... so looks like some dir is missing in the hierarchy
<spiv> parthm: "in the write more"?
<parthm> spiv: sorry. I meant, write mode for the test case. I don't care about existing content. Just want to add 1 junk entry.
<spiv> parthm: use the APIs in bzrlib.ignores, don't write the file directly
<spiv> parthm: compare how test_ignore works
<parthm> spiv: good idea. will try that.
<spiv> Note that it calls get_user_ignores, or _set_user_ignores
<parthm> spiv: ok.
<spiv> And _set_user_ignores explicitly does "ensure_config_dir_exists"
<spiv> Or perhaps add_unique_user_ignores would be more appropriate in your case.
<spiv> Anyway, you're running into trouble because you're bypassing the APIs in bzrlib.ignores which take care of this stuff for you :)
<parthm> spiv: yes. that was it. add_unique_user_ignores takes care of it. thanks :)
<poolie> lifeless, ok, dirstate2 comments
<poolie> .. sent
<lifeless> thanks
<poolie> it's not inherently scary :)
<poolie> there are both some substantial comments and some on the description
<zpp> hi everyone... I'm looking for someone that is well versed in the bzr-svn plugin for some help with bug hunting :)
<poolie> oh i meant to say thanks so: 'thanks'
<poolie> lest all the criticism seem too much
<poolie> zpp, jelmer's the expert; he'll probably be on in a bit
<poolie> you can just ask though
<lifeless> poolie: I appreciate the thorough examination
<poolie> i appreciate the code and documentation, and the openness to feedback
<lifeless> poolie: some bits I do disagree with (I don't want hashes in the dir with working tree config files etc, experience tells us folk facing too-many-files apply big hammers
<lifeless> figuring out what makes things correct given fs nastiness is really the key bit, I think
<poolie> i think so too
<poolie> i had a go at listing adequately pessimistic assumptions
<lifeless> I've starred your post for next pass at the code
<poolie> i probably should have added that you can barely count on ordering in the normal case
<lifeless> by which I mean, i won't reply till then
<poolie> even without crashes network clients may be incoherent
<poolie> np
<lifeless> but I have read it
<poolie> i may have a go at removing write-during-read
<lifeless> yes
<poolie> it may suck
<lifeless> OTOH bad-network-protocols are bad
<poolie> mm
<lifeless> the problem
<poolie> there's another alternative which is to just say "sorry, no"
<lifeless> with write-during-read is that we aim to have our operations take < 3 seconds
<poolie> and keep relying on OS locks for writing
<lifeless> that would still not work on NFS, for instance.
<poolie> sorry i don't follow you
<lifeless> I will note that the pack repo format, which I built using an earlier version of the same algorithm has been pretty darn reliable
<lifeless> sorry, changed horses
<zpp> poolie: sorry... just got back :)... thanks for that
<zpp> Im attempting to create a remote branch with a bound local repo & checkout and keep getting this error when I push data to the remote branch: ErrorFromSmartServer: Error received from smart server: ('error', 'Internal check failed: Cannot add revision(s) to repository: missing chk node(s) for id_to_entry maps')
<vila> hi all
<lifeless> ok
<lifeless> EOD
<lifeless> poolie: ^
<poolie> hi there vila, cheerio lifeless
<spiv> zpp: ooh, interesting
<spiv> zpp: I guess that's probably https://bugs.edge.launchpad.net/bzr/+bug/485601
<ubot5> Launchpad bug 485601 in Bazaar "missing chk node(s) for id_to_entry maps (affected: 2, heat: 12)" [Medium,Incomplete]
<spiv> zpp: that bug seems to be stalled on a way for bzr devs to reproduce it, though
<spiv> zpp: I don't suppose your repositories are public? :)
<spiv> It's interesting that bzr-svn always seems to be involved.
<mohitranka> Hi...
<mohitranka> Is it possible to give access to bzr without creating a user account at the system?
<poolie> mohitranka, over ssh?
<mohitranka> Poolie, yes
<poolie> see http://doc.bazaar.canonical.com/bzr.dev/en/admin-guide/security.html#authentication
<zpp> spiv: yep I think so too... it's causing us a lot of issues so i'm hunting it now :)
<zpp> spiv: I actually believe it might be a race condition somehow...
<zpp> spiv: if you see jelmer before i do... can you let him know i'm hanging around?
<zpp> i have a fun way of reproducing the issue now it seems
<spiv> zpp: great!
<igc> night all
<zpp> spiv: unfortunately it's all closed source stuff so i can't gie direct access to the repo
<zpp> spiv: but it looks like under some conditions multiple svn checkins get identical bzr rev numbers...
<spiv> zpp: Hmm!
<zpp> spiv: and these checkins then appear in svn...but the files never appear (or the log entry) in a bzr clone of the svn repo
<spiv> zpp: anyway, please post about it on the bug report.  That will make sure interested people see it, and will help pool knowledge about what's going on
<zpp> spiv: yep... definitely will do :)
<bialix> hi all
<bialix> bonjour vila
<bialix> hi poolie
<vila> bialix: privet Sacha :)
<bialix> privet :-)
<zpp> jelmer: are you around atm?
<bialix> vila, at uds you asking me and Gary about adding new feature to qbzr
<bialix> vila: about checking branches and their relations with their parents/submit branches
<vila> bialix: yeeeees....
<vila> and ?
<bialix> vila: can you file a bug report please so we don't forget it?
<vila> I won't forget it (in fact I badly needed it again when my HD died),
<vila> but the last discussions left me with the idea that I could start with command-line plugin
<vila> if only to explore a bit what is needed there and provide low-level stuff for qbzr
<vila> or any other GUI  :-P
<jelmer> zpp: hi
<vila> bialix: I think I saw you continuing on your idea about branches in the same repo and being able to add/remove them interactively to qlog, which is also very good and complementary
<zpp> jelmer: hi.... I'm currently chasing on bug 485601 atm... would you have a moment to lend a quick hand? I have a theory... but am not sure how to reproduce atm
<ubot5> Launchpad bug 485601 in Bazaar "missing chk node(s) for id_to_entry maps (affected: 2, heat: 12)" [Medium,Incomplete] https://launchpad.net/bugs/485601
<bialix> vila: ok, just head up. I recall that discussion this morning and decided to ping you anyway
<vila> bialix: thanks, but don't worry, I won't forget this one
<vila> bialix: it just keeps haunting me every other day
<bialix> hmm, why people said that my summary about uds is very good? I've just written my personal impressions. I can't say for other: what they did, what they talking about
<bialix> vila: at least summary mail to qbzr ML will be good to have, maybe somebody else has similar ideas and willing to implement ;-)
<vila> bialix: sure, I'll try to do that as soon as I recover from the fallouts of my HD death
<bialix> oh, sorry
<zpp> jelmer: I believe there is a race condition in bzr-svn that can cause revisions to not be picked up by bzr from the svn repo
<vila> bialix: what ??? You're the one who killed my HD ?
<vila> :-)
<bialix> sorry for bother you while you in such problem
<fullermd> It's not dead, it's just in Vegas for the weekend.
<jelmer> zpp: there is an open bug report about an issue like that
<ignas> hi,  I am trying to install bzr on a mac, but seem to be unable to download the dmg file
<zpp> jelmer: I'm just finishing a script to reproduce it reliably, and a potential work around.  I'll file a new bug and you can mark as dup if it's the same :)
<ignas> I keep getting not-found error
<ignas> from launchpad
<vila> fullermd: you know the funny thing about that ? I'm pretty convinced now, that the OS tried to inform me about the problem via syslog looong ago (months), but always failed to do so because... the HD had parked its heads and was refusing all requests :)
<jelmer> zpp: cool,t hanks
<vila> fullermd: observing syslogd consuming 100% CPU is what led to me think about this scenario
<vila> syslogs 100% and no disk IOs ? Wtf ??
<fullermd> vila: Well, that's why you have the OTHER hard drive in the mirror, right?
 * fullermd hugs his ZFS close.
<vila> haaa, interesting solution... I still haven't played with raid so far...
 * fullermd twitches.
<fullermd> I haven't built a system in more'n a decade without it.  I'm not paranoid; I know for a FACT that hardware it out to get me.  I don't trust hard drives as far as I can swallow them.
<vila> That wasn't an option with that box anyway, I had to give it for repair as I couldn't access the single HD there (without removing the LCD and having to play with thermal glue or horrors like that)
<vila> HD failures are still rare enough for me that I can cure them on a case-by-case basis, I may have to reconsider though :)
<bialix> ignas: try later maybe
<ignas> bialix, I thought broken link maybe ;)
<bialix> which one?
<bialix> if there is broken liunk then it could be a bug in lp
<vila> bialix: no worries, you couldn't know :)
<bialix> I'm don't
<mgz> hey bialix, why did you put your diff filenames branch back to WIP? Looked good to land to me.
<bialix> mgz: heya!
<bialix> after some discussion I'd like to change mbcs to terminal_encoding and add --path-encoding command-line option
<vila> bialix: I think it would be better to land what has been approved first. A further (smaller) submission will be easier to discuss
<vila> (Just a general rule, I didn't follow closely enough to know if it was approved or if some tweaks were required)
<mgz> It was basically approved, and yeah, further improvements could land on top.
<bialix> then at least I should change from mbcs to terminal_encoding
<bialix> mgz, vila: ^
<vila> bialix: yup, sounds fine
<mgz> hmph, the problem with using terminal_encoding is you need to be sure it's actually ending up on the terminal (and in which case, you'd be better using unicode)
<mgz> mbcs is at least still a reasonable option if it's going into a pipe or file
<parthm> lifeless: ping
<mgz> he should be sleeping, unless he's not liking his bed again.
<parthm> mgz: yes .. just looked up the time in google ... 1am. i really should start taking timezones into account :)
<bialix> mgz: not really. mbcs is not good choice for piping
<mgz> depends where the pipe goes, which we can't know.
<bialix> mgz: with terminal encoding user can at least change that encoding with chcp command
<bialix> if I stick with mbcs then...
<mgz> if it passes through some byte-manipulating program and ends up on the terminal anyway, we'd want terminal encoding
<mgz> if it ends up in a file, we'd want mbcs (or utf8 perhaps)
<bialix> mgz: I think the main use case: show me diff on terminal (or paging it via more|less)
<bialix> mgz: if we want utf8, then I need --path-encoding option
<mgz> if it's going into a program for processing, lots of apps assume their input is in mbcs
<bialix> really
<mgz> yeah, the paging is the main breakage case
<mgz> more really screws things.
<bialix> vila, mgz: that's why I want to implement --path-encoding for landing
<mgz> but bialix, the current behaviour is a output with mixed encodings, and different from what I get if I use --diff-options=something
<mgz> so, the patch as it exists is an improvement
<mgz> (I happen to be in a locale where the terminal encoding equals the base encoding, so I'm a little biased :)
<bialix> yes, but I've asked people in ru_bzr, and consensus seems to be using terminal_encoding by default
<vila> bialix: I thought poolie wanted to do some infra work that could *also* handle --path-encoding ?
<vila> bialix: so that would be cleaner in a separate submission
<bialix> infra?
<mgz> yeah bialix, but they're biased because they have a different terminal encoding ;)
<bialix> of course
<mgz> I'd prefer we did printing to the terminal "right" and solved the paging thing seperately
<mgz> (there's no reason to encode to print to the terminal in windows, it's unicode anyway)
<mgz> (it's just pipes that are the problem)
<bialix> mgz: you know that we don't print on terminal buffer
<mgz> not terribly hard to change that though, if it'd actually help things
<bialix> yep, but...
<vila> bialix: infrastructure to be able to -opath-encoding=xxx without the need to define --path-encoding, or something along those lines
<bialix> vila: I'm not surte it will be so easy
<vila> bialix: which is why it's better as a separate submission :)
<bialix> OKAY I'M GIVE UP
<mgz> ehehhee
<mgz> we've worn him down!
<mgz> vila: two things I'd like to bug you about if you've got the time
<vila> bialix: :-) My feeling was that you and poolie had different pov on that, I don't want your actual submission to stay in the queue while it's sorted out, better land the already agreed upon stuff, that was my point since the beginning :)
<vila> mgz: don't ask to ask, ask :)
<mgz> it takes time to type!
<vila> oh sorry :)
<mgz> vila: 1 - I still don't quite get what state bugs should be ending up in when closed, some people have been setting milestones on things but I don't see any option to do that on launchpad or if I should be doing this
<mgz> ack, visitors have just arrived, I'll have to be quick
<GaryvdM> Hi bialix
<vila> 1) when a patch has landed is should be 'Fix released', before that it's 'In Progress' is someone is working on it, including waiting for review
<vila> mgz: we don't use 'Fix Committed' anymore
<GaryvdM> I guess that you were looking the 0.14.7 release
<GaryvdM> Hi all
<mgz> vila: 2 - if I want to create a branch, with no tree, for a test, so that I can then try and branch from it as if it were a remote repo, what's the right mechanism for that?
<vila> mgz: it's weird that you don't see milestones, it's the last column (Affects, Status, Importance, Assigned to, Milestone)
<vila> mgz: branch --no-tree (IIRC)
<vila> 'reconfigure --branch' may work too, but it may also be under the shared-repo control, I don't remember the exact rules there
<mgz> right, but if I want to do that for a test
<mgz> there must be a way not through run_bzr right?
<mgz> (I'm thinking specifically of testing filenames that can't be created on a windows filesystem, then trying to create a working tree from that branch)
<vila> bzrlib.branchbuilder.py, sorry I didn't realize you wanted that for tests
<mgz> thanks, will look for examples on that later
<vila> mgz: there are more and more examples using it as it's a good way to avoid blackbox tests
<mgz> seemed like it might be the right thing but slightly low-level and weird, what with having to make the magic root entries and stuff
 * mgz displays ignorance of how bzr actually *works*
<mgz> back to 1 again, eg bug 581298
<ubot5> Launchpad bug 581298 in Bazaar "bt.test__walkdirs_win32.TestWin32Finder.test_dir fails without ever being run (affected: 1, heat: 0)" [Undecided,Fix released] https://launchpad.net/bugs/581298
<mgz> should I be setting a milestone there?
<mgz> because launchpad gives me no box for doing it (it lists importance, but doesn't let me change it)
<vila> mgz: 1) we set milestone when the submission lands 2) looks like you're not in the right group :-/
<mgz> okay, so should set fixed released and the milestone at the same time?
<vila> you *should* be able to set the importance
<vila> yup
<mgz> okay, thanks!
<vila> mgz: meh, you're part of the contributot agreement group and nothing else it appears, try joining some bazaar group :)
<vila> mgz: and be ready to receive some related mail or double-check your subscriptions ;)
<vila> mgz: see http://launchpad.net/~bzr to join
<bialix> hi GaryvdM !
<bialix> GaryvdM: yes, I've looked at 0.14.7
<bialix> vila: btw, http://launchpad.net/~bzr said the team is restricted, and there is no easy way to say "I'd like to be a member"?
<mgz> right, I was just about to say that.
<mgz> okay, lunch for me.
<bialix> bon app
<GaryvdM> bialix: I'm quite sure that the 2.1 requirement was only introduced in 0.19b1.  See http://bazaar.launchpad.net/~qbzr-dev/qbzr/trunk2a/annotate/head:/NEWS.txt#L58
<vila> bialix, mgz : Hmm, but reading this page: 'Membership is granted to people who've already been active on the list' so presumably poolie or lifeless can add people there
<GaryvdM> http://bazaar.launchpad.net/~qbzr-dev/qbzr/trunk2a/annotate/head:/NEWS.txt#L44 (better context)
<bialix> my coworker have troubles to run 0.18 on bzr 2.0
<bialix> I don't have a details, but the only one answer for 2.0 was to use qbzr 0.14
<GaryvdM> bialix: Please ask him to log a bug.
<bialix> will try
<GaryvdM> bialix: If we don't fix the bug, then we should may be have more strict checks. (e.g. we could have checks in 0.14.7 with both minimum and max checks)
 * bialix is ok with that
<bialix> we can use bzrlib builtins check then, right?
<GaryvdM> blacklisting in bzr would also be nice...
<GaryvdM> bialix: Yes
<bialix> hehe, we finally found use case for that
<GaryvdM> bialix: There is a fix for a bug in 0.18. We just don't have a milestone...
<GaryvdM> bug 580798
<ubot5> Launchpad bug 580798 in QBzr 0.18 "treewidget shows wrong tree (affected: 1, heat: 6)" [High,Confirmed] https://launchpad.net/bugs/580798
<bialix> hmm, I don't see a new revisions in 0.18 after 0.18.6
<GaryvdM> bialix: The rev not yet in 0.18, but it was a daggy fix, so it will be really fast to merg.
<GaryvdM> *merge
 * GaryvdM does that now...
<GaryvdM> bialix: also bug 546843
<ubot5> Launchpad bug 546843 in QBzr 0.18 "bzr qlog broken with new 2.2.0 bzrlib API (affected: 1, heat: 6)" [Undecided,New] https://launchpad.net/bugs/546843
<GaryvdM> That description is misleading. I'm going to change that...
<bialix> I'd like to have those bugfixes in 0.18, so I can planning next release. can you add next milestone?
<GaryvdM> bialix will do.
<GaryvdM> bug 546843 - better now...
<ubot5> Launchpad bug 546843 in QBzr 0.18 "bzr qlog breaks when bzr-svn incomparable with bzrlib (affected: 1, heat: 6)" [Undecided,New] https://launchpad.net/bugs/546843
<bialix> I'm usually adding milestone when there is something to put into release
<bialix> ok
<GaryvdM> * incompatible...
<GaryvdM> ok
<GaryvdM> bialix: Are the qlog labels better now?
 * bialix pulling new revisions
<bialix> labels still is not uniques, but there are indeed tooltips.
<bialix> using tooltip is workaround
 * bialix still is not happy
<bialix> I will try to look into this in next days
<GaryvdM> bialix: Would you mind If I uncommited a rev in lp:qbzr/0.14 commited in the last few min?
<GaryvdM> I did it :~
<bialix> bbl
<sili> I have a shared repository where people do checkouts, commits, and also add new branches. Am I understanding correctly that a post-commit email hook cannot be installed on the repository, but a plugin should be installed on each bzr client?
<Raim> you could run a cronjob with bzr-email-notifier, which is able to scan for new branches
<sili> Raim: I think this will work; thanks.
<sili> Does anyone know if copying a bzr shared repository with rsync is a bad idea?
<sili> the copy will never be written to.
<GaryvdM> sili: I don't know.
<GaryvdM> sili: but there use to be a bzr rsync plugin
<GaryvdM> sili: It has been deprecated in faviour of just using bzr to pull.
<GaryvdM> sili__ ^
<GaryvdM> bbl
<MvG> lifeless: Care to re-review https://code.launchpad.net/~gagern/bzr/bug560030-drop-zsh-completion/+merge/25955 ? Addressed your fixing request.
<lifeless> MvG: thanks. The (gagern) isn't needed now, we auto-add that when sending it
<lifeless> moin moin everyone
<MvG> lifeless: Shall I strip it then?
<MvG> Oh, I see you did.
<lifeless> :>
 * MvG is glad to have two out of four open bzr merge requests ready to land.
<Guest5926> hi everyone, i'm jesse
<Guest5926> i'm thinking of using bazaar to record the history of wikipedia entries
<Guest5926> so i'm thinking of doing a sort of revision mapping
<Guest5926> are there any tutorials or dev doc i can refer to?
<MvG> lifeless: thx
<lifeless> anyone else notice that commit templates add lots of vws ?
<lifeless> jam: ping
<jam> lifeless: officially I'm on vacation today
<lifeless> jam: I'll be very quick
<jam> what's up?
<lifeless> I'd rathe rhav ethe Patch pilot week of the 21st, before vila inserted himself
<lifeless> can I swap that and the 28th with you
<jam> sure
<lifeless> thanks
<lifeless> now go repair your base :P
<vila> :)
<mgz> lifeless: "During the week I got tired of Martin[gz]'s patches" - ha, wrong move if you were tired of them!
<mgz> (think I provided what was needed via email, yell if there's anything else I need to do)
<lifeless> mgz: I pinged the rt ticket to say you'd added your key to launchpad
<lifeless> mgz: tired-of-manually-processing
<lifeless> not tired of the contributions.
<mgz> I know, just teasing :)
<lifeless> :P
<MvG> Lifeless: Shall I change the status of bug #560030 to committed or released?
<ubot5> Launchpad bug 560030 in Bazaar "Shell completion scripts outdated (affected: 1, heat: 6)" [Medium,Confirmed] https://launchpad.net/bugs/560030
<lifeless> MvG: if the branch landed, released
<lifeless> and set the milestone to 2.2b4
<MvG> Seems I can't set milestones.
<lifeless> ah
<lifeless> bzr-qa can, I think
<lifeless> mgz: reviewed your testtools change
<MvG> Do you want to set both, or shall I set the status without the milestone?
<lifeless> I've done it
<MvG> thx
<lifeless> no probs
<lifeless> thank you for doing all the hard work
<MvG> Oh! LP has the arrows the wrong way round in my rendering: {OLD_VALUE} <- {NEW_VALUE} instead of {OLD_VALUE} -> {NEW_VALUE}. Is it just me?
<lifeless> rendering where ?
<MvG> At the bottom of the bug report, where the changes are listed after the comments.
<MvG> Three boxes, for status, milestone and assignee, and all of them the same way round.
<MvG> Initial change after comment 1 the same as well.
<MvG> Hmmm... but the HTML reads &#8594; which in theory should be correct.
 * MvG scratches his head
<lifeless> milestone:	 none â 2.2b4
<lifeless> old -> new
<lifeless> what locale are you using ?
<lifeless> text rendering ?
<lifeless> are you using a RTL text layout or something ?
<MvG> de_DE, but LC_MESSAGES=C, Firefox, Gentoo, would really like to know what font it used.
<lifeless> please file a  bug
<lifeless> this would really confuse people *badly*
<MvG> Copy & Paste displays correct glyph, so it's FF or some aspect of my font system, not LP.
<lifeless> ok
<MvG> Added Add-On to analyze problem, restarted firefox -> problem gone.
<lifeless> hah
<mgz> lifeless: thanks! all the comments seem reasonable, I'd like to bug you a bit more about how to write the tests but will reply in the review later
<lifeless> absolutely
<mgz> before that, for the *other* patch, about stripping tracebacks
<lifeless> yes
<mgz> would the debugging-testtools-itself concern be resolved by having the base TestCase for testtools-itself tests override the module __unittest variable back to False resolve it?
<lifeless> you want to see me cry don't you
<mgz> well, I'm not sure which debugging methods you're most worried about, having testtools-itself tests displaying full tracebacks seems a reasonable requirement
<lifeless> I was teasing
<lifeless>  :P
<mgz> :P
<lifeless> seriously though
<lifeless> the __unittest variable is a terrible hack, IMNSHO
<mgz> this is not untrue, it is however, a hack that works.
<lifeless> Here's what I'd like:
<mgz> there are a couple of other options
<lifeless>  - unit-under-test frames are shown
<lifeless>  - infrastructure frames are not shown
<lifeless>  - when the same *line* is present in both sets, its still only shown for the unit-under-test frame
<lifeless>  - if we have two threads executing tests, they don't break each other
<lifeless>  - infrastructure frames from users of testtools are also not shown
<lifeless> fin
<lifeless> mgz: now, if this is too hard, we can look at doing something temporary
<mgz> I'm still not clear from that how we differentiate
<mgz> the callback-happiness of testtools is also problematic, can hop in and out of infrastructure code more than once
<lifeless> hmm, I'm not sure that it does
<lifeless> runtest and TestCase are both infrastructure
<mgz> (but the old way also had issues, failures inside infrastructure code (for instance not removing a dir in cleanup) tended to be stripped of traceback completely)
<lifeless> right
<lifeless> I think its crucial that we err on too-much-info
<lifeless> but I'd be delighted to reduce the error margin
<mgz> so, I can recode TestResult._exc_info_to_string to do... something not TestResult._is_relevant_tb_level related (which 'd remove some magic from the other patch as a side effect), the question is what
<mgz> testtools has enough levels of nested calls that it's annoying not to strip *something* even in the fail-inside-cleanup case
<mgz> it's not twisted-bad, but it's still pretty unreadable
<mgz> okay, I need to go off and cook now, but will think about it some more and try a couple of approaches
<lifeless> feel free to just brainstorm
<lifeless> I'm happy to put considerable effort into getting a good answer
<mtaylor> lifeless: heyho...
<mtaylor> lifeless: any idea what this means: bzr: ERROR: Tree transform is malformed [('unversioned executability', 'new-130')]
<lifeless> yes
<mtaylor> lifeless: awesome!
<mtaylor> lifeless: (I was trying to do a merge-upstream)
<lifeless> it means something is changing the +x bit on a file which is deleted / not added
<lifeless> please file a bug
<mtaylor> ok. will do
<mtaylor> lifeless: on bzr-builddeb? or on bazaar?
<lifeless> yes
<lifeless> (I don't know where the bug lies, so choose one)
<mtaylor> done
<rryan> Hey all, anybody know the bazaar equivalent of `hg outgoing' or `hg incoming' ?
<rryan> I searched a little bit but didnt find anything.
<mtaylor> rryan: what do they do?
<jelmer> rryan: bzr missing
<jelmer> rryan: it does both "hg outgoing" and "hg incoming"
<rryan> jelmer : thanks!
<rryan> mtaylor : outgoing tells you which local changesets would be pushed if you pushed, and incoming does the opposite
<mtaylor> rryan: gotcha. well, jelmer was quicker to answer than me - but yeah, missing will fix you up :)
<mtaylor> lifeless: I figured out the cause at least - in the tree I had moved a file, license.py, to internal/licensing.py and then added a new file called license.py
<mtaylor> lifeless: this caused merge upstream to become confused
<mtaylor> lifeless: if I re-expressed that in the upstream bzr tree as adding a new file internal/licesnsing.py and modifying license.py with the new contents - all worked fine
<lifeless> mtaylor: please add to the bug
<lifeless> mtaylor: probably tarball import related
<mtaylor> yup
<lifeless> bbs, <-> doctors
<poolie> hi all
#bzr 2010-06-01
<igc> morning
<lifeless> hiya
<codebrainz> hi.  is there something out there that "plugs in" to something like loggerhead to administer repos/branches/users and whatnot?
<lifeless> codebrainz: not that I know of
<lifeless> it might be nice though! perhaps you could file a bug on loggerhead asking for that
<lifeless> poolie: got a minute for a chat ?
<codebrainz> is loggerhead in python?
<lifeless> yes
<lifeless> launchpad.net/loggerhead
<codebrainz> maybe I'll work on a patch
<lifeless> that would be awesome
<poolie> hi there lifeless
<poolie> sure
<mwhudson> i think there is already a bug asking for more 'write access' type stuff in loggerhead
<steven_t> hello
<steven_t> have any of you previously used git or hg?
<mlh> I'm pretty sure everyone here would have tried both
<steven_t> whysat?
<mlh> steven_t: do you have a deeper question trying to get out?
<steven_t> no.
<steven_t> ive never learned a vcs before. i want to learn one but want my knowledge to be applicable and useful and relevant for years to come. researching which one to learn :)
<steven_t> so far git is the winner, because its so modularized and widely supported
<mlh> I think they're all very good, myself
<mlh> bzr and hg are supposed to be easier to learn, bzr in particular tries to be user friendly
<maxb> modularized?!
<mlh> steven_t: have you used other vcs's before, like rcs or cvs or svn?
<steven_t> none.
<mlh> the choice in part also depends on whether you're going to be casual or heavy user
<mlh> are you familiar with diff and patch?
<steven_t> no
<steven_t> i want to become a heavy user, im a coder and plan to be a professional
<mlh> what sort of coding and how long have you been coding?
<steven_t> well technically im already a professional, but what im learning in my spare time is more unixy than my dayjob (cocoa)
<steven_t> to answer your question: http://blog.degutis.org/post/651422590/i-think-im-a-little-crazy
<maxb> git is excessively complex, and rather arcane, IMO. I'd favour bzr or hg, especially if you're without previous VCS knowledge
<mlh> what maxb said.
<mlh> although without the 'excessively'
<mlh> nice read; either bzr or hg would be fine for you
<mlh> I'd also consider a code completing editor, although good fast typing skill is always valuable :-)
<mlh> django use svn, so you might want to try that first; sometimes the best thing to try is what the people who you work with use
<mlh> do you just use one machine mostly?
<lifeless> poolie: thanks :)
<igc> lifeless: I'm curious as to why pqm is failing. Does it try building the docs via the Makefile? Are there logs I can look at?
<lifeless> igc: yes, it builds the docs - we check they build on every commit, just like code
<lifeless> [which is another reason I want all the docs in the one tree, but thats a different discussion]
<lifeless> igc: its building in a very small chroot, that only has default packages + what we've specifically asked for. We haven't asked for any sphinx stuff, and I don't know what ones to ask for.
<igc> lifeless: we need python-sphinx
<lifeless> is that the entirety ?
<igc> lifeless: 0.6 or later
<igc> lifeless: I believe so
<lifeless> hah
<lifeless> so we're still on hardy
<lifeless> it has < 0.5.2
<lifeless> sorry, <= 0.5.2
<igc> lifeless: building the PDFs are messier though - LaTeX toolchain
<igc> lifeless: it *may* work there (in terms of building something)
<lifeless> I'm loathe to disable checking the docs on commit
<igc> i.e. 0.5.2 may be ok
<lifeless> we've caught doc syntax errors that way
<lifeless> I'll file an rt
<lifeless> and we can see what happens.
<igc> lifeless: I agree - let's keep the doc build step as a check
<igc> lifeless, poolie: was there a consensus on https://code.edge.launchpad.net/~ian-clatworthy/bzr/cmds-in-userref-585667/+merge/26004 ?
<poolie> igc if it doesn't break the import tests it's ok with me
<lifeless> igc: I'd be happiest with just calling the register method from the doc generators
<lifeless> igc: because they are essentially mini front ends, its appropriate that they do that
<lifeless> igc: this isn't in conflict with poolies comments
<igc> poolie: test_import_tariff passes with my fix fwiw
<poolie> then it's ok with me
<lifeless> its not with me
<poolie> if someone later wants to tighten it up while keeping both your test and the import tariffs passing they can
<lifeless> it will undo work done for commandant
<igc> lifeless: how?
<igc> lifeless: it only uses the builtins if none are already registered afaict
<lifeless> igc: right, so if none are registered you'll show the bzr specific ones
<igc> lifeless: yes
<lifeless> which is wrong
<lifeless> if none are registered, none are registered
<lifeless> I appreciate that there is a little bit of code tension here, because we have generic and bzr specific stuff in the same module.
<lifeless> but I really do think its worth having a clear separation
<poolie> mm, this code is not super generic at the moment anyhow
<lifeless> poolie: its used as a generic core by commandant, by lptools, and possibly others
<spiv> I thought commandant reimplemented it?
<lifeless> as jkakar wanted more facilities he decided to layer on us
<lifeless> I reworked things to make that possible
<spiv> Ah ok.
<lifeless> he has a patch to further reduce stuff in commandant, but that got push back
<lifeless> and it outside of the commands.py core anyhow, it was about reuseing the cmd_help object and the like
<lifeless> s/it/is/
<lifeless> igc: poolie: What would convince you to keep the query/setting code paths separate? It seems obvious to me that that is desirable, and I'm not sure how to convince you.
<lifeless> igc: poolie: Its roughly 30 seconds work to add a call to the set function from the doc generator code, so its clearly not about the effort involved :)
<poolie> lifeless, i'm pretty sure i made the change that ian's correcting here, not jamu
<lifeless> poolie: I'm pretty sure I made it
<poolie> ah
<igc> lifeless: we don't know how many clients are broken by the change
<lifeless> poolie: but lets look deeper
<lifeless> ok
<igc> lifeless: at least the doc generators are broken - they are easily fixed
<lifeless> poolie: I think you're right, the doc generators already call install_bzr_command_hooks
<lifeless> ok, land it.
<lifeless> my complaint is rescinded
<lifeless> sorry for the noise
<igc> lifeless: I'm not sure the doc generators call install_bzr_command_hooks btw
<lifeless> igc: see generate_docs.py
<lifeless> igc: that is the front end, isn't it ?
<igc> lifeless: yep - it is
<lifeless> igc: it appears to call it
<lifeless> igc: please do correct me if I'm wrong
<igc> lifeless: you're correct - my mistake
<igc> lifeless: i was looking in the layer below last week (bzrlib/doc_generate)
<lifeless> so install_bzr_command_hooks is the thing that should be called to make bzr commands visible
<lifeless> it installes _get_bzr_command
<lifeless> and _list_bzr_commands
<lifeless> and if its not enough, then there is a bug
<lifeless> which is why I've retracted my objection: I was misremembering the function name I needed to care in detail about
<lifeless> \o/ 247 emails unread, down from 1400 this morning (UDS and moving backlog finally getting under control)
 * igc lunch - bbl
<lifeless> EODing - started at 6
<bialix> hi
<bialix> igc: still here?
<igc> hi bialix!
<bialix> hi igc!
<bialix> I have a question about bzr-exlorer project
<bialix> there is separate documentation for it
<bialix> where is the branch?
<igc> bialix: lp:bzr-explorer-website
<bialix> igc: I think it's worth to change ownership of this project to bzr-explorer-dev or something similar. what do you think?
<igc> bialix: +1
 * igc looks
<bialix> who is in charge to upload these docs to bazaar site?
<bialix> igc: ^
<igc> bialix: it's done automatically by a cron job ...
<bialix> ?
<bialix> directly from your branch?
<igc> just make the changes to bzr-explorer-website and it will appear within an hour typically
<igc> from trunk, yes
<bialix> so so, branch ownership should be changed to explorer-devs too
<bialix> igc: anything other I should be aware of?
<igc> bialix: maybe the bzr-docs team ought to be the maintainer of bzr-explorer-website?
<bialix> maybe, I dunno
<bialix> igc: there is no bzr-docs team on lp
<bialix> ~bzr-doc is
<bialix> I'm ok with ~bzr-doc as owner
<bialix> igc: when your vacation starts?
<igc> bialix: I'm around this week and next
<igc> bialix: till the 9/Jun at least
<bialix> ok
 * bialix has no more questions so far
<bialix> thanks igc!
<igc> bialix: fyi, most of the other bzr doc projects are maintained by Bazaar Developers (~bzr)
<igc> bialix: that's a restricted team
<igc> which I'm thinking the owner of bzr-explorer-website ought to be
<igc> otherwise, anyone can "join-up" and spam the site
<igc> bialix: ^^^
<igc> bialix: is switching ownership to ~bzr ok by you?
<igc> (i.e. ownership of bzr-explorer-website)
<bialix> mmm, yes
<bialix> but *I* am not memebr of ~bzr
<bialix> need to join (again)
<igc> bialix: yes, I just noticed that
<bialix> I will do
<igc> bialix: cool (and thanks)
<bialix> :-)
<fullermd> Shucks, after all that time keeping ~bzr bialix-free...
<bialix> today is holiday?
<bialix> fullermd: yep :-(
 * bialix waves on fullermd
 * igc waves to fullermd too!
 * beuno waves at igc 
<igc> hi beuno!
 * fullermd gets a little seasick from all the waving.
<bialix> more waves for you: ~~~~~
<fullermd> Oooh...  urrrg...   blech.  This must be how Windows developers feel all the time   :(
<bialix> rotfl
<bialix> not really
<igc> bialix: ok - bzr-explorer-website now maintained by ~bzr and trunk moved accordingly
<bialix> igc: thanks
<parthm> I am getting these gc warning while running some tests. http://pastebin.com/00H7XCn0 ... is this something that I should be worried about?
<parthm> this is the test producing the warnings .. http://pastebin.com/KhTkcnV1
<spiv> parthm: yes, that's worth worrying about
<spiv> It indicates that some objects have been locked but not unlocked.
<spiv> Which is usually a relatively minor issue, but it should be easy to correct (and if it isn't then it suggests a deeper problem)
<parthm> spiv: so could this be an issue in test or the code?
<spiv> In this case there's nothing in your test method directly that is locking the tree, so I would suspect the code is at fault.
<parthm> by test i mean test case. and code is feature.
<parthm> spiv: ok. thanks. will check code.
<bialix> poolie: thanks!
<bialix> hey spiv
<spiv> Hey bialix
<parthm> is 'self.add_cleanup(tree.lock_read().unlock)' the recommended way now as against try/finally? .. i think the gc issue was due to unlock not being in finally for cmd_ignore.
<parthm> i am wondering if i should add_cleanup or try/finally.
<spiv> add_cleanup
<spiv> There should be something in the dev docs about that
<parthm> spiv: ok cool. that was the problem. i will add_cleanup to cmd_ignore.
<parthm> spiv: thanks
<spiv> Hmm, the docs do mention @only_raises, but don't seem to have been updated to mention bzrlib.cleanup or Command.add_cleanup
<spiv> Just quickly, the rationale for preferring add_cleanup is a) it behaves better when multiple exceptions occur, and b) it avoids extremely indented code just because some code needs three different resources acquired and released.
<parthm> spiv: that makes sense. thanks. add_cleanup fixed it.
<vila> spiv: quick chat about leaks ?
<vila> spiv: or did you EOD already ?
<poolie> hi there vila
<vila> poolie: hey !
<spiv> vila: sure
<vila> spiv: so, regarding our discussion at UDS, I'd like to tweak my description :) The problemS occur when the main thread, close a socket handled by another thread
<vila> spiv: does that make more sense ?
<spiv> vila: if you mean 'while another thread is concurrently performing operations on that socket', sure
<vila> spiv: yes, generally listen (Though I avoid that case by faking a connection) or just waiting in a recv() call
<spiv> That seems fairly clearly a bad thing to do... does our test suite ever try to do that?
<vila> spiv: so, next, the smart server create a thread for each client connection and make it a daemonic one, errr, push this subject on the stack
<vila> spiv: to reclaim the threads, yes,
<vila> spiv: the server collects the threads as connections occur and in stop_server() calls shutdown(RW)
<vila> the threads are blocked otherwise waiting for the client to speak
<vila> the client sockets are opened, waiting to be used by their respective transport
<vila> we don't have a transport.close() to get out of this loop and I don't want to add it before addressing the leaks
<vila> I will need it anyway as when all leaks are fixed, a full selftest run fails with Too Many Open Files, most of them being transport sockets
<vila> so I first need a way to completely shutdown the server, including all threads, not relying on the daemonic ones anymore
<spiv> vila: hmm, so you are saying that it can leak fds if one thread does sock.close() while another thread is doing sock.recv() on the same sock?
<spiv> Or are you saying something else?
<vila> the other side of the socket (the client one),
<vila> shutdown() + close() actually (I couldn't find a confirmation that one will call the other)
<spiv> So the main thread doing server_sock.close() succesfully closes the server_sock fd and causes the associated thread to terminate, but the client socket is not released too?
<vila> yes
<spiv> Ok, that sounds like a bug in our client code to me.
<spiv> Possibly in our test infrastructure for our client code.
<vila> spiv: the transport contract says the socket will remain opened so far
<spiv> Right.
<vila> and as long as we don't try to manipulate it, there is no point where we can realize it's closed
<spiv> The fact the contract doesn't facilitate this doesn't contradict my claim ;)
<vila> I suspect that python can't either so it can't gc it either
<spiv> There are a couple of options.
<vila> spiv: I wanted to understand if 'bug in our client code' was covering this
<spiv> Well, but in our test infrastructure at least.
<spiv> s/but/bug/
<spiv> Whether we decide it's ultimately because the Transport API doesn't provide a way to close connections isn't yet settled in my mind.
<vila> backtracking a bit: 'bad thing to do', yes, but what can be the consequences ?
<spiv> So, actually, I think calling close() in one thread while another does recv() is reasonable.
<vila> spiv: no problem with that, as long as the test infra can use it :)
<spiv> It's arguably a workaround for a more elegant way to interrupt the worker thread, but in practice it seems to behave the way we'd like it to.
<vila> spiv: knowing that exceptions in threads are caught and re-raised at join time to make it possible to ignore the socket ones occuring in this context
<spiv> s/for a/for the absence of a/
<vila> yup, exactly
<spiv> (And glancing at the CPython source for socketmodule.c it seems to be robust enough to make sure the close(fd) really will be called)
<vila> an alternative will be to use timeouts, but I've encountered too many problems with this approach and I'd prefer to avoid it if possible
<spiv> I vote very strongly for steering well clear of Python's socket timeouts.
<spiv> So there's a fairly cheap thing we could do.
<vila> spiv: but close() itself doesn't ensure the other side is notified right ? There may still be data to be transmitted no ?
<spiv> Which is add a hook point that is called every time ConnectedTransport makes a connection
<vila> yeah, I overrided transport.get_transport, same result
<spiv> Then the test suite could install a hook function to collect those connection objects, and then close them after every test.
<vila> yeah, addCleanup(disconnect_transport)
<vila> disconnect_transport is an ugly hack so far testing for attributes called 'close' or 'disconnect' :-D
<spiv> I think that would a reasonable thing to do.  I don't think it would get in the way of possibly adding an official "close connection" API to transport later, and might even be an incremental step towards that.
<spiv> It would also be useful as a debugging tool, perhaps.
<vila> exactly, this doesn't address what close connection should mean: always close, close only for the last user of the shared connection, etc
<spiv> I could imagine writing a plugin that counts the number of connections, same sort of thing as how -Dhpss etc can report stats about other things.
<vila> hmm, yeah, a hook is better than overriding get_transport in that case, I'll keep that in mind
<spiv> And a hook on "create connection" rather than get_transport in general.
<vila> sure
<vila> transports can be created but never connect
<vila> now, about the samrt server itself
<vila> smart
<vila> a daemonic thread is created for each client connection
<vila> this interfere in my leak hunt :)
<vila> most of the test use SmartServer_for_testing, but some don't
<vila> most of the tests use SmartServer_for_testing, but some don't
<vila> I tried to change them but failed, lost in the difference parameters used for __init__ and start_background_thread (from memory)
<spiv> Well, why not do the same thing?
<vila> collect threads ?
<spiv> Add a hook point to bzrlib.smart.server that is invoked for every new thread?
<spiv> There's already an overall server_started (and server_started_ex :/) hook point.
<vila> here you are, thanks, that's the bit I came here for :-)
<vila> a bit more work, but definitely the way to go, hooks are good
<vila> :)
<spiv> I think you only need to invoke it from SmartTCPServer.serve_conn
<vila> spiv: a 'connection_started' hook... yes
<spiv> Or perhaps from the target func it uses.
<vila> that's the one I override in _for_testing
<vila> may be, I have to do the same kind of stuff for http/sftp anyway, I'll try to unify
<spiv> It's not perfect, as the server does occasionally create other threads
<spiv> (to handle insert_stream requests)
<spiv> But I think probably that it will be good enough.
<spiv> vila: btw, jml filed a bug asking about a way to close bzrlib transport connections for launchpad's test suite
<vila> ha ha, thanks for the tip, I still have a few leaks without explanation so far (but nothing critical anymore)
<spiv> vila: if you do address this be sure to find that bug and let jml know how we're dealing with a similar problem
<vila> spiv: hehe, I commented there :) Th problem is on my radar for eons, I wanted to address the server side of the problem first to avoid masking it
<vila> success: the gross hack keep the open files to ~50 instead of >1024 !
<vila> with some fallouts for gio and ftp accounting for ~70 failures but that's expected
<vila> pfew, I see the light !
<vila> spiv: thanks for the teddy-bearing, very valuable !
<spiv> vila: nice work!  Glad I could help :)
<vila> spiv: by the way, bzrlib.smart.server.SmartTCPServer uses a timeout,
<vila> I understand why, yet, it contradicts your recommendation... Why ?
<spiv> Because the world is imperfect :(
<vila> grr, I meant: reading the code I understand why you used it, but why take the risk ?
 * spiv looks
<spiv> Erk, so it can break out of blocking accept once per second to check if it should stop?  Ugh.
<vila> also, isn't there a potential bug there, related to leaks, for a loooong live running smart server ? (Hitting the too many open files limit or something)
<spiv> Gosh I wish we could use Twisted for this stuff.
<spiv> Not that I know of, why do you think so?
<vila> shooting in the dark here, but in case some weird bug came out of lp, that may be worth looking at
<spiv> The leaks we've been discussing are client-side.
<vila> so far yes, I'm now talking about the smart server creating a daemonic thread in serve_conn
<spiv> I don't recall any bug reports about 'bzr serve' running out of fds.
<vila> ok, good to know :)
<spiv> When the client disconnects that thread will stop.
<vila> hmm, that's the point where I don't know *when* it will stop
<vila> after all, the client leaks in selftest are kind of a mirror scenario
<spiv> I do know when it will stop.
<vila> tell me :)
<spiv> It will stop when it tries to read from the socket and finds it has been disconnected.
<vila> when will it try to read ?
<spiv> All the time, except when actively working on processing bytes it has already received.
<vila> then it will block waiting for the client, what if the client crashed  and can't properly close the socket ?
<spiv> (and if it is in the middle of calculating a response then that means it's either about to try writing the response, or about to try to read more bytes of the request)
<spiv> Well, if the client drops of the internet suddenly and never manages to send a FIN etc then yes the socket will hang around indefinitely.
<vila> guarded by some timeout ?
<spiv> I don't think so.  Timeouts are a risky proposition.
<vila> no no, not by us, I was thinking by the TCP stack or something
<spiv> (Both in that historically Python's socket.settimeout feature has had subtle bugs, and that you can get false positives if the client really does want to be idle for 2 hours)
<spiv> Oh, well, some platforms allow you to set a system-wide timeout for checking if a TCP still seems to be alive.
<vila> hmm, ok, out of scope for today and the hook should be far enough for the tests
<spiv> But no, we don't do anything about that in bzr.
<spiv> It would be good to do so, I think.
<spiv> But judging from the lack of bug reports about it I don't think it's a high priority :)
<spiv> Yeah, a hook would be handy there, especially if it is passed the thread object and the socket object.
<vila> sure, I wanted to mention the idea in case it would light a bulb for you
<vila> spiv: for my purposes, both are needed :)
<spiv> Because then it makes it possible to write a plugin that arranges to e.g. use Linux-only magic to set TCP keepalives per socket.
<spiv> vila: great :)
<vila> spiv: just for fun, have  a look at bzrlib.tests.stub_sftp.SokectListener for the last biggest source of thread leaks :)
<spiv> vila: I've had that fun in the past, I hope you don't mind if I pass on that tonight ;)
<vila> hehe, np, enjoy your evening :)
<peitschie> evenin all :)
<poolie> hi there
<peitschie> hi :)
<AntoineLaf> I'm fairly novice at using bzr and today got stuck with a problem while trying to commit changes to a local branch. bzr just freezes and does nothing... I can run status or log or diff on the same branch, but it hangs when trying to commit the changes done to a single file. Did other commits on the same branch earlier in the day. I know this isn't much to try to help me, but if anyone could point me to some things that is possible to do to tr
<AntoineLaf> find a bit more about what might be the source of the problem, I would apreciate.
<jelmer> AntoineLaf: how big is that single file?
<AntoineLaf> it is a simple settings.php file
<tumbleweed> hi. I just filed https://bugs.edge.launchpad.net/bzr-rewrite/+bug/588249 anyone got any ideas?
<ubot5> Launchpad bug 588249 in bzr-rewrite "[regression] Rebase onto previous revision carries merge-metadata (affected: 1, heat: 0)" [Undecided,New]
<AntoineLaf> 12kb
<jelmer> AntoineLaf: in that case, no idea
<jelmer> AntoineLaf: you might want to try to see what it's stuck on using strace
<AntoineLaf> jelmer: that's exactly the kind of advice I was looking for :) thx
<AntoineLaf> now I need to know what strace is... :)
<AntoineLaf> ah, okey, I see how this could bring some light on the problem.
<jelmer> tumbleweed: hi
<jelmer> tumbleweed: what do you mean with "will show merge history" ?
<tumbleweed> jelmer: commit 2 is now a merge commit
<jelmer> tumbleweed: of what exactly?
<jelmer> tumbleweed: also, is this with trunk?
<tumbleweed> jelmer: http://paste.ubuntu.com/442742/
<tumbleweed> yes, tested with trunk
<tumbleweed> it used to do the right thing, but started doing this a few months ago. I put it down to ineptitude with rebasing until today :)
<peitschie> jelmer: have you got any time to lend a hand in figuring out how to repair https://bugs.launchpad.net/bzr-svn/+bug/587819 ?
<ubot5> Launchpad bug 587819 in Bazaar Subversion Plugin "race condition when doing a bzr commit to an svn repo (affected: 1, heat: 6)" [Undecided,New]
<jelmer> tumbleweed: thanks for the bug report
<tumbleweed> jelmer: np. glad someone can understand it
<jelmer> peitschie: sorry, I'm working at the moment
<peitschie> jelmer: nps.  I'm simply under some heavy time constraints... if i can't get the repository repair in the next day we probably will be forced to move back to pure svn
<jelmer> peitschie: The only real solution is to lock the root of the tree
<peitschie> jelmer:... obviously not my first preference :)
<peitschie> jelmer: the pre-commit hook i wrote should prevent it for the interm... it's trying to fix the existing data that is causing issues.  I can't create a clean checkout in it's current state
<jelmer> peitschie: one of the alternatives is to remove all bzr revprops from the later revisions
<jelmer> that means your history will diverge but you should be able to check out the branch again
<peitschie> jelmer:  sounds like a plan.  I'll give that a try and see how badly it fails :)
<peitschie> jelmer: just to update, removing the bzr revprops really makes a mess of any existing bzr-svn branches (made with the corrupt info).  I'll have to see if I can work around it... but this looks like it might be a little too much work to fix :(.  that race condition bug really makes a mess!
<peitschie> thanks for your help though... and the otherwise wonderful plugin :)
<csgeek_> is there something like gitolite/gitosis that exists for bzr?
<nDuff> csgeek_, what _are_ gitolite or gitosis?
<nDuff> csgeek_, web frontends? PQMs? ...?
<nDuff> re the former, I think Loggerhead is preferred
<csgeek_> it allows you to limit what user can write to what using ssh RSA/DSA keys
<nDuff> ahh
<csgeek_> basically security mechanism for granting user rights to a repo and limit what they can and can't do
<csgeek_> rathern then relying to unix permission.  Also prevents users from deleting "master" or whatnot
<nDuff> see http://doc.bazaar.canonical.com/bzr.dev/en/admin-guide/security.html
<csgeek_> thanks nDuff
<nDuff> csgeek_, ...that said, my preferred route to controlling who has commit where (and under which circumstances they can commit, ie. forcing unit tests / formatting checks / whatnot to pass) is use of a PQM.
<csgeek_> PQM = https://launchpad.net/pqm ?
<nDuff> csgeek_, and that class of tools, yes; there are a few for git also.
<csgeek_> I'm familiar with the git tools, it has a few shortcomings, at least work preferes bzr (:
<jjann> Hi. I started playing around with the externals plugin and navigated myself into a "situation". I first checkout out a svn repo inside m bzr working dir, then added it to .bzrmeta/externals. that broke because the url I used for the svn checkout was different than the one in the externals file (which I noticed on bzr ci), I then deleted the svn checkout and the externals-snapshot file but now I can't commit anymore. bzr ci always gives me:
<jjann> bzr: ERROR: Not a branch: "/path/to/bzr/repo/svn/repo"
<jjann> bzr st says nothing about that director though, it just shows the removes externals-snapshot
<jjann> removed even
<jjann> any hints on how to get out of this?
<csgeek_> wow.. so when I make a new branch, that requies a new directory to be created.   bzr branch . foobar would branch the current repo to the directory foobar.
<nDuff> csgeek_, there's an experimental colocated branch support plugin, and proper support should eventually show up in a release.
 * TresEquis finds bzr's non-colocated branches much easier to work with than the git / hg model
<TresEquis> especially with the "shared repository" format
<lifeless> :)
<mgz> garyvdm: re expensive plugins, I bet you're being screwed just by qt import times, it's a big thing
<mgz> unless you're already very careful about lazy loading?
<GaryvdM> mgz: we are very carefull about lazy loading.
<GaryvdM> mgz: it's importing bzrlib.branch
<GaryvdM> mgz: but I think the method that I used is not very accurate. :-(
<mgz> measuring startup time isn't
<mgz> you can do cold startup properly on nix as well, which will give you bigger numbers
<mgz> what was the magic drop-caches command again...
<GaryvdM> hmm - let me try that
<mgz> echo 3>/proc/sys/vm/drop_caches
<mgz> after a sync.
<GaryvdM> mgz: do you know what I'm doing wrong here?
<GaryvdM> http://pastebin.org/
<GaryvdM> http://pastebin.org/298078
<mgz> your shell doesn't seem to support time taking arguments
<mgz> (time bzr rocks) 2> plugin_profile.txt
<mgz> maybe?
 * GaryvdM tries
<GaryvdM> mgz - that works, but I also want to do time -f %E bzr rocks - What shell should I use?
<mgz> bash -c "help time"
<mgz> and see what it offers
<mgz> otherwise... well, see what else you have installed
<GaryvdM> hmm - thats very different to "man time"
<GaryvdM> mgz: got it
<GaryvdM>  /usr/bin/time -ao plugin_profile.txt -f %E bzr rocks
<mgz> a, ha.
<csgeek_> how do I delete a remote branch?
<csgeek_> I suppose I can ssh and rm -fr, but is there some mechanism via bzr
<mgz> just do the obvious.
<jam> csgeek_: 'bzr remove-branch'
<jam> though that was added in the 2.2 series
<GaryvdM> mgz: just sent a mail with the cold cache results.
<lfaraone> One of the users of GroundControl is getting http://people.ubuntu.com/~alanbell/Screenshot-Bazaar%20Error.png when attempting to push to a remote lp repository. (bug 587051) Should we handle this in GC, or is there a failure on the bzr side?
<ubot5> Launchpad bug 587051 in groundcontrol (Ubuntu) "repository incompatibility error message fixing bug in dasher (affected: 1, heat: 10)" [Undecided,New] https://launchpad.net/bugs/587051
<GaryvdM> lfaraone: The error message could be more friendly...
<lfaraone> GaryvdM: okay, what exactly is the problem encountered, and can it be fixed programmatically?
<GaryvdM> lfaraone: not programmatically
<GaryvdM> lfaraone: either upgrade lp:~vcs-imports/dasher/trunk, or...
<mgz> garyvdm: that's interesting, very different result, presumably more penalty from not lazy loading other needed modules and less from hooks in bzr core
<mgz> wonder what the search plugin is doing
<GaryvdM> lfaraone: recreate lp:~alanbell/dasher/bug..... as a --1.14 branch
<GaryvdM> lfaraone: see bzr help current-formats
<GaryvdM> lfaraone: You can convert a non-rich-root format to a rich-root format, but not the other way around :-(
<GaryvdM> http://pastebin.org/298236 with search
<GaryvdM> http://pastebin.org/298243 --no-plugins
<GaryvdM> mgz: ^
<GaryvdM> mgz: bzrlib.branch, bzrlib.xml4
<mgz> hm, so that is mostly what john was saying in the last mailing list post.
<GaryvdM> Could be more lazy
<mgz> though, making the commands that don't touch branches 100ms faster still seems worthwhile
<GaryvdM> mgz: Also I want to bring up the gui before bzrlib.branch is imported...
<GaryvdM> Hi vila
<vila> GaryvdM: hey !
<GaryvdM> vila: I'm getting some test failures, an I want check if they are also happening on babune.
<GaryvdM> vila: But I cant access babune
<vila> where ?
<GaryvdM> vila: karmic
<vila> lol, I meant failures where ?
<vila> and what do you mean by "can't access" ?
<GaryvdM> vila: http://pastebin.org/298300
<GaryvdM> oh
<GaryvdM> http://babune.ladeuil.net:26862/grid
<GaryvdM> vila^
<vila> babune is blue and almost sunny
<GaryvdM> oh - thats the old address
<vila> wow, wow, wow, that's the old buildbot one, yeah ;)
<vila> http://babune.ladeuil.net:24842/ should be better
<vila> GaryvdM: And I thought you were running lucid ?
<GaryvdM> vila: thaks
<GaryvdM> vila: lucid on laptop, but not upgraded on the desktop.
<vila> GaryvdM: beware, I started keeping various versions here and there and I ended up running babune :-P
<GaryvdM> vila: Yhea - I'm just lazy to upgrade.
<lfaraone> GaryvdM: okay. our goal is to avoid requiring users to have to manually do any of that. So, in the future, we should make sure that our new branches are created with the same format as the source?
<GaryvdM> lfaraone: Yes
<GaryvdM> lfaraone: bzr also needs a command that you can create a shared repo, in the format that you are going to branch into
<GaryvdM> lfaraone:  we currently don't have a nice way to do that :-(
<GaryvdM> vila: any idea why I get these failures, and how to fix: http://pastebin.org/298327
<vila> GaryvdM: hmm, that vaguely rings a bell... is it with --no-plugins or anything fancy ?
<vila> GaryvdM: anything weird with time or file system there ?
<GaryvdM> vila: yes
<GaryvdM> vila: yes --no-plugins
<GaryvdM> vila: ext4 fs
<GaryvdM> vila: going to try on the lucid laptop
<vila> What can I say, using /tmp/testbzr-buzGMO.tmp is asking for trouble, tests don't like being called buggy gizmos even in disguise
<vila> :)
<vila> so, debugging it manually is hard, it's a blackbox one, but you could try setting a breakpoint before the failing assertion, pp self.test_dir, open a terminal there and try looking around
<GaryvdM> vila: ok
<vila> including running ${TEH_RIGHT_PATH}/bzr st or ${SYSTEM_WIDE_INSTALLED}/bzr st
<GaryvdM> vila: also fails on lucid laptop
<vila> revno ?
<GaryvdM> 5274
<vila> right, passed tests on babune
<vila> 5274 on trunk right, no local changes ?
<GaryvdM> yes
<GaryvdM> hmm - some unknown files. let me try bzr clean-tree and run again
<vila> GaryvdM: no !
<GaryvdM> why?
<vila> wait, keep them in a safe place, there is no known reason for interference from the source tree, if it is the case, we have a bug
<vila> GaryvdM: so, put them aside and retry and but I won't hold my breath
<GaryvdM> vila: I allready did it on the desktop, but it's also failing on the laptop, so we can debug there if needed
 * vila reading the test
<vila> urgh, one more eager test....
<GaryvdM> vila: I rm the wt, did a checkout, make and it passes now
<GaryvdM> vila: Going to debug on the laptop
<vila> GaryvdM: anything in your setup related to .... what ?
<GaryvdM> vila: Sorry - don't understand the question.
<vila> I stopped writing when you said you fixed the problem by rm'ing your wt....
<GaryvdM> ok
<vila> You had a dirty wt ?
<vila> on both machines ?
<GaryvdM> yes
<vila> tell us your dirty secrets will you...
<vila> what did *you* do to that poor wt ?
<vila> unresolved conflicts ?
<GaryvdM> Not sure
<GaryvdM> The plot thickens
<GaryvdM> The wt was not related.
<GaryvdM> If I run ./bzr selftest --no-plugins branch - I get the failures
<GaryvdM> If I run ./bzr selftest --no-plugins -s bzrlib.tests.blackbox.test_status.CheckoutStatus.test_branch_status - it passes
<GaryvdM> vila^
 * vila trying
<vila> with -s the plugins are loaded
<vila> err, sry, you have --no-plugins there too
<vila> eeeerk
<vila> vada retro satanas failing here, I wasn't there I hear nothing, I saw nothing
<vila> so, this smells test isolation
<vila> maybe a hook was added recently in this area and was not registered in b.h.known_hooks ?
<GaryvdM> vila: There was a BZR_PDB for tests, but I can't find it now.
<GaryvdM> vila: Maybe it was in my imagination ...
<vila> hmm, no I think there is one
<vila> BZR_TEST_PDB
<GaryvdM> vila: Thanks. btw where did you find that?
<vila> emacs...
<vila> :-P
<vila> I searched for PDB in bzrlib/tests/__init__.py
<GaryvdM> ok
<vila> GaryvdM: can you run qblame bzrlib/status.py and tell me if th revnos are truncated for you too
<GaryvdM> vila: Yes
<GaryvdM> vila: we try guess how much space we need, by just looking at the tip revno. We should look at the length of each revno that is shown
<mgz> but see bug 504070
<ubot5> Launchpad bug 504070 in testtools "testtools change broke BZR_TEST_PDB (affected: 1, heat: 8)" [Wishlist,Triaged] https://launchpad.net/bugs/504070
<GaryvdM> vila: taking into account font metrics, I'm worried that it will be slow.
<vila> GaryvdM: just give me a way to resize interactively :)
<GaryvdM> vila: yes
<vila> GaryvdM: do you often run ~3000 tests in a single selftest ?
<vila> GaryvdM: did your failing runs ended mentioning a high number of leaking tests ?
<GaryvdM> vila: no - I want to make some imports lazy in bzrlib.branch - so I want to test lots of things
<vila> the no was for the ~3000 ?
<GaryvdM> Yes
<GaryvdM> vila: 17 non-main threads were left active in the end.
<vila> how many leaking tests ?
<GaryvdM> bzrlib.tests.blackbox.test_branch.TestBranchStacked.test_branch_stacked_from_smart_server is leaking threads among 13 leaking tests.
<vila> next line
<vila> err, what 13 only, lier :)
<GaryvdM> vila: bzr: interrupted - I'll run it again
<j0rd> I'm about to switch my whole VCS over to git, sell me on bzr. I'm interested in installing and using launchpad and just read about the usability of bzr. got me thinking
<vila> haaa, I got 591 leaking tests and 166 non-main thread left active
<mgz> hey, that's better than 1600
<vila> on top of that, there are may sockets left open, so you may be experiencing a 'Too Many Files Open' exception that is silently swallowed
<vila> mgz: that's for trunk :)
<GaryvdM> j0rd: Here is a page with good reasons: http://doc.bazaar.canonical.com/migration/en/why-switch-to-bazaar.html
<j0rd> GaryvdM: reading it now
<j0rd> GaryvdM: i was interested in real users expereiences as well
<vila> once I finished implementing all my pending tricks, I should be close to 0 unexplained thread leaks
<j0rd> i use ubuntu as well, which is another selling point of bzr, but other than that....i've never really heard of people using it
<mgz> if you can get the working set of a full test run back down to 200MB rather than 1GB I'll be very happy
<vila> mgz: and by cheating a bit I know that instead of >1024 sockets for a full run, I'm now at ~50 (some of which being "valid")
<vila> mgz: no idea about that yet, first things first :)
 * vila back to hacking
<kostja_osipov> j0rd: we use bazaar quite extensively here at MySQL, moved from BitKeeper.
<kostja_osipov> I'd say it's a pretty good tool, although we do have internal advocates with git
<kostja_osipov> the main selling point for me with bzr would be that you can get paid support from the vendor for it.
<j0rd> kostja_osipov: i assume you have used the others as well "cvs, svn, git?" which is the stream i'm coming from.
<kostja_osipov> svn was out of the question when we migrated, being a "better cvs"
<kostja_osipov> git was high on the list, mainly because of its speed.
<j0rd> kostja_osipov: alright, not looking for paid support, but i do like the web frontend launchpad...which currently is my major selling point. I need something web frontend, that i can show to my clients and have them interact with for bugs and documentation
<kostja_osipov> but git wasn't as mature as it is now when we migrated, back in 2008
<vila> GaryvdM: one more thing: 'branch' get you 3000 tests, most of them involving servers, with leaks, so you're doing the opposite of the --parallel=fork trick: instead of spreading the leaks, you're attracting them :-D
<kostja_osipov> j0rd: well, that's launchpad platform, it's way more than just bzr
<mgz> <kostja_osipov> but git wasn't as mature as it is now when we migrated, back in 2008 <- it was, it was just less of a meme than it is now
<j0rd> kostja_osipov: i'm aware of that, it's something I'll need
<kostja_osipov> we use our own development infrastructure (e.g. bugs.mysql.com, with bzr triggers in python that keep the bug database in sync with the trunk state), and only partially integrate to launchpad
<GaryvdM> vila: ack
<kostja_osipov> mgz: we needed Windows support.
<mgz> which git still doesn't have.
<mgz> running half a unix system underneath it doesn't count.
<kostja_osipov> mgz: when you choose a tool for a large open source project, you want all platform to be well supported.
<kostja_osipov> and bzr was better than others in that.
<mgz> bazaar has improved much more in the last two years than the other vcses
<kostja_osipov> mgz: well, I think it's better now than before. I haven't been looking
<j0rd> ease of use is important for me, because i'm a free lancer and if the people I work with can't figure out my VCS, it'll cause problems
<j0rd> another reason I'm looking towards bzr right now
<mgz> you can get a pre-packaged msys with your git now, it is still a sucky option
<GaryvdM> vila: that test says it is a blackbox test. I thought that ment a subprocess, but that is not the case. Is my understanding of what blackbox implies wrong?
<kostja_osipov> mgz: Haven't been watching closely. I can say bzr still has a way to go to be my real BitKeeper replacement. But I can't say it doesn't get the job done.
<kostja_osipov> and in some parts it's of course better than bk
<mgz> yup, there's a long way to go all round.
<kostja_osipov> j0rd: how big is your project?
<vila> GaryvdM: yes, a blackbox test runs with stdout/stderr/stdin redirected, subprocess is not a requirement and we try to avoid them
<kostja_osipov> how many people work on it?
<j0rd> kostja_osipov: many small projects, for one off clients
<vila> GaryvdM: stdout/stdin being redirected, pdb can't be used
<j0rd> kostja_osipov: about 1-3 months in lenght each
<j0rd> kostja_osipov: drupal development. Ubercart uses bzr as well
<j0rd> and i do mostly ubercart work
<j0rd> so another selling point
<kostja_osipov> I'd say if you're under 500 000 and 5 years of active history, you won't notice much of bzr drawbacks.
<kostja_osipov> at least they are not apparent to me on that scale.
<j0rd> kostja_osipov: i'm really just looking for a frontend to my VCS, so that i can update my clients on progress upon commit and self document along the way. allowing them to see progress, track bugs and i can document features as they get built
<kostja_osipov> my issue was with performance and with bzr file-ids...
<kostja_osipov> and some gui quirks... I'd like the gui to be more flexible.
<kostja_osipov> but otherwise... does the job.
<j0rd> kostja_osipov: ya, i'm fairly VCS agnostic to be honest. so the front end interface for my clients is actually more important to me. and having other colaborators pick it up easily
<GaryvdM> kostja_osipov: Which gui: gtk, or qbzr?
<kostja_osipov> (and you only start to be getting performance issues when  you're in millions of slocs)
<kostja_osipov> I use gtk but I miss some very specific interface that was good in BK
<kostja_osipov> gotta go (dinner)
<j0rd> kostja_osipov: thanks for your insight, very helpful
<GaryvdM> j0rd: It is very easy to run your own loggerhead. (http://bazaar.launchpad.net/~qbzr-dev/qbzr/trunk2a/files is loggerhead)
<vila> kostja_osipov: tell us at least what you're missing, we're holding our breath !
<vila> kostja_osipov: :)
<GaryvdM> kostja_osipov: If you don't mind qt to much, give qbzr a try.
 * GaryvdM plugs away shamelessly
<kostja_osipov> I will. I'm missing bk sccstool to be precise
<kostja_osipov> where you start with the revision history tree view, and can scroll back and forth in time and instantly get to every changeset.
<kostja_osipov> really need to go
<GaryvdM> kostja_osipov: sounds like bzr qlog
<jjann> I have a branch with a broken attempt of trying bzr-externals, everytime I try to commit on this branch, I just get an "bzr: ERROR: Not a branch: /path/to/the/old/external/thingy", any hints on how to get past this? I tried using uncommit to get to a stage before this happened but no luck
<jjann> ok, deleting .bzrmeta/externals completely helped
<GaryvdM> vila: test results: http://pastebin.org/298796
<GaryvdM> vila: The problem is caused by trace.is_quite() returning True. I'm going to log a bug.
<GaryvdM> Ah - Allready loged. 579996
<GaryvdM> bug 579996
<ubot5> Launchpad bug 579996 in Bazaar "test_status failure on trunk (revno 5227) (affected: 1, heat: 6)" [Medium,Confirmed] https://launchpad.net/bugs/579996
<Abhijeet> hi all
<Abhijeet> our company currently using jazz clearcase server from IBM
<Abhijeet> we are thinking to replacing this with new SVC..
<Abhijeet> Our servers are based on HPUX os.
<Abhijeet> so is BZR well supported on it?
<maxb> HPUX is pretty rare. Your chances of finding someone who knows about it on IRC are fairly slim
<maxb> But if it can run Python and a decent C compiler, chances are good
<Abhijeet> hpux has it's own compilers.
<exarkun> bzr locks seem to last across reboots on Windows
<exarkun> That's a bit unfortunate, eh?
<GaryvdM> exarkun: you just need to break the lock with bzr break-lock
<exarkun> GaryvdM: I know.  But I don't see why I should need to.
<bialix> heya
<GaryvdM> Hi bialix
<bialix> I have question about pqm setup
<bialix> actually 2 questions
<bialix> 1) Does example in the HACKING.txt is still correct? it talking about sftp and b-v.o URLs so it seems pretty outdated
<bialix> 2) Why it so overly-complicated? Is there wrapper around pqm plugin suitable for lazy and dumb windows devs who need only submit requests to bzr pqm?
<bialix> hi Garyvdm
<GaryvdM> bialix: yes HACKING.txt does seam out of date. From my locations.conf: http://pastebin.org/299166
<GaryvdM> bialix: re question 2 - It does not only apply to windows...
<GaryvdM> exarkun: Probably not the most knowable person to answer that question. I believe it is because the locks are handled by bzr, and not the os, and bzr does not know when the machine is restarted.
<GaryvdM> exarkun: The reason why bzr handles the locks, is it needs to be able to write to transports like ftp, where we can't do os locks.
<exarkun> GaryvdM: That's probably true.  bzr should use a lock that gets reset across reboots, instead of whatever it uses now.
<exarkun> I filed a bug report, https://bugs.launchpad.net/bzr/+bug/588431
<ubot5> Launchpad bug 588431 in Bazaar "bzr locks persist across reboots (affected: 1, heat: 6)" [Undecided,New]
<GaryvdM> ok
<bialix> exarkun: I don't think so
<bialix> GaryvdM: oh, nice, thanks for the example
<exarkun> bialix: The purpose of the lock is to prevent concurrent access.  If the lock was held by a process that existed before the last reboot, then there is no chance of concurrency.
<bialix> exarkun: the problem with limbo is a known bug
<bialix> exarkun: everything else is require more intelligence than bzr has right now
<bialix> it's not so hard to run break-lock, is it?
<exarkun> Yes, it is.
<bialix> GaryvdM: cool, I was not sure I can use lp: style urls
<exarkun> If I were actually the agent running "bzr checkout", then maybe it wouldn't be so hard to manually break the lock.
<exarkun> But I'm not.  An automated build system is.
<bialix> yep
<GaryvdM> bialix: yes, except for the submit branch.
<exarkun> So far I'm finding bzr to be somewhat lacking in reliability.  I could easily use svn in an automated build system.  It was slow, but it just about always worked.  bzr, on the other hand, is much faster for many operations, but fails in a lot of different ways.
<exarkun> So, I hope #588431 (and the other bugs I've filed) are considered real issues and eventually addressed.  I'd much rather be able to continue using bzr in the future, rather than having to switch back to svn.
<bialix> yes
<bialix> Garyvdm: I want a pony^W qpqm-submit command. And planning to do so tomorrow
<GaryvdM> bialix: :-)
<GaryvdM> bialix: I want to look at our start up time on windows
<bialix> btw, I've started dogfooding bzr-explorer every day
<bialix> it needs to be improved
<bialix> one things that bother me: we need to invent a way to add "edit file" command to treewidget context menu
<bialix> GaryvdM: cool
<GaryvdM> I did a clean install of windows, and the start time is not bad. But I have seen on windows installs that have been around for a while, the start up is very slow.
<GaryvdM> bialix: like you laptop.
<GaryvdM> *your
<bialix> hmm
<GaryvdM> Open = edit file
<bialix> no
<bialix> open is launched file
<GaryvdM> bialix: I would like to try make an installer without libaray.zip, to see if it makes a difference, but the instructions to build the installer made me very scared...
<bialix> so open for python file is just launched its execution
<bialix> GaryvdM: really? I'm ever don't know if there is up-to-date instructions
<bialix> why you need installer?
<GaryvdM> bialix: I think that maybe if we don't have libaray.zip, the start up will be faster, I would like to prove/disprove this.
<bialix> you don't need installer for this
<bialix> you can build bzr.exe with `python setup.py py2exe` command
<bialix> and there is one place n setup.py where you can control creation of library.zip
<GaryvdM> bialix: re Edit File - maybe show the options for the different edit applications registerd in windows, like windows explorer?
<GaryvdM> oh - ok
<bialix> GaryvdM: if you run bzr-explorer -- then you can see edit action (icon of paper with pen) which opens selected file in treewidget in the editor
<bialix> we need a way to mirror this action in treewidget
<bialix> allow explorer to inject this action
<bialix> IIRC there is bug report on this
<bialix> GaryvdM: which instructions scare you?
<GaryvdM> bialix: bzr.dev/doc/developers/win32_build_setup.txt
<GaryvdM> Thats just to install the dependencies.
<jam> GaryvdM: what is your alternative to library.zip ? A loose tree of files?
<GaryvdM> Then you have to get all the plugins
<jam> i'm pretty sure that would be slower
<GaryvdM> jam: yes
<jam> .zip already has an index at the back
<jam> and the actual content is stored uncompressed
<jam> And navigating the python import path is a real pain on Windows
<jam> (and so is trying to measure cold-start performance)
<jam> GaryvdM: I thought bialix had done some testing to show that the pre-built installer was quite a bit faster than running from source
<jam> but it has been a while
<GaryvdM> jam: apparently you can do   options = {"py2exe": {"skip_archive":1}}
<GaryvdM>  
<bialix> jam: it was faster for me, at least on FAT32
<bialix> but I can't say for sure about NTFS
<bialix> hi jam, btw
<GaryvdM> I think that a py2exe exe probably does not scan the installed python paths, which would explain why it's faster.
<bialix> Garyvdm: those could be simpler a bit: http://wiki.bazaar.canonical.com/BzrWin32Installer
<bialix> GaryvdM: actually py2exed application has only library.zipin sys.path
<bialix> GaryvdM: actually py2exed application has only library.zip in sys.path
<GaryvdM> bialix: Yes, thats what I was trying to say
<GaryvdM> bialix: thanks for the better doc.
<bialix> GaryvdM: they're out-of-date a bit
<bialix> feel free to blame
<GaryvdM> jam, bialix: we don't need MS Visual Studio for tbzr any more?
<bialix> no, we need
<bialix> maybe you can skip tbzr?
 * bialix is about to going offline
<GaryvdM> I thought that req was removed. :-(
<bialix> how fullermd said? rest is for wimps? so I am
<bialix> ~~~
<jam> GaryvdM: You need at least the 'light' version, but I've never actually worked out how to do it
<jam> naoki was good enough to figure out how to use express edition + an sdk
<jam> but as bialix mentioned, that is mostly just for the tbzr extension
<jam> I thought you had access to Desolation, though (the win32 build host)
<GaryvdM> jam: No :-(
<aarfeick_> I have a question on bug tracking... is anyone here knowledgable about it?
<mkanat> aarfeick_: Bug tracking in general, or bug-tracking with launchpad?
<aarfeick_> Well, I wrote my own bug tracker (as an exercise)
<aarfeick_> I developed a URL scheme to close bugs
<aarfeick_> My commits indicate the URL of the fix, but I don't think Bazaar is actually resolving that URL
<aarfeick_> Any ideas why?
<jelmer> aarfeick_: What do you mean with your commits indicate the URL of the fix?
<mkanat> aarfeick_: The bzr bugtracking support doesn't do anything to the bug-tracker.
<mkanat> aarfeick_: It just stores a URL to the bug-tracker in bzr.
<aarfeick_> When I use bzr commit -m "Test commit" --fixes my_tracker:123, the commit logs show the URL that I specified in my config
<aarfeick_> I see
<aarfeick_> I thought the point was to actually apply the fix using that URL
<jelmer> aarfeick_: no, it just tracks that a particular bug was fixed by a particular revision
<aarfeick_> I see...
<aarfeick_> I suppose I'd have to write a hook to do anything about it?
<mkanat> aarfeick_: Yeah.
<jelmer> aarfeick_: in launchpad's case it scans branches that are pushed for this revision proprety
<aarfeick_> Is there a (relatively) simple way to do so, that I could distribute to the rest of my development team? I fear I know nothing about bzr hooks.
<mkanat> aarfeick_: You could have the bug-tracker scan the VCS.
<aarfeick_> Oh... so it could scan the logs for the fix statement
<aarfeick_> My current implementation of the tracker is web-based so it can be used by other developers
<aarfeick_> So it would not be so simple
<lifeless> moin
<aarfeick_> In this case, I'd want to write a hook that "visits" a certain URL, which the bug-tracker uses to actually close the bug
<aarfeick_> Is there a *good* way to do this in Python?
<exarkun> By "visits" do you mean "issues an HTTP GET to"?
<lifeless> aarfeick_: a post commit hook could do "bzrlib.transport.get_transport(bugfix_url).get('.')" or you could use httplib/httplib2/twisted's getPage etc etc
<aarfeick_> exarkun: yes, an HTTP GET.
<exarkun> Yea, what lifeless said.
<exarkun> There's like a million Python libraries for that. :)
<aarfeick_> Excellent! I'm just learning Python (though I do know several other languages), and I figured this is a good useful project.
<aarfeick_> The tracker is in PHP
<GaryvdM> jam: Is there a reason bzrlib.errors one big file? It is quite costly to import.
<GaryvdM> dito for bzrlib.builtins
<GaryvdM> I'm trying to delay the importing of bzrlib.errors. It's a wack a mole game....
<lifeless> GaryvdM: they are
<lifeless> GaryvdM: I've considered a few things, like putting them one-per-error in separate py files
<lifeless> more realistic to do that for builtins to start with, I think.
<GaryvdM> lifeless: ok
<lifeless> GaryvdM: however
<lifeless> GaryvdM: for builtins.py we have to load it for most commands
<lifeless> GaryvdM: for errors, if we catch *any* exception, we have to load it.
<lifeless> So lazy loading is a misleading tool for performance improvements here.
<lifeless> The key thing is, how much code do we load *doing a users operation*
<lifeless> and how much code do we *use* to do that operation
<GaryvdM> lifeless: My objective is to get those things to only import after I have got a qbzr window up
<GaryvdM> lifeless: I know it's just delaying the inevitable...
<GaryvdM> lifeless: I've made some progress. I can now import bzrlib.branch with out importing bzrlib.repofmt.pack_repo :-)
<TresEquis> ugh, just had bzr revert --forget-merge still leave my sandbox hosed (due to conflicts)
<TresEquis> I would expect all the conflicts to get washed away by the revert
<lifeless> the difference is stuff we can work on
<lifeless> GaryvdM: how do users invoke qbzr ?
<GaryvdM> lifeless: Either the command line, or tbzr, or bzr explorer
<lifeless> details!
<lifeless> gimme gimme details
<GaryvdM> bzr qlog
<lifeless> ok
<lifeless> so
<lifeless> how do you feel about 'qbzr log'
<GaryvdM> lifeless: hmm - I don't know
<GaryvdM> lifeless: I'll think about that.
<lifeless> that would make it trivial to avoid builtins.py - you wouldn't want all the bzr commands loaded *anyway*
<lifeless> and similarly errors.py would only need commands.py and options.py to be audited
<lifeless> a small tweak to the command lookup invocation code in your frontend would make 'qbzr log' load 'qlog' as the command object
<lifeless> and you can register the stock bzr command providers after you're in your mainloop
<lifeless> [if you want them at all, that is]
<lifeless> if you're not calling into cmd_foo objects, then you don't need to register them *at all*
<GaryvdM> lifeless: I don't think builtins is a problem  - I'll check
<GaryvdM> lifeless: The other way to solve the problem is a central hook registry as per mailing list discussion.
<lifeless> that won't solve the problem
<lifeless> builtins.py, which you mentioned at :53 is *already* demand loaded by hooks
<lifeless> you'll get precisely 0.0 time saves from hook infrastructure changes for builtins.py
<IslandUsurper> TresEquis, I think bzr detects text conflicts from the markers in the files. revert --forget-merge doesn't touch the working tree, so the conflicts would remain
<lifeless> TresEquis: 'bzr revert' - resets files and merge info
<lifeless> TresEquis: 'bzr revert .' - rests just files
<lifeless> TresEquis: 'bzr revert --forget-merges' - resets just merge info
<GaryvdM> lifeless: ok - sorry the builtins comment was just an observation. The bigger problem is plugins importing bzrlib.branch to register hook.
<lifeless> GaryvdM: thats not a problem for the command line
<GaryvdM> lifeless: yes
<lifeless> GaryvdM: And there is a lot of stuff in branch.py we should move into a format package
<lifeless> like we did for repository
<lifeless> that would make branch.py cheaper
<lifeless> not saying that the hook changes might help
<lifeless> but for branch.py it only defers stuff
<lifeless> better to avoid it completely; and we have 4 formats or so, only need the code for one.
<GaryvdM> lifeless: Yes, thats what I've been trying to do (make import bzrlib.branch cheaper) (maybe with the wrong approach)
<TresEquis> lifeless:  thanks, that helps
<lifeless> GaryvdM: I'd like to see the following made cheaper "using a branch"
<lifeless> GaryvdM: think whole-operation costs, not import costs.
<lifeless> that would benefit *everything*
<GaryvdM> lifeless: ack
 * lifeless hands the furball back
<GaryvdM> http://bazaar.launchpad.net/~garyvdm/bzr/delay_imports/revision/5276
<GaryvdM> lifeless: ^ that makes import bzrlib.branch not import  bzrlib.repofmt.pack_repo
<GaryvdM> jon$yd
<GaryvdM> darn - wrong window
<lifeless> lol
<GaryvdM> time to change lots of passwords...
<exarkun> GaryvdM: To different things, this time.
<GaryvdM> exarkun: My brain wont cope with that
<exarkun> GaryvdM: That's okay.  Use technology.
<GaryvdM> exarkun: Important things like bank are different
<aarfeick_> How precisely would I use the iter_bugs function in revision.py?
<aarfeick_> I'd like access to the bug URL's for a revision in a post-commit hook.
<aarfeick> I am having trouble using iter_bugs() in revision.py...
<lifeless> yes?
<GaryvdM> lifeless: I just tested, and what I've done makes bzr status import less. (I'm not sure what exactly yet. It quite hard to compare 2 profile-imports)
<lifeless> GaryvdM: I'm not really all that interested in profile-imports
<lifeless> GaryvdM: I'm interested in 'time bzr st'
<GaryvdM> ok
<lifeless> with (say) a 20K file tree
<lifeless> or 100K if your machine is too fast to detect changes on 20K
<lifeless> GaryvdM: profile imports and similar are tools to direct performance effort, but they are poor proxies for actual time-spent.
<lifeless> GaryvdM: remember that importing all of bzr and plugins etc on modern machines is < 0.5 seconds
<lifeless> GaryvdM: oh also, if working on just getting-started speed, also time bzr st on very small trees
<lifeless> you'll have some chance of making the import time dominate
<GaryvdM> lifeless: yes - I've been timing bzr st on small trees, but not large trees
<lifeless> the risk with large trees will be near-zero if you're not changing code in loops
<lifeless> but I don't know what you're doing, so I mention it to make sure you're aware of the space we've optimised status within
<GaryvdM> lifeless: I'm also testing with cold cache, and warm cache
<lifeless> yes
<lifeless> jelmer: have you seen hydrazine?
<jelmer> lifeless: yes
<lifeless> I'd love it if you use it
<lifeless> because we could start generalising and pulling its features up into lp proper
<lifeless> you don't have to
<lifeless> just saying
<jelmer> lifeless: I do use it, I contributed some trivial fixes IIRC :-)
<lifeless> jelmer: ah! perhaps you have a stale branch :)
<jelmer> lifeless: which features are you thinking of though?
<jelmer> I've mostly used bugclient so far
<lifeless> feed-pqm
<poolie> hi jam
<poolie> hi lifeless, GaryvdM, jelmer
<lifeless> hey
<GaryvdM> Hi poolie
<GaryvdM> How come doing a status on a 2a branch imports xml code. I thought that 2a used bencode rather than xml.
 * GaryvdM sees if making that lazy makes a difference.
<lifeless> GaryvdM: better to not load it, than to make it lazy
<lifeless> GaryvdM: lazy loading has given us some really nasty structures
#bzr 2010-06-02
<lifeless> jam: do you want to talk about parth's patch ?
<lifeless> jelmer: feed-pqm will take the lp commit message and Just Work
<lifeless> poolie: I'm going to mail the bzr list about savannah now, unless you want to?
<poolie> go for it
<GaryvdM> lifeless: does it make sense that we should not have to import xml when doing bzr status on a 2a branch, or am I missing something.
<jelmer> lifeless: I haven't had feed-pqm working yet
 * jelmer tries to remember what was wrong last time
<GaryvdM> lifeless: I cant work out if the inventories are stored in xml or bencode
<lifeless> jelmer: please give it a shot and file a bug
<lifeless> jelmer: I want to stabify to death pqm-submit.
<lifeless> GaryvdM: in 2a? neither.
<lifeless> GaryvdM: commit objects are stored in bencode I think.
<lifeless> early CHK formats used xml commit objects
<GaryvdM> lifeless: Cool
<jelmer> lifeless: :-)
<jelmer> lifeless: will do
<igc> morning
<GaryvdM> Morning igc
<igc> hi GaryvdM
<poolie> +1 re pqm
<poolie> hi igc
<igc> hi poolie
<poolie> igc, can you catch up with jam sometime to hand over windows build stuff?
<igc> poolie: sure
<lifeless> \o/ I'm down to inbox 72
<lifeless> bbs, grabbing lunch
<eric_f> is there a way to "undo" a rename?
<eric_f> I did bzr mv --auto and it's pretty far off
<poolie> eric_f, mv --after to put it back the way you want
<poolie> lifeless, does anything else need to happen on 2.1.2 and 2.2b3?
<poolie> could you try to push the former into SRUs and backports?
<lifeless> poolie: I've put 2.1.2 forward for lucid already
<lifeless> I haven't done anything for backports, as you say its probably finding the right person to tickle
<lifeless> poolie: I put the 2.1.2 lucid SRU forward on friday
<poolie> great
<poolie> there is a bug asking for a backport...
<lifeless> I believe so
<lifeless> you've commented on it before.
<Jaearess> What does an asterisk by a file mean in the 'bzr status' command?
<Jaearess> My Google search only turned up a bug report that it wasn't documented, but not what it actually means.
<mwhudson> it means it's either gained or lost the execute bit since the last commit
<Jaearess> Ah, thank you.
<Jaearess> Someone wielding chmod -R 777 wildly would probably cause that to show up on a lot of files, correct?
<lifeless> yes
<spiv> Jaearess: yes
<lifeless> spiv: sigwinch is done, yes?
<spiv> lifeless: gosh I hope so!
<lifeless> just updating kanban
<spiv> Hmm.
<spiv> That was odd.
<spiv> My internet connection mostly dropped out... except I could still reach Google.
<lifeless> spiv: !
<spiv> Then Mary came home and the rest returned!
<lifeless> spiv: anyhow, while I'm looking at Kanban
<spiv> So, you were asking about sigwinch: yes that should be done -- we no longer register a sigwinch handler :)
<lifeless> do you want to confirm that you're (removing relocking, doing merge-subdirs)
<lifeless> which are the two things in kanban with your name on them
<spiv> Yes, confirmed.
<lifeless> if you're not doing either, we should put it back in the backlog
<spiv> I'm not actively doing removing relocking.
<spiv> But it is a background task I nibble at from time to time.
<lifeless> right
<lifeless> I don't think we've got a good way to really show 'not significant time' tasks
<lifeless> which I think that that falls under, no ?
<lifeless> 16:18 < bob2> yay, exetel plugged their international link back in
<lifeless> spiv: ^
<spiv> lifeless: ah, although it affected some .au stuff for me as well!
<lifeless> probably peered stuff
<lifeless> sign MS
<lifeless> please, if you're going to make a free virus scanner, don't make it broken.
<lifeless> you've got the dang OS source code in front of you.
<fullermd> Sure, but who can read it?
<lifeless> fullermd: their staff can, one hopes
<fullermd> Aw.  You're so coot when you're optimistic   :)
<lifeless> ha!
<lifeless> fullermd: http://preachsecurity.blogspot.com/2009/06/microsoft-security-essentials-road-test.html
<lifeless> fullermd: "Overall some things that I noticed is that the engine's real time protection is a little lacking, as it rarely (only once) caught the piece of malware as it was being unzipped, and typically only when I attempted to actually run the file."
<lifeless> oh and https://support.mozilla.com/en-US/forum/1/542294
<lifeless> for added value 'ms virus scanner breaks firefox. Yay.'
<mneptok> lifeless: most clergy have their holy books right in front of them, and really can't decipher them in any meaningful way, either. ;)
<lifeless> mneptok: I'm not sure fiction counts as source code ;P
<mneptok> lifeless: tell that to HURD developers.
<lifeless> LOL
<vila> hi all
<vila> poolie: ping, quick chat ?
<lifeless> poolie just popped out for a bit
<lifeless> try him again in 20
<lifeless> gnight
<vila> lifeless: thks, g'night
<poolie> hi vila
<NET||abuse> hey guys,, had a weird thing just happpen
<NET||abuse> i was changing permissions for access to a bzr repo/working copy to run on a server, the two users in question were in the same group, so i rann chmod -R 775 bzrrep/  where the working copy and standalone repo is on the server,
<NET||abuse> then as the second user i tried bzr up(i'd just pushed up a change from my local machine) but i'd failed to update permisisons .bzr.log, it ran the update and also gave an error saying permissino denied on that log file,,, problem is nwo when i run bzr st as either user in the working copy, everything is marked as modified.
<NET||abuse> i don't think it was doing that before now, though i didn't happen to check
<fullermd> Well, you set the +x flag on every file in the WT; presumably most of them didn't have it before, so that WOULD be a modification...
<NET||abuse> ohh, format: pack-0.92   is that out of date.
<NET||abuse> ahhhh
<NET||abuse> fullermd, of course, duh
<NET||abuse> so ye, it's got that change marked,, any wya to get it to disregard that change?
<fullermd> Disregard?  No.  You could use revert (or another chmod) to undo it.
<NET||abuse> or would i be better checking it out to a parallel directory location as the new user i want to switch over to using?
<flam> is there a command to update bazaar to a newer version? i'm using windows
<flam> bzr help commands didn't show it, neither did few minutes of googling:p
<mgz> flam: no, windows doesn't work like that. download and run the new msi. or a debiant install cd.
<mgz> -t
<starenka__> hi, sorry for silly question, but i have problems w/ group permissions while using bzr+ssh
<starenka__> i set umask in /etc/profile to 002 and it works in shell, but while pushing repo to server the repo is rw-r--r--  any clue?
<TresEquis> starenka__: google points to this: https://lists.canonical.com/archives/bazaar/2007q3/027560.html
<starenka__> thanks. i made a "wrapper" script in /usr/bin/local/bzr which sets umask and runs bzr
<starenka__> it works like a charm
<parthm> jam: ping
<jam> hi parthm
<parthm> jam: hi, i was thinking some more about the `bzr st` bad ignore pattern
<parthm> i am somewhat divided between warning / error but am leaning towards error. if we have a bad pattern other commands like `add` and `ignored` would fail anyway.
<parthm> i am not sure if there are others. so it may be better to fail quickly and have the user fix it sooner than later.
<parthm> there could also be a case that a user ends up pushing a bad pattern to their server/lp. as .bzrignore is already added. its just a `bzr ci` and `bzr push`.
<parthm> so failing on `st` may be a good idea.
<jam> parthm: why would add and ignore have to fail?
<jam> the point is that, especially right now, people may have a bad config
<jam> having it fall over when it used to work is bad
<jam> having it fall over *in general* is bad
<jam> I don't feel super strongly
<jam> but we've done the 'error early' in the past
<jam> and generally it has provided worse user experience
<jam> as a minor misconfiguration in X
<jam> suddenly blocks Y and Z from working at all
<parthm> jam: `ignore` works, it issues a warning and discards the bad pattern.
<jam> even if the pattern was already in the file?
<parthm> `ignored` fails as we compile all ignored patterns (99 at a time) into one pattern. so we cant selectively ignore.
<jam> you certainly *could*
<parthm> jam: yes. if  a file has a bad pattern, `ignore` would still work. so it issues a warning about the pattern on the command line. if the tree is processed, then a followup error is shown about the existing bad pattern.
<jam> parthm: the problem is that if we filter out the bad pattern from the disk content we make it harder to get the right pattern
<jam> since the old one is gone
<jam> it may be a fair trade
<jam> but something to be thought about
<parthm> jam: we don't filter out the bad pattern from the file. filtering is only for the command like. we display an error message for the pattern in file.
<parthm> jam: http://pastebin.com/fMWtEUjc
<jam> so for compiling, we could certainly attempt the 100-way compile and if it fails rollback
<parthm> jam: i am not sure i understand. are you talking about `ignored`?
<jam> yes
<jam> but also statu
<jam> status
<jam> add, etc
<parthm> jam: what do you mean by try the compile and rollback?
<jam> parthm: try to compile all 100, if it fails, compile them individually to find the one that failed
<parthm> jam: thats whats done in the current patch. the current patch allow the operation to happen, if there is an exception, it processes the file to find the bad pattern and displays it along with the error message.
<jam> so why does ignored *have* to fail?
<parthm> jam: so are you suggesting we retry after filtering out the bad pattern at runtime?
<jam> That is what I've been suggesting, yes
<parthm> jam: IMO once the user has a bad pattern in the file he would sooner or later end up with a problem so it may be better to just error out pointing to the pattern.
<parthm> i don't think existing installation would have a bad pattern as it would make bzr crash.
<jam> parthm: the difference is whether someone can still finish what they were trying to do
<jam> *before* they have to fix everything
<jam> or if they have to drop their train of thought
<jam> and go handle this thing
<parthm> jam: i agree with your point on 'train of thought' but the results of a command e.g. `ignored` may not be what the user expects due to the skipped pattern.
<jam> parthm: that is why we give a big warning
<parthm> jam: i suppose being a ui thing there is no obviously right answer :)
<parthm> jam: i will paste this chat on the merge proposal and probably others can chime in with their views.
<C-S> How can I add stuff to the bzr wiki?
<parthm> C-S: You should be able to create a login and edit it.
<parthm> C-S: What do you have in mind?
<C-S> parthm: I just added qbzr and bzr-explorer to the FreeBSD port system. That needs to be reflected in the downloads sections of qbzr and bzr-explorer.
<parthm> C-S: cool :)
<C-S> parthm: indeed. bzr-git and bzr-svn are under way :-)
<parthm> C-S: yay!
<C-S> parthm: which means we will have all necessary tools easily installable on FreeBSD!
<C-S> parthm: here is an example: http://www.freshports.org/devel/bzr-explorer/
<parthm> C-S: thats pretty neat. it should make things very convenient for a lot of users. the plugins you mention have dependencies and not the most convenient to install.
<C-S> parthm: right, that makes it much easier. bzr-svn requires subvertpy for example and bzr-git dulwich. The FreeBSD ports system installs them automatically as needed
<C-S> parthm: I had to port subvertpy too, of course.
<parthm> C-S: you can probably mention this on the bzr mailing list. there may be interested parties there too.
<C-S> parthm: You can have a look at the respective Makefile where all the dependencies are mentioned: http://www.freebsd.org/cgi/cvsweb.cgi/ports/devel/bzr-explorer/Makefile?rev=1.1;content-type=text%2Fplain
<C-S> parthm: good idea. I am not on these lists though. Do you have a link?
<parthm> C-S: i was a FreeBSD user for quite some time. been on ubuntu for about 2 years now.
<C-S> parthm: FreeBSD is a beauty. You should consider a switch :-)
<mgz> parthm: I'm massacring bzr-grep for fun, please review when I'm done
<C-S> parthm: cool. I am already working on a port for bzr-grep. Are you the maintainer?
<parthm> mgz: sounds good :)
<parthm> C-S: yes. i am the maintainer for bzr-grep
<C-S> parthm: if yes. please post your releases on launchpad. that makes it much easier for me to grab the latest copy.
<C-S> parthm: otherwise, I have to download via bzr and release 0.3.0 myself.
<C-S> parthm: that is annoying.
<C-S> parthm: second, that way, I'll have a second backup download site
<parthm> C-S: do you mean a tarball?
<C-S> parthm: right
<C-S> parthm: by the way. bzr-grep is absolutely great
<parthm> C-S: will do.
<parthm> C-S: good to know :)
<C-S> parthm: cool. Many many thanks. You make my life easier.
<C-S> parthm: as you know, people of FreeBSD don't want to release updates via bzr or some VCS. It just doesn't make sense for the average user
<C-S> parthm: so, tarball would be great :-)
<parthm> C-S: i agree.
<C-S> parthm: Great. So, I wait for your tarball and will then continue on the port.
<mgz> while I have you right here:
<mgz>     line = line.decode(_te, 'replace')
<mgz> why?
<mgz> and... wha?
<mgz> this is a raw line from a file we're greping through,
<parthm> C-S: when i was a casual bzr user i myself preferred installing it via apt-get on ubuntu. have been thinking of creating a ppa.
<mgz> that we want to print *to* the terminal
<mgz> why are we *de*coding it in the terminal encoding?
<C-S> parthm: sorry, but what is a ppa?
<C-S> parthm: something like a package?
<parthm> C-S: ppa is the package system for ubuntu.
<C-S> parthm: Ok. Sure, I agree, packages/ports are so much easier for most people.
<parthm> mgz: thats probably a bug then. my unicode-fu is not the best :( ... could you file a bug?
<C-S> parthm: and you usually have bugs in development, so it makes sense to stay with the official release as long as posible.
<C-S> parthm: anyway. many thanks.
<mgz> I'll just fix it when I'm done with this consolidation
<parthm> C-S: thanks for the freebsd ports :)
<C-S> parthm: sure. Its a pleasure.
<mgz> I might break some things, am touching a lot of code branches, but if I do, it's your tests fault :P
<parthm> mgz: great :)
<parthm> mgz: yes ... i think the tests should be sufficient. if not will add some more :)
<parthm> mgz: what are you looking into regarding bzr-grep?
<mgz> well, what I *started* looking at and what I'm doing are... nothing like each other
<mgz> I'm currently deleting code.
<mgz> I wanted to do some unicode things.
<mgz> hmmm:
<mgz> a = '\x1b[35m\x1b[35mfile0.txt\x1b[0m\x1b[1;36m:\x1b[0m\x1b[1;31mfoo\x1b[0m is \
<mgz> x1b[1;31mfoo\x1b[0mbar1\n'
<mgz> b = '\x1b[35mfile0.txt\x1b[0m\x1b[1;36m:\x1b[0m\x1b[1;31mfoo\x1b[0m is \x1b[1;31
<mgz> mfoo\x1b[0mbar1\n'
<mgz> I think I better go back to longer ansi sequences for the moment, to avoid confusing the tests
<LeoNerd> Can't you use an  \e  to help those
<LeoNerd> ?
<mgz> oo, but I've duped the lead in.
 * mgz fixes that
<parthm> mgz: the unicode support is probably not the best in bzr-grep. this was before i really actually understood unicode :P .. not that i get it fully yet.
<mgz> well, it's largely not your fault anyway, you're kinda stuffed on knowing what the file contents are
<mgz> anyway, so what I'm doing currently is making bzr-grep a bit slower so I can delete some code, and make it faster
<mgz> what it comes out the other end like, I have no idea
<parthm> mgz: i am glad to have another pair of eyeballs on bzr-grep. thanks.
<mgz> okay, I'm just gonna change the test on that bit, saves an ansi switch
<mgz> bom ta dom ta dom
<parthm> well, its getting late here. goodnight.
<mgz> night!
<vila> mgz: ping
<mgz> boingy.
<mgz> vila: any fun progress on leaks?
<vila> yeah, a robust socket server in a thread, with fresh tests
<vila> Oh, and clear road ahead to turn my experiments into production
<vila> mgz: see my pm ?
<ompaul> can anyone tell me how to dig around in a bzr .pack file
<jam> ompaul: in general, the contents aren't going to be very friendly to generic digging, is there something specific you are trying to do?
<ompaul> just curious to see what happened historically
<jam> ompaul: trying to see the history of individual files?
<ompaul> jam, I have a 30 meg pack file
<ompaul> out of 42megs
<ompaul> kind of like s2n :)
<jam> ompaul: you might be interested in https://edge.launchpad.net/bzr-repodetails
<jam> ompaul: we collapse pack files over time
<ompaul> ok
<ompaul> thanks
<jam> so that 30M is probably the bulk of your history
<ompaul> it is since day one
<ompaul> jam, thank you for that
 * ompaul wanders off to share this new clue file 
<lifeless> vila: hi
<lifeless> vila: what did you find to be the cause of the leaks?
 * vila waves
<vila> the cause was known for a long time: http server threads,
<vila> I've found some server in the sftp area
<vila> The main source of problems was uncaught exceptions in these threads especially when I started closing their socket from *another* socket
<jam> hi vila, go to bed :)
<vila> jam: hey ! Yeah, yeah, bed, good
<lifeless> vila: ok cool
<lifeless> vila: uhm, the paste web server has code to kill threads
<lifeless> hi jam
<jam> lifeless: ouch, somebody creamed you in bym
<lifeless> yeah
<vila> lifeless: *kill* threads ? Via a C extension ?
<lifeless> took them 6 waves of 48 ichis
<lifeless> and then 2 more waves to get resources
<lifeless> vila: ctypes; have a look at it
<jam> lifeless: yeah, I find that putting ProjectX in there actually helps a lot
<jam> 2 X's is as much dps as the other 41 Ichis, and if you stagger them correctly, they usually help to take out a tower or two
<vila> lifeless: that would complement what I just did quite nicely.. I'll check
<jam> (if a snipe focuses them they go down in 2 hits, though)
<lifeless> jam: i think she was pissed that in 4 waves I made a pretty deep dent in her yard
<jam> lifeless: who?
<lifeless> april
<lifeless> the person who attacked me [just a random neighbour]
<jam> sorry, can't help, not in my neighbor list :)
<lifeless> :)
<lifeless> jam: I was looking at kanban
<lifeless> yesterday; I'm wondering if its a little stale
<lifeless> are you stil working on win32 installer scripts, historydb, fetch perf and annotation caches ?
<jam> lifeless: the historydb stuff is pretty much done, so I moved it over
<jam> the rest, yes
<james_w> abentley: do you know how to deal with "bzr: ERROR: Format Checkout reference format 1 cannot be initialised by this version of bzr." and a broken branch when using reconfigure-pipeline?
<james_w> well, I've got my branch back, but I have no idea what the error was telling me to start with
<james_w> ah, API issues due to colo change
<james_w> fixed by pulling bzr-pipeline, thanks abentley
<abentley> james_w, happy to help :-)
<bendj> I logged into a client's box to try to un-fubar some of their recent work.  @ a 'bzr pull' I get "bzr: ERROR: exceptions.ImportError: cannot import name LogicalLockResult" ( more -> http://pastebin.com/EbC5jCf5)
<bendj> New one on me ... though I notice they've bzr 2.2b3.  Sound familiar to anyone?
<jam> bendj: sounds like api skew, where some of there modules are up to date, and some are not.
<jam> Since 2.2b3 isn't packaged yet (I believe) you might try deleting the existing install, and installing from scratch again.
<bendj> jam: k. brb ...
<lifeless> ok
<lifeless> some to overhaul branch cloning a it
<lifeless> *bit*
<bendj> jam: cleaned house, dropped back to a 2.1.0 tarball, up'd to 2.2b3 trunk, reinstalled modules.  back in business ... except for one plugin: dulwich
<bendj> getting,
<bendj> Pulling /usr/local/lib/python2.6/site-packages/bzrlib/plugins/dulwich from bzr+ssh://bazaar.launchpad.net/~vcs-imports/dulwich/trunk/
<bendj> Not a branch: "bzr+ssh://bazaar.launchpad.net/~vcs-imports/dulwich/trunk/".
<jam> bendj: "bzr pull --remember lp:dulwich"
<jam> I'm guessing the trunk location moved
<bendj> jam bingo.  thanks!  now back to our regularly schedule un-fubaring ...
<jelmer> lifeless: hi
<lifeless> hi
<jelmer> lifeless: are you aware of a good way to store version info in a single file?
<lifeless> you mean like bzr version-info ?
<jelmer> lifeless: I'd like it to be available from both __init__.py and setup.py
<jelmer> but there doesn't seem to be a good way to do that that doesn't break BZR_PLUGINS_AT and 'bzr plugin-info'
<exarkun> jelmer: The least terrible option I've heard is to keep it in package/version.txt and read it from setup.py and __init__.py.  But clearly there are plenty of pitfalls there.
<jelmer> exarkun: yuck :-(
<lifeless> jelmer: how does it break things?
<jelmer> lifeless: they don't support relative imports
<jelmer> so 'import info' from __init__.py doesn't work
<lifeless> what!
<lifeless> it sure should
<jelmer> it doesn't work when using BZR_PLUGINS_AT
<lifeless> sounds like a bug in BZR_PLUGINS_AT
<lifeless> theres no reason it shouldn't work
<jelmer> ok, that's easy then
<vila> lifeless: there is one: it's a bug :-(
<lifeless> I fixed a bug in plugin-info a short while back to permit doing this
<lifeless> so it *was* working
<lifeless> vila: sounds like BZR_PLUGINS_AT isn't finished then.
<jelmer> it works when not using BZR_PLUGINS_AT
<vila> the problem is that during the import of the plugin's __init__.py the module path is not set, so plugins that are fully lazy work (the module path *is* set *after* the __init__.py file load :-/
<jelmer> I've been using it for quite some time and I remembered 'bzr plugin-info' was broken
<jelmer> but it works now :)
<vila> lifeless: it escaped the tests... I have some idea about a possible workaround but no time to investigate
<vila> namely: force a dummy module with the right path into sys.modules
<vila> but I don't know if python will like that...
<jelmer> vila: should I file a bug?
<vila> jelmer: sure
<lifeless> vila: I have no idea what BZR_PLUGINS_AT is doing, but I suspect its about 1000 time more complex than needed
<lifeless> :)
<vila> lifeless: if you can cut the number of lines by 1000, I'll give you a bottle of champagne :)
<lifeless> vila: :P
<vila> lifeless: I went with the lightest way I could think of relying on... some python provided load_module which obviously doesn't address this "detail" :-)
<lifeless> vila: load_module in plugin.py ?
<vila> lifeless: yeah, it uses imp.locad_module and then set the mod._path__, this 'mod' is then inserted into sys.modules by python I think
<vila> s/locad/load/
<lifeless> vila: do you need help with it
<vila> lifeless: to try that ? No, I need time :-/
<vila> I thought I was the only one blocked by it and went with creating a symlink in bzrlib/plugins instead (temporary :-/)
<vila> yeah, I know, I should have filed a bug, bad vila
<lifeless> go sleep
#bzr 2010-06-03
 * jelmer yells at libapr
<poolie> hi all
<spiv> Good morning.
<lifeless> hi guys
<poolie> hi there spiv
<mwhudson> jelmer: hey, do you want to make launchpad work with bzr 2.2? :-)
<poolie> mwhudson, what's broken?
<mwhudson> i can't remember
<mwhudson> the usual sort of boring things i think
<poolie> failing tests in integration?
<mwhudson> yeah
 * mwhudson is trying to dig up a buildbot log, the openid process is a little slow over 3g
<mwhudson> hm, the compile is failing currently, but that looks like an image problem
<mwhudson> src/zope/interface/_zope_interface_coptimizations.c:15:20: error: Python.h: No such file or directory
<mwhudson> (that's not even the build of bzr)
<mwhudson> hee hee, making bzr whoami mandatory seems to have broken some tests
<mwhudson> poolie: failing tests from a couple of weeks back: https://lpbuildbot.canonical.com/builders/bzr/builds/200/steps/shell_8/logs/summary
<mwhudson> i guess we have some bzr-using tests that don't inherit from bzrlib's testcase, maybe
<poolie> wow
<poolie> probably
<poolie> look at all that crap :)
<poolie> what are the dns failures about?
<mwhudson> not sure
<mwhudson> _probably_ the image is old and needs stuff adding to /etc/hosts
<parthm> i was looking at bug #488519 what would be a way to handle this. abort the operation telling the user to change the name? any suggestions?
<ubot5> Launchpad bug 488519 in Bazaar "[master] UnicodeDecodeError in osutils.walkdirs with non-ascii filenames (affected: 12, heat: 26)" [High,Confirmed] https://launchpad.net/bugs/488519
<poolie> oh hi parthm
<poolie> dude you're fixing all our bugs! :-}
<poolie> i think in the first place it would be good to at least just print the name of the problem file
<poolie> what actually should happen
<parthm> poolie: i am just having fun ;-) ... also bugs with stack trace are easier to fix.
<poolie> 1- in most cases, the filename is valid but the filename encoding is not set properly
<poolie> eg on unix filenames are normally going to be utf-8 but in this case we seem to be detecting it as ascii
<poolie> so that could be about better detection or better defaults or perhaps (last resort) having a configuration for it
<poolie> 2- in some cases the user really may have a file that does not fit with the encoding of their tree
<poolie> and then i guess we should...
<poolie> i wonder
<poolie> i think ideally we would just tolerate it if it was an ignored file
<parthm> poolie: i saw another ticket by you saying we need a config option for bazaar.conf. maybe that should be fixed first?
<parthm> poolie: bug #538925
<ubot5> Launchpad bug 538925 in Bazaar "want configuration option for filesystem encoding (affected: 1, heat: 6)" [Medium,Confirmed] https://launchpad.net/bugs/538925
<poolie> i would do #1 then bug 538925 then #2
<ubot5> Launchpad bug 538925 in Bazaar "want configuration option for filesystem encoding (affected: 1, heat: 6)" [Medium,Confirmed] https://launchpad.net/bugs/538925
<parthm> poolie: makes sense. ... i will look into the detection logic and try to understand it better. thanks for your inputs.
<GungaDin> How come bzr tells me it's added file.OTHER during a merge?
<poolie> GungaDin, ah, because you didn't totally resolve a conflict
<poolie> this shouldn't be allowed; there's a bug vila's working on
<GungaDin> shouldn't it have added just file and not file.OTHER?
<GungaDin> after bzr resolve --all it's disappeared and file is just under 'unknown'
<vila> GungaDin: Urgh, 'bzr resolve --all' is a huge hammer that should almost never be used
<vila> If a file.OTHER is versioned after a merge, it's generally because there was a 'file' present in the working tree and in the other branch leading to a conflict on this path and you should resolve this conflict manually (by keeping one file, the other or a mix of the two)
<vila> GungaDin: 'bzr resolve --all' "solves" the conflicts by just deleting them, it's really the last resort when nothing else make sense
 * vila not really there yet, will be back in ~40mins
<vila> poolie: spurious failure at http://lbabune.ladeuil.net:24842/job/selftest-jaunty/90/testReport/junit/bzrlib.tests.test_progress/TestTextProgressView/test_render_progress_nested/
<vila> poolie: not reproducible, so probably a time dependent issue, just mentioning it as it's the first time I see it fail
<poolie> that is odd that it would be timing depednt
<poolie> however some of those tests are old and could bear to be refactored and thereby more isolated
<lifeless> hmm, didn't get nearly enough done today
<lifeless> tomorrow!
<mlh> there is always tomorrow
<vila> poolie: why not ? progress rendering is controlled with a time threshold no ?
<vila> hi all !
 * vila fully there now albeit may need to reboot soon :)
<poolie> vila, i guess it is
<poolie> obviously in rendering tests it should not be
<vila> poolie: not a big deal, the subsequent run worked anyway
<poolie> vila i'm going offline for a bit in the name of concentration
<vila> poolie: np, I'm going to reboot in the name of valuable upgrades :)
<fullermd> Well, I'm eating in the name of getting fatter.
<vila> :)
<vila> cu later all
<vila> bug #586341 is assigned to bazaar (Ubuntu), what is the trick get it assigned to bzr ? I can't set the importance right now
<ubot5> Bug 586341 on http://launchpad.net/bugs/586341 is private
<vila> argh
<vila> for once the private status is valid :-/
<vila> some confidential stuff exposed in the comments :-/
<spiv> vila: Click "Also affects project"?
<vila> spiv: that will create an additional line, I want to do that as a last resort only :-/ But thanks
<spiv> vila: why as a last resort?
<vila> I think the current affectation is bogus
<spiv> Well, it affects the version in Ubuntu...
<spiv> Anyway, the LP bug tracker doesn't currently allow directly reassigning from a distro package to a project.  Using the "also affects" options is as close as it gets.
<vila> Ha, ok
<vila> spiv: hehe, I can't copy/paste right now, but just try what you're proposing :)
<spiv> First, let me fix it to be assigned to bzr (Ubuntu) rather than bazaar (Ubuntu)...
<poolie> vila you can't delete 'affects' lines (aka tasks)
<poolie> which is a bug
<poolie> so just leave it there or mark it invalid
<vila> poolie: I can't use 'Also affects project' either, I run into a 'too many matches' when searching for 'bzr' as  a project
<spiv> vila: worked for me
<spiv> vila: although as noted I fixed it to point to the right package first
<spiv> Which means it automatically defaulted to the right project.
<vila> spiv: cool, thanks
<spiv> The "there's no upstream link for this package" and "this package has no versions published in Maverick" was a bit of clue that something was up :)
<poolie> sorry, that sucks
<poolie> there's a bug for that too
<vila> poolie: well, spiv is right, I suck too :)
<spiv> vila: heh, I didn't mean to say that :)
<vila> :)
<poolie> vila or you can use hydrazine bugclient and say 'bug 1234123' 'affects bzr' :-)
<ubot5> Error: Could not parse data returned by Launchpad: 1234123 (https://launchpad.net/bugs/1234123)
<vila> poolie: wow, cool, well, the demo effect didn't please ubot5 but I trust you :)
<vila> ubot5: don't worry, that wasn't a real bug
<ubot5> Error: I am only a bot, please don't think I'm intelligent :)
<vila> ubot5: that's why I explain
<ubot5> Error: I am only a bot, please don't think I'm intelligent :)
<poolie> poor thing
<lifeless> vila: you might like to file a bug saying you can't do that reassignment you wanted to
<poolie> there is one laready
<vila> jelmer: ping
<spiv> in 27
<vila> spiv: try 28 too
<spiv> :P
<nitian> i am getting "different rich-root support" and " is not compatible " when i am rying to merge my branch .
<nitian> how can i fix this?
<Jemsquash> Does anyone know if there is jira integration for bazaar?
<verterok> Jemsquash: Hi, there is a experimental plugin (for jira 3.x)
<verterok> Jemsquash: and I have a inprogress branch to make it work with the new jira SDK (and probably jira 4)
<Jemsquash> I think I just found it, is this the correct place to get it? https://code.launchpad.net/~verterok/bzr-eclipse/trunk
<servilio> hi! I am getting an bzrlib.errors.NoSuchRevision exception in bzr when doing a rebase; is this normal or something I should file a bug for?
<verterok> Jemsquash: http://launchpad.net/bzr-jira isn't a full integration, just a small experiment based on the svn integration
<Jemsquash> just paste the wrong one - doh
<verterok> Jemsquash: but it depends on the old jira sdk :(
<Jemsquash> ah we just upgraded to the latest Jira yesterday - sods law :(
<maxb> servilio: You should file a bug (against the bzr-rewrite project). If at all possible, provide links to the branches you were trying to rebase
<RDV_Linux> I am looking for some help. I cannot push changes to my branch. I was working in March of this year.  Here is a step by step from starting at a bzr update to make sure I was working from what was in LP. http://paste.ubuntu.com/444107/
<RDV_Linux> Any help would be appreciated. This is for Mythbuntu.
<servilio> maxb: what if the branches are not publicly accessible ATM?
<servilio> maxb: I mean, what would you recommend in that case?
<maxb> Did bzr write a .crash file and give you its path when it died?
<servilio> maxb: yes, it did :)
<maxb> Check it doesn't contain anything private (I doubt it will), and attach it to the bug. Describe as much as possible about the rebase operation you were doing
<servilio> maxb: ok, thanks!
<maxb> The NoSuchRevision presumably mentioned a specific revision-id - try to find out what that revision-id was
<servilio> maxb: I notice in the traceback that though the exception ocurred while using a command from the bzr-rewrite module, it happened in bzrlib/repofmt/groupcompress_repo.py, should I file the bug in bzr instead of bzr-rewrite?
<maxb> Were there bzr-rewrite frames in the traceback?
<servilio> maxb: there is indeed a missing revision, I had to revert a commit in the parent branch and add a couple of other things
<maxb> If so, it's more likely a rewrite issue
<servilio> maxb: yes, there is; also, thinking about it, it was while doing a rebase and fails, so it should be there
<servilio> maxb: again, thanks!
<lfaraone> lifeless: you said that bug 556968 was fixed in bzr-git, do you know which commit that was?
<ubot5> Launchpad bug 556968 in Bazaar Git Plugin "bzr branch crashes with "exceptions.TypeError: expected string or buffer" when cloning a git repository (needs upstream cherrypick/backport) (affected: 3, heat: 18)" [Critical,Confirmed] https://launchpad.net/bugs/556968
<lfaraone> jelmer: see above.
<jelmer> lfaraone: hi
<jelmer> lfaraone: it's fixed in the latest release
<jelmer> 0.5.1 IIRC
<lfaraone> jelmer: okay. I'm looking for what I should SRU to Lucid.
<jelmer> lfaraone: you'd have to SRU both dulwich and bzr-git
<jelmer> I think dulwich 0.5.0 and bzr-git 0.5.0 would be sufficient as well
<jelmer> alternatively you can cherry-pick the fix, which is trivial
<lfaraone> jelmer: ideally, we want to make the smallest change possible.
<jelmer> lfaraone: I have to make sure I get my groceries before the shops close, but if you're still here in 2 hours I can get you a patch for just this issue.
<lfaraone> jelmer: sure, thanks.
<servilio> what is the recommended way of changing the parent of a branch? is editing the branch.conf ok?
<beuno> servilio, bzr pull --remember?
<servilio> beuno: I was wondering if there would another way other than editing branch.conf or using --remember
<servilio> beuno: thanks!
<james_w> abentley: hi, was it lp-submit that has pipeline integration?
<abentley> james_w, lp-submit and lp-propose both have pipeline integration.
<james_w> I'm having trouble getting it to do what I want
<james_w> aren't they the same thing?
<abentley> james_w, lp-submit was the official name of the version in bzr-pipeline, and an alias for lp-propose when it moved to bzr proper.
<james_w> abentley: ok. Is there a certain way to add ~/.bazaar/locations.conf entries to get a nice mapping to LP branches?
<james_w> appendpath has .bzr/pipes/ showing up in the LP urls
<abentley> james_w, there's nothing that will make locations.conf give a nice public location for that kind of layout.
<james_w> abentley: you have your branches at the same level as the checkout?
<abentley> james_w, no, but I have my branches at the same level as each other, whether or not they're part of a pipeline.
<abentley> james_w, I have my checkouts in ~abentley/launchpad, and my branches in ~abentley/launchpad/branches
 * mtaylor bitches about bzr storing the expansion of shortcuts rather than the shortcut itself
<mtaylor> bitch bitch bitch
<lifeless> huh?
#bzr 2010-06-04
<spiv> There's a bug open about that, https://bugs.launchpad.net/bzr/+bug/569361 I think.
<ubot5> Launchpad bug 569361 in Bazaar "Remembering an URL different from the one the user entered is surprising (affected: 3, heat: 18)" [Wishlist,Confirmed]
<TresEquis> Anybody seen bzr-svn create bogus tags when pushing to SVN after merging from another bzr-svn branch?
<spiv> TresEquis: I haven't, sounds like a good bug to file.
<TresEquis> spiv: I would file it if I could figure out how to reproduce it
<TresEquis> happened twice to me yesterday, but I'm not sure why /how
<TresEquis> This checkin was a push from a local bzr branch to the bzr-svn checkout :parent
<TresEquis> https://mail.zope.org/pipermail/checkins/2010-June/047200.html
<TresEquis> followed immediately by creation of bogus tags:
<TresEquis> https://mail.zope.org/pipermail/checkins/2010-June/047201.html
<TresEquis> https://mail.zope.org/pipermail/checkins/2010-June/047202.html
<TresEquis> etc
<spiv> Hmm. :(
<spiv> Does your local bzr branch have tags with those names in the 'bzr tags' output?
<TresEquis> none of those tags ever existed in that project, nor any such releases
<TresEquis> spiv: hmm, I think I wiped out the local checkout ;(
<TresEquis> yup ;(
<TresEquis> I have a half-baked theory that bzr might have been confused by an attempt to merge an unrelated branch
<TresEquis> which didn't actually make any changes in my working tree
<spiv> Oh, yes, that does sound plausible off the top of my head.
<TresEquis> but maybe it messed up the tags bookkeeping?
 * spiv takes a peek at the code
 * TresEquis crosses his fingers
<spiv> Hmm.
<spiv> Yes, that does seem plausible, if you managed to get bzr to go as far as fetching revisions from the other branch into this one.
<TresEquis> it seemed to try, then give up claiming "no common revisions" or something
<spiv> Hmm, that doesn't sound right then.
<spiv> I'm pretty sure tags are only updated after fetching the actual revision objects, and that can only happen after determining the revisions to fetch, which is when that error would happen.
<spiv> It's possible there's a code path I'm not noticing, of course.
<TresEquis> if it matters, the two trees both point back to the same SVN repository
<TresEquis> just to different project areas in it
<spiv> I wouldn't expect that to matter, directly.  Well, that's presumably what allows bzr to know that it can even create those tags (because the revisions from the other repo are there), but doesn't address the mystery of why bzr/bzr-svn is mixing tags from an unrelated project.
<TresEquis> all the branches (bzr-svn checkout, local branc) were inside a shared repo, if that matters
<TresEquis> anyway, I will post a bug with as much information as I have
<TresEquis> even though reproducing it seems wicked
<spiv> That would be good, I suspect jelmer may be able to guess the bug :)
<spiv> I don't suppose anyone knows much about configuring apache to use active directory?  If you do, https://answers.launchpad.net/bzr/+question/113185 could use your help.
<TresEquis> Posted here: https://bugs.launchpad.net/bzr-svn/+bug/589514
<ubot5> Launchpad bug 589514 in Bazaar Subversion Plugin "Bogus tags created after failed merge attempt (affected: 1, heat: 6)" [Undecided,New]
<TresEquis> Thanks for the sounding board, spiv
<poolie> spiv, thanks for the import test and patch
<lifeless> spiv: poolie: you guys might benefit by lurking in #ubuntu-devel, amongst other channels. Just had a query about udd reliability there - I don't think most folk having bzr related things go wrong will think to come here in the first instance.
<spiv> Hmm, I'm usually in there.  I need to poke irssi harder to make that stick I guess.
<poolie> yeah likewise
<poolie> thanks for the reminder and for catching it
<spiv> It's very wet today.
<poolie> mm it is
<lifeless> uhuh
<parthm> poolie, lifeless: regarding ignore handling. while i prefer 'fail early' i am ok with warning for 'ignore', 'ignored', 'ls' and 'st' as these command don't change anything.
<parthm> doing a warning for 'add' seems scary to me as the user might end up adding unwanted stuff to the repo.
<parthm> he could revert but then he may not notice and just add more revisions.
<parthm> we have seen tickets like thing regarding whoami guessing and .moved files being added.
<parthm> i was hoping to catch jam but i guess its late in his timezone.
<poolie> i think if you explicitly try to add an invalid file that should certainly fail
<lifeless> poolie: spiv: check my facebook feed - not wet today :)
<mwhudson> it's been very nice here today too
<lifeless> poolie: not invalid file; invalid .bzrignore making the regex compilation fail
<mwhudson> you have better mountains though
<lifeless> you're in a mountain!
<poolie> i think one interesting case is having a file with a bizarre name generated by a build process that you can't change
<poolie> ah sorry, different bug
<parthm> poolie: i am thinking if user does 'bzr add foo', it should work irrespective of bad ignore pattern. however a 'bzr add' should fail if there is a bad pattern in ignore files.
<poolie> in that case i think it's within the person's power to fix it before doing anything else?
<lifeless> poolie: certainly bad files in the tree shouldn't stop bzr being usable as long as they aren't versioned
<lifeless> poolie: well thats what I've been arguing
<poolie> parthm, right with 'add foo' (foo not a directory) we shouldn't need to even think about ignores
<poolie> well that's nice we agree then :)
<lifeless> jam and vila have expressed an interest in just warning and not stopping
<lifeless> poolie: so you and I agree, jam and vila appear to agree with each other ;P
<poolie> and they're both asleep...
<parthm> poolie: if a user is hoping to ignore 'x.zz' and it gets added. he may not notice and end up adding a few more revisions.
<poolie> ... so ... _-)
<lifeless> there is discussion in the bug
<lifeless> personally, I've said my bit - and any improvement over a backtrace is an improvement
<lifeless> so, I'm -> loom stuff for a bit more, then EOD
<poolie> incremental improvements and working code generally get my approval
<lifeless> parthm: what time is it for you, now ?
<poolie> ok
<poolie> i'm going to concentrate on reviews for a bit
<parthm> its 10:30 am ... i am planning to start working on a new patch for the ignore pattern issue.
<lifeless> you should look at my scenery porn first :)
<lifeless> poolie: ^
 * poolie coughs
<poolie> that is very pretty though
<lifeless> hmm, facebook seem to discard lots of resolution.
<poolie> interesting choice of foreground
<lifeless> it *was* a 4K by 3K
<poolie> oh from what camera?
<lifeless> I have some others without anything but water in foreground
<lifeless> coolpix s8000
<lifeless> has a 10x optical zoom, which is pretty nice
<lifeless> nothing compared to your beasty
<lifeless> but I wanted something I can hold for extended periods
<lifeless> the other ones though aren't as dramatic on the mountains
<lifeless> and I thought the prosaic foreground item was fun
<mgz> morning all.
<poolie> hi mgz
<poolie> spiv, btw, you're pilot next week
<poolie> i'm going to empty it a bit today if possible
<spiv> Thanks :)
<poolie> mgz, thanks for your review of the walkdirs patch
<mgz> happened to be something I'd just been looking at from the other end in testtools, and before that with vila in bazaar.tests._rmtree_temp_dir
<mgz> if we've got a function that wants to guarentee unicode (or utf-8) outputs, and has a posix filesystem as its input, something has to give
<mgz> throwing a clear error like in the merge proposal is an improvement
<poolie> yes
<mgz> ah, that's what I was doing, commenting on one of you bugs about this
 * mgz finishes typing that
<poolie> i wonder if i have some still unpushed developer docs about handling unicode
<poolie> we could try to explain the general approach more
<mgz> did I write anything for my nonc bits...
<mgz> hm, just:
<mgz> +No API should take '``str`` or ``unicode``' expecting to use ``isinstance`` to
<mgz> +tell them apart. Text that may need to include non-ascii characters on some
<mgz> +platforms, such as filenames or error messages, should be decoded to unicode
<mgz> +at the earliest opportunity. Much of this will also need looking at carefully
<mgz> +when considering a py3k port.
<mgz> which isn't all that useful.
<poolie> mgz, "use instance to tell them apart ... without a very good excuse" :-)
<poolie> such as coping with a platform api that can return either
<mgz> right.
<mgz> we have to cope with such problems, don't want to propogate them
<poolie> i've been meaning to write a tool that auto-fixes filenames
<poolie> by guessing what encoding they're in and changing them to utf-8
<poolie> there are libraries to do the guessing
<poolie> maybe such a tool exists
<mgz> also foreign branches, I filed a bug against bzr-git the other day while trying to track down a different issue
<mgz> a sensible guess is the right thing sometimes.
<poolie> lifeless, so what did we finally agree about sphinx in pqm? we'll try to backport it?
<mgz> bug 587074 it twath.
<ubot5> Launchpad bug 587074 in Bazaar Git Plugin "Branching tree with non-ascii filenames fails (affected: 1, heat: 6)" [Medium,Triaged] https://launchpad.net/bugs/587074
<vila> hi all
<parthm> hi vila
<poolie> hi there vila
<vila> \o/
<poolie> are your machines feeling better?
<vila> yes, and an additional disk for backups is on its way
<vila> Of course I had a kernel panic on OSX yesterday just to keep me on my toes, but I ignored it because enough is enough :)
<poolie> good idea :)
<poolie> i'm still waiting for my rebuilt machine
<vila> poolie: errr, when did it broke ?
<poolie> wow, two weeks ago now
<poolie> but it took a while to conclude what was wrong
<vila> wow, I was lucky enough to get mine so quickly then
<vila> yeah, the diagnosis for mine went a bit fast because it was locking quite fast
<vila> but in retrospect, I'm now convinced that the failure started manifesting itself long ago, but only once in a while (like once a month)
<vila> I'm toying with the idea of using a remote log facility for cases like that (fullermd mentioned raid but I can't do that on the imac)
<vila> But that's low priority, backups are better :)
<poolie> so vila if we started testing python2.4 only in babune, do you think that would be fairly safe?
<vila> Sure, let me check hardy's default version
<vila> Unfortunately lucid doesn't support 2.4 anymore...
<mgz> one concern I've got about that is Vincent's too good at just fixing things. when pqm fails, the patch submitter sees the fallout so there's some community learning about what isn't 2.4 safe.
<poolie> that's true
<vila> hmm, 2.5 is the default
<poolie> yes
<vila> hehe don't make me blush,
<poolie> however we could make him put coding-style additions up when he fixes something
<vila> The thing is it's still faster to fix things than finding the time to configure email sending on errors
<poolie> i think fixing them is fine
<poolie> but it should be visible somehow
<vila> so hardy's default is 2.5, I can either add a specific run for 2.4 or just force 2.4 on hardy (but that feels wrong since it's not the default config used by hardy's users and that's wht I want to test primarily)
<vila> I try to at least file bugs with a babune tags when I fix such things
<vila> s/tags/tag/
<poolie> if you put up a mp adding to doc/developers/coding-style.txt and say why you need the addition
<poolie> that will help
<poolie> someone did that
<poolie> recently
<poolie> i'd care more about getting 2.4 on hardy than i would about retesting 2.5 on both hardy and jaunty
<vila> ha no, the best solution for python2.4 is to add a centos/redhat slave
<poolie> what's 'selftest-matrix' again?
<poolie> oh that would be better
<poolie> i'm not paying for a RHEL licence though :)
<vila> the old way to run on all slaves which was confusing as all tests were consolidated there
<vila> I will delete it once I get a blue babune including windows
<vila> It's unfortunate that the default view is the 'all' one which by definition includes all jobs whether they are relevant or not (debug-* for example have a specific focus by definition)
<vila> And by the way, there are tooltips on the colored icons
<vila> hmm, no example there, but grey can mean either disabled or aborted
<vila> selftest-matrix is disabled because it's obsolete
<mgz> and here I was thinking you were testing bzr on human batteries
<vila> template-selftest is disabled because it's not intended to be run but is used by selftest-<slave> to keep some definitions unique
<vila> mgz: what did I tell you about rule #1 ?
<mgz> there's no such thing as babune?
<mgz> or was that rule #2...
<vila> thre is no such thing as human batteries powered selftest :)
<lifeless> poolie: I don't know what the consensus was
<poolie> if you're talking about sphinx then i think it was that we'd try the backport
<spiv> That was my impression too.  I don't recall anyone objecting to that suggestion, at least.
<poolie> lifeless, i don't want to be snarky but pqm failures now seem unreadable
<poolie> since they lose the crlf distinction
<poolie> i guess i should write an alternate encoding
<mgz> subunit thing? what kind of unreadable?
<mgz> I guess I need to try out my new powers and see what sort of mail sends soonish.
<mgz> anyway, if it's because of \r in test output I might squash that at the testtools level
<mgz> because it's a good way to break terminal output too.
<mgz> >>> raise ValueError("\rgotcha!")
<mgz> Traceback (most recent call last):
<mgz>   File "<stdin>", line 1, in ?
<mgz> gotcha!ror:
<lifeless> poolie: the fix is coded, see the lp rt queue for the request to deploy it
<lifeless> poolie: (fix here meaning to send as an attachment)
<lifeless> mgz: there is a bug open on subunit to use a more robust framing
<mgz> right, but my point was random control characters are bad anyway
<poolie> lifeless, that's nice
<poolie> this is rt39555?
<poolie> well, obviously
<lifeless> poolie: something like that, I can look it up if needed, but it should be pretty obvious
<lifeless> poolie: aaron wrote a sketch for me @ UDS, I polished and prepped, needs deployment
<poolie> ok, i bumped it up for attention
<lifeless> a better protocol would be nice
<lifeless> so would a summary in the body of the mail; but I figured getting the terrible bahviour sorted was the high priority
<bignose> The âbzr-buildpackageâ tool is capable of doing the equivalent of an export, but taking the current uncommitted files from the working tree.
<bignose> is that a capability of the export command?
<bignose> I want to be able to export the current what-would-be-committed working tree state.
<poolie> there was a bug for that
<poolie> i think someone fixed it?
<poolie> but maybe not
<bignose> $ bzr version | head -n 1
<bignose> Bazaar (bzr) 2.1.1
<bignose> $ bzr export --help | grep uncommitted
<bignose> $
<poolie> i might sign off soon
<lifeless> mgz: so
<lifeless> mgz: matchers; did you look at the exception matcher in testrepository ?
<vila> urgh argh eeerk, ssl fingerprint do not match wth !
<vila> fetchmail: despite my thanks for your wonderful support all those years: I hate you!
<lifeless> ayan: hi
<lifeless> ayan: what timezone are you in ?
<lifeless> well gnight y'all
<mgz> darn, came back too late
<mgz> will have to catch lifeless in another cycle.
<jelmer> mgz: 'morning Martin
<mgz> morning jelmer.
<parthm> what does the '?' indicate in 'bzr status'? i am getting a status of '?  .bzrignore' for a test output.
<jelmer> parthm: unknown file (not versioned, not ignored)
<parthm> jelmer: thanks :)
<bignose> parthm: âbzr help status-flagsâ
<parthm> bignore: neat. i didn't know about that.
<parthm> sorry. i meant bignose :P
<bignose> you may also want to know about nick completion in your IRC client :-)
<parthm> bignose: yes. i think i should start using it :)
<parthm> yup. it works :)
<bignose> heh
<bignose> parthm: for more interesting topics, âbzr help topicsâ
<parthm> bignose: yes. i have used that one. somehow i missed status-flags.
<parthm> thanks.
<peitschie> hi everyone
<peitschie> does anyone know if there is an official policy for how bzr deals with ghost revisions?
<jelmer> hi peitschie
<jelmer> peitschie: Can you expand? Ghost revisions are just there (or rather, they aren't ;-)
<peitschie> hi jelmer :)
<peitschie> i'm chasing up 3 crashes that happen in qbzr tools... all related to ghost revs
<peitschie> most of the time bzrlib throws errors if the revision doesnt exist
<peitschie> in some cases i think this behaviour is incorrect (e.g., in repository.py def _get_revisions(self, revision_ids) for example)
<peitschie> but just wondering if there was any disctussion about better ways of dealing with these?
<peitschie> in some cases... qbzr can't possibly work around the iszsue, because it is calling a low-level bzrlib call with a bunch of revisions, which may or may not be ghosts
<jelmer> peitschie: in general the policy is to raise exceptions when you ask for a single revision that doesn't exist
<jelmer> peitschie: for calls that return multiple revisions such as get_revisions() it should probably either yield None or ignore the revision altogether if it's not present
<jelmer> peitschie: you shouldn't be calling _get_revisions directly though
<peitschie> jelmer: sorry... ur right... it is calling get_revisions :)
<peitschie> jelmer: would it be bad in your opinion to return a partially filled Revision object with a special "missing=True' property?
<jelmer> peitschie: In that case I'd opt for a GhostRevision object or something like that
<peitschie> jelmer: ah..  That's a good idea!  I'll introduce one of those
<amanica> has any body seen the following? (google doesn't know anything about it):  ErrorFromSmartServer: Error received from smart server: ('error', 'Internal check failed: Cannot add revision(s) to repository: missing chk node(s) for id_to_entry maps')
<amanica> I did a reconcile on the server but that didn't help :(
<peitschie> amanica: are you using bzr-svn?
<amanica> not in this case
<amanica> do you think the plugin interferes?
<peitschie> amanica: not unless you're mirroring from an svn repo :).  how many revs in your repo?
<amanica> in my branch 200, in my repo much more
<amanica> I'm gonna try to upgrade the bzr on the server from 2.0.1 to 2.1.2 maybe that helps..
<mgz> hey marius!
<mgz> how are you?
<amanica> hey buddy mgz, I'm good thanks and you?
<mgz> not too bad, sun is shining and lunch awaits.
<amanica> I'm trying to get some work done, but things just keeps getting in my way :(
<amanica> mgz: btw. congrats with being granted pqm access
<bignose> Bazaar offers me a command to break a lock, but using the command doesn't work.
<bignose> âIf you're sure that it's not being modified, use bzr break-lock chroot-13269072:///bzr/collab-maint/comixcursors/comixcursors.debian/.bzr/branch/lock
<bignose> but:
<bignose> $ bzr break-lock chroot-13269072:///bzr/collab-maint/comixcursors/comixcursors.debian/.bzr/branch/lock
<bignose> bzr: ERROR: Unsupported protocol for url "chroot-13269072:///bzr/collab-maint/comixcursors/comixcursors.debian/.bzr/branch/lock"
<bignose> so presumably Bazaar should either gain the ability to do what it's offering to do, or not offer it.
<jelmer> bignose: please file a bug
<mgz> amanica: I have yet to try it out though, need to get one of your merge requests ready to land so I can break it :)
<mgz> bignose: this is on launchpad, right?
<bignose> I don't (yet) have a Launchpad account, I'd appreciate someone filing it on my behalf.
<bignose> mgz: no, on Alioth
<amanica> mgz: cool, will do :)
<mgz> oh. you can still un-root the path to something you can access right?
<mgz> I think I did that when I had a similar issue on launchpad
<mgz> ...or maybe I deleted the branch and pushed again, don't recall.
<bignose> I can work around the problem. but presumably the lock will remain until broken.
<bignose> the bug is rather that the error message suggests a command that will never work.
<mgz> what I mean is, can you give break-lock that url in a form it understands?
<mgz> I'm not disputing that the message is a bug.
<jelmer> bignose: try using ' bzr break-lock' on the URL you originally used to access the branch
<bignose> mgz: hmm. you're suggesting that the problem is the error message is displaying the wrong URL, and a correct URL could be used?
<mgz> right.
<bignose> jelmer: does it need to go all the way to the ââ¦/.bzr/branch/lockâ file?
<jelmer> bignose: no, that's not necessary (both should work)
<bignose> or could I just refer to â:boundâ?
<jelmer> perhaps, I'm not sure
<jelmer> worth a try :-)
<bignose> (the reason I'm asking, rather than trying it, is that I've already broken the lock by SSH onto the remote machine. so I can't test these questions.)
<jelmer> I wasn't even aware the smart server over plain tcp worked on alioth these days..
<bignose> âplain TCPâ? it's over SSH, I'm not sure if that's different from what you're saying.
<jelmer> it's different, I meant bzr://
<jelmer> as opposed to bzr+ssh://
<bignose> okay. I've never tried the plain TCP protocol on Alioth.
<bignose> nope, Alioth doesn't provide Bazaar plain TCP protocol.
<shrini1> team
<shrini1>  is there any way to rescue the disconnected "bzr branch" command?
<shrini1> i have disconnecting net onnection
<maxb> I don't think it's possible to resume bzr branch
<beuno> shrini1, use a shared repositoru
<beuno> repository even
<beuno> it will save the revisions to it, and will continue branching just from the ones it doesn't have
<csgeek> how would I checkout out a particular revision of a bzr repo? (I've already pulled the branch and should have all the history )
<lifeless> csgeek: bzr revert -r xxx
<lifeless> or if you want to make a new branch at an old revision, bzr branch -r xxx . ../b2
<csgeek> thanks
<csgeek> nah.. just wanted to look at a particular revision.  Just need to confirm something.  Thank you
#bzr 2010-06-05
<dan|el> Any idea what's up with this error?
<dan|el> Conflict: can't delete lib/js because it is not empty.  Not deleting.
<dan|el> Conflict because lib/js is not versioned, but has versioned children.  Versioned directory.
<dan|el> why would this even happen?
<dan|el> found things here: http://doc.bazaar.canonical.com/bzr.0.92/en/user-guide/conflicts.html
<dan|el> fixed
<meoblast001> hi
<meoblast001> does Bazaar end commit messages with a new line?
<spiv> meoblast001: not necessarily, I think.
<meoblast001> hm, ok
<vila> mgz: If you're around, care to give lp:~vila/bzr/for-babune a host on your windows host ?
<vila> mgz: It implements some fixes for the http *thread* leaks (socket leaks will come later) but I'd like some feedback on memory consumption and overall elapsed time (I've got weird results here like it has been running for the last 5 hours while consuming very little CPU)
<mgz> branched, I'll hook it up for a full run now.
<vila> mgz: oh cool you're there,
<vila> so about memory, performance monitor tells me ~150M, is this where you found your 1G figure ?
<mgz> hm, exception
<mgz> !pastebin
<ubot5> For posting multi-line texts into the channel, please use http://paste.ubuntu.com | To post !screenshots use http://tinyurl.com/imagebin | !pastebinit to paste directly from command line | Make sure you give us the URL for your paste - see also the channel topic.
<mgz> http://paste.ubuntu.com/445174/
<mgz> presume that's a try/except/finally
<mgz> which is a 2.4 no-no :)
<mgz> ^no, ~150M is about what the right number should be, without horrible leaks messing things up
<vila> hmm, thanks fixed (that's what I get from running llucid where py24 is not packaged anymore :-/)
<mgz> full testrun working set size prior to r4920 was 177MB, and >500MB after
<vila> yeah, but where do I find that ws sizr you're talking about ? Performance monitor ?
<mgz> I added a thingy to my script
<vila> err, task manager ?
<vila> Can it merged into core ?
<vila> Can it be merged into core ?
<mgz> http://float.endofinternet.org/bazaar/bzrcst/bzrcst/perf.py
<mgz> probably, the windows version has an analogue in bzrlib.win32utils anyway
<mgz> vila: have you pushed the try/except/finally fix to lp yet? can do it independantly here, but prefer to run off your rev
<vila> I'm preparing a version with more fixes included (far less socket leaks)
<mgz> yell when pushed and I'll pull and start a run here
<vila> yup, I'd like to let mine finish even if it takes a day or some (or not :)
<vila> mgz: pushed
<vila> mgz: in case it matters, it's based on trunk from a few days/weeks, I don't remember exactly when I last updated my loom
<mgz> nope, shouldn't matter
<vila> thought so but nobody told me nothin' so I prefer to check :)
<mgz> there were some revs around the gio merge that had issues, but runner is resilient to import/syntax issues in tests
<vila> hmm, I missed the review window there...
<vila> pff, 6 hours for 2000 tests something is very wrong there
<mgz> but the tests are still progressing? it's not just hung somewhere?
<vila> yeah was progressing (I just killed it)
<mgz> because... er... it seems to have hung here already
<vila> give it some time
<mgz> my hang protection will kick in... just has
<vila> I smell some network related timeout from.... some unknown place
<vila> try disabling that for once
<mgz> ...I really need to get the name of the started test out before running it...
<vila> -v
<mgz> the test *after* bb.test_branch.TestBranchStacked.test_branch_stacked_from_rich_root_non_stackable at any rate
<mgz> lets see if it happens again
<mgz> yup.
<mgz> bb.test_branch.TestBranchStacked.test_branch_stacked_from_smart_server
<mgz> used to leak, now hangs.
<vila> pass here
<vila> but I've seen weird failures involving the smaer server on windows only
<mgz> I'll try running it just from the console and... urk, bb.* so no pdb
<vila> shudder
<vila> the CPU graph is flat again...
<mgz> yup, no ctrl+break
 * mgz goes to kill process manualy
<mgz> I'll try a full run minus bb.
<vila> or if you have data available, just compare -s bt.test_http
<vila> and -s bt.per_transport
<vila> I think that cover most of the leaks
<vila> hmm, anyway, looks like my fixes make a lot of hangs came up,
<vila> the ones I've fixed... were all in the server part and have been there for a long time, I don't yet have a good explanation about why my other fixes are shaking them up though, it seem to be an overall effect
<vila> .. which in turn means that I need to fix a lot of things together if I don't want to disrupt the whole selftest :-(
<mgz> okay, that gave me a whole load of errors
<mgz> somehow broke my runner framework (are you now deleting things in cwd somehow?) but get failures run with -x blackbox from console
<vila> I delete nothing I can think of
<mgz> a bunch from cleanups like:
<mgz>   File "C:\bzr\bzr\for-babune\bzrlib\osutils.py", line 2041, in connect_socket
<mgz>     for res in socket.getaddrinfo(host, port):
<mgz> NameError: global name 'host' is not defined
<vila> but I've got some basic error, yeah that noe
<vila> one
<mgz> also some from threads like:
<mgz> error: (10058, "Can't send after socket shutdown")
<vila> yeah, smart server, coming from a .recv() call, which is ... ironic :)
<vila> I've yet to reproduce them somewhere else, but thanks for feedback, it means it still need to be addressed (I wan't totally sure it was reproducible)
<mgz> ah, maybe it's trying to clean up BZR_HOME now
 * mgz tries moving that in the runner
<vila> one more fix pushed, now it's almost all http/1.1 tests that fail for -s bt.test_http :-/
<vila> and stil an almost flat CPU graph
<mgz> ha, okay, worked out what the problem was here
<mgz> one of the tests was cding somewhere and not cding back
<mgz> fixed my isolation on that.
<vila> weird, the base test framework should do that for you
<mgz> yeah, "should" being the important word there :)
<vila> hmm, interesting, I've got thread hung detection triggered here and 10058 cant blah blah too with no smart server involved
<vila> mgz: so, sorry for the trouble, I thought things were more stable than that :-/
<mgz> http://float.endofinternet.org/xmlbin/for-babune_r5277_A
<mgz> got some interesting results before hang there
<mgz> not sure why `raise tests.TestSkipped('Not a local URL')` is turning up as an error... probably an exception in another thread or cleanup I'm not recording currently?
<vila> mgz: almost all tests seem to be skipped ?
<mgz> need to wrestle with testtools some more.
<mgz> that was me forcing a blackbox skip to avoid the early hang
<vila> hmm, so I should drill down somewhere ?
<mgz> click one of the yellow boxes in the last row
<mgz> those are thread exceptions + leaks
<vila> ha ok, yeah, I got a can't send
<mgz> likewise some of the sky-blue (skip + leak)
<vila> so, I don't have a fix yet for the smart server threads leaks, so rule them out
<vila> the 10058 case... need to be fixed though
<vila> ha, cool, I've got -s bt.test_test_server failing 1 errors 2 out of 8 tests :)
<vila> including a 10058 and a 10054
<mgz> I'll try and get the tracebacks-from-cleanup in there as well, as that's a worry
<vila> mgz: try -s bt.test_test_server and look at the tests themselves, some exceptions in the cleanup phase need to be caught but have a simple explanation,
<vila> I'm closing sockets from the main thread and the exceptions occur... either there or elsewhere :)
<mgz> this hangs for me: test_test_server.TestTCPServerInAThread.test_start_stop(TestingTCPServer)
<vila> mgz: interesting... and a bit worrying too :-/ It looks like too many hangs occur that I can't address...
<vila> hmm, but start/stop shouldn't be one of them :-/
<vila> those are whitebox tests though, can you see which line is hanging under pdb ?
<vila> oh, and this one ERROR or FAIL here
<mgz> ha, I think I forgot to kill that last run, and it seems to have got past it:
<mgz> http://paste.ubuntu.com/445198/
<mgz> ERROR   119984ms
<mgz> very interesting.
<vila> 2mins
<mgz> that's just over my hang protection limit
<mgz> and probably a socket timeout of some kind
<mgz> could explain your six hours too.
<vila> yup
<mgz> hm... bumping the time wasn't enough to get past my first blackbox hang
<vila> hmm, so a bit of explanation of the traceback in your last pastebin, that's an exception crossing the thread boundary (the t.join() line is the boundary)
<vila> i.e. an exception occurred in a thread and is re-raised in the main thread
<vila> I was post-poning a better mechanism to declare which exceptions should be caught when but it looks I need it *now*...
<vila> mgz: I was referring to the first traceback in your pastebin (ending with 10058)
<vila> mgz: the second one is similar but for the server thread
<vila> whereas the first was for a connection thread in a threading server
<mgz> http://float.endofinternet.org/xmlbin/for-babune_r5278_bt.test_test_server#bt.test_test_server.TestTCPServerInAThread.test_start_stop(TestingTCPServer)
<mgz> that one, right?
<mgz> (bumping the number was enough to get past that hang reliably, it seems)
<vila> the last you pasted is from the server thread yes, always search for a .join()
<vila> hmm, worth renaming that 't' for the connection threads
<vila> mgz: and since there are multiple threads involved but only one exception can be raised, as soon as one is, all bets are off since the overall server shutdown has been interrupted...
<vila> the idea is that server bugs are not supposed to occur and should be fixed before anything else... which is what we are encountering here I suspect
<vila> and more precisely here, I suspect that windows is raising exceptions that are a bit different and there are holes in my exceptions filters :)
<mgz> the socket errors are all a bit different, certainly :)
<vila> ...which in turn expose the flaw in my design: the "acceptable" exceptions should be easier to specify
<mgz> generally, when ever you catch a en E* you also need to catch a WSAE*
<mgz> and sometimes another one as well
<vila> the 1005* are WSAE* ?
<mgz> yup.
<vila> hmm, that's very good to hear
<vila> The problems with the actual exception catching are: 1) too many different places in the server code, 2) a mix between exception occurring in the normal usage and in the shutdown phase 3) some windows equivalence missing
<vila> back to the drawing board it is...
<meoblast001> hi
<meoblast001> i'm getting this error with one of my scripts
<meoblast001> http://pastebin.com/3df3sReW
<meoblast001> the script was tested working locally on this system, and previously worked on my server
<meoblast001> i only made on modification (switched a split ('\n') with a splitlines()
<mgz> serious import resolution screw up
<mgz>   File "/usr/lib/python2.5/site-packages/bzrlib/__init__.py", line 19, in <module>
<mgz>     from bzrlib import branch
<mgz> that can't happen, did you add it?
<meoblast001> ugh, wtf
<meoblast001> i remove the script and the old one is running
<meoblast001> where else could Bazaar hooks be located?
<meoblast001> mgz: this is proving to be much more painful than anticipated
<meoblast001> it was supposed to be as simple as move files to bzrlib like always, run, everything is happy
<meoblast001> i tested it locally, everything works
<mgz> well it looks like you've screwed up your bzr installation somehow
<meoblast001> i THOUGHT i overwrote the old files
<meoblast001> ok, so i have to uninstall and reinstall Bazaar :/
<mgz> removing it all and starting from scratch might be easiest
<meoblast001> sudo apt-get purge?
<mgz> try it.
<meoblast001> mgz: ah thanks
<meoblast001> it removed everything but my files
<meoblast001> so now i can find where the old ones were
<lifeless> mgz: hai
<mgz> wotcha lifeless.
<meoblast001> hm, didn't realize i have custom repositories for bazaar on my server
<meoblast001> considering i'm still running hardy >.>
<meoblast001> thanks mgz
<meoblast001> seems i did overwrite Bazaar critical files
<mgz> paella awaits, back to hack in a little bit.
<meoblast001> another Bazaar question... i'm using post_change_branch_tip in my script that announces updates in our source respositories
<meoblast001> if the server has to pull somewhere though, it also will announce there
<meoblast001> is it possible to make it only call a script if the server has been pushed to?
<lifeless> in your script, check the url or config of the branch which changed
<meoblast001> lifeless: ok, thanks, good idea
<meoblast001> lifeless: i'm having some trouble finding a listing of branch members, you by any chance know where that would be otoh?
<meoblast001> wait, think i found it
<meoblast001> hm, maybe not, hard to tell
<meoblast001> lifeless: is it possible for me to store a file in the .bzr directory of a project and then check it later?
<meoblast001> i could create a function bzr <something> where it will then create a file that is checked
<meoblast001> when i try to check the location i get bzr: ERROR: exceptions.TypeError: cannot concatenate 'str' and 'NoneType' objects
<meoblast001> doing a print "COMMITTING TO: " + result.branch.get_parent()
<lifeless> well parent can be None
<lifeless> if you want to store a config value use branch.get_config()
<meoblast001> well, that seems like the only thing in the docs remotely close to a location
<lifeless> oh, the branch itself is branch.base
<lifeless> though it will be in a virtual chroot, so not the same path you'd see on disk
<meoblast001> lifeless: yeah, i get file:///home/braden/test/
<meoblast001> could i just pop the file:// off of it and go with that?
<exarkun> Hey, why is the snow leopard bzr installer link a 404?
<lifeless> I don't know, why is the snow leopard bzr installer link a 404?
<exarkun> http://wiki.bazaar.canonical.com/MacOSXDownloads -> http://launchpad.net/bzr/2.1/2.1.1/+download/Bazaar-2.1.1-2.dmg -> 404
<lifeless> looks like duplicated info -> badness
<exarkun> Okay, I can get behind that, although I don't really know what you mean.
<exarkun> Anyway where can I download bzr 2.1.1 for OS X?
<lifeless> have a look at http://launchpad.net/bzr/2.1/2.1.1
<exarkun> Okay thanks
<lifeless> though 2.1.2 is out now
<exarkun> Blech.
<exarkun> http://launchpad.net/bzr/2.1/2.1.1/+download/Bazaar-2.1.1-OSX-10.6-3.dmg can't be downloaded with curl.
<lifeless> anyway, basically I think the wiki page is stale
<exarkun> Okay.  Unfortunately that didn't help.  Is there some way to have libtdb on OS X?
<lifeless> hmm
<lifeless> you want bzr-svn on macosX, right ?
<exarkun> yea
<lifeless> is http://edge.launchpad.net/bzr/2.1/2.1.2/+download/Bazaar-2.1.2-OSX-10.6-1.dmg what you grabbed ?
<exarkun> I got 2.1.1 I think
<exarkun> I can try 2.1.2 though
<exarkun> I tried 2.1.2, still no libtdb
<lifeless> ok
<lifeless> https://edge.launchpad.net/bzr-mac-installers
<lifeless> is the mac installer project
<lifeless> is bzr-svn bundled in the installer ?
<lifeless> or are you installing it separately ?
<lifeless> I'm about to go out
<lifeless> but I suggest the following:
<lifeless>  - if bzr-svn isn't bundled in the installer, you're going to need to roll your own dependency chain
<lifeless>  - but I think it is bundled in the installer, so start by filing a bug saying 'its bundled but not working' and work up from there.
<lifeless>  - if you're time-sensitive about getting this fixed, or willing to fix it yourself, the home page for bzr-mac-installers seems to describe how to get going with the code to do installs
<lifeless> and you could probably figure out whats going on fairly straight forwardly, if you know mac stuff.
<exarkun> Okay, I just built libtdb myself and apparently it works although it was a horrible experience.  But now I'll go file a bug against something.
<lifeless> please do!
<lifeless> https://edge.launchpad.net/bzr-mac-installers is the thing
<PsyberS> has anyone created a script(s) that will do a bzr log on every file, gather a list of all committers, and then update the file itself to list them (probably replacing some fixed/annotated block in the comments of the file)?
<PsyberS> basically so every source file can have a 'copyright 2010 author1, author2, ...' etc that is automatically updated based on who has committed that file
#bzr 2010-06-06
<mgz> bah.
<mgz> what's the easiest way of getting tree.get_file_text to actually give me text, as in no \r in lines...
<mgz> horrible feeling the answer is "content filters"
<vila> 526AAF67
<vila> pff wrong window :)
<mgz> just have to skip the optimisation if os.sep != "\n" for now,
<mgz> and down to one failure...
<vila> PsyberS: there is https://edge.launchpad.net/bzr-update-copyright that sounds like a good starting point
<vila> As if I was bored, I managed to break my boot partion map while formatting a new HD for backups...
<vila> thanks to ubuntu-rescue-remix I managed to restore it, fix the FS, reinstall grub and viola, works again, interesting times indeed
<vila> I wish you all less emotions tonight :)
<mgz> yeay for computers.
<vila> but enough for me tonight :)
<mgz> submitted, Parth is going to hate reviewing that.
<mgz> actually, 718 lines (+229/-297) 3 files modified isn't as bad as I thought it'd be
<PsyberS> vila: thanks for the pointer, i think that updates the year so thats a start at least
<PsyberS> hah, the author lives like 1.5 hrs away from me
<Visualante> how do i restore a file?
<Visualante> searching restore on launchpad didn't garner anything helpful
<PsyberS> Visualante: bzr revert <file>
<Visualante> thank you, PsyberS, i found another backup
<Visualante> ../Filename instead of Filename :I
<exarkun> Did I overhear that someone is already fixing the SIGWINCH bug?
<lifeless> exarkun: already fixed, in 2.1.2 and 2.2b3, I think
* lifeless changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: poolie | bzr 2.1.1 is out | bzr 2.1.2 is having binaries built for it
<devilsadvocate> hi, i really, really need some help. for some reason anyone using windows who tries to update a bzr repo here causes an error 123 (incorrect filename/path/...). i've tried bzr-revert, bzr-uncommit to the last few commits. no good. (everyone's using a checkout of the same branch and commit to it)
<devilsadvocate> does anyone know why this could happen / how i can sort it out?
<devilsadvocate> oh, and everything works just fine on linux. also, the last commit was made from a windows box.
<lifeless> have a look in your .bzr.log
<lifeless> bzr --version will show you where that is
 * devilsadvocate looks
<devilsadvocate> hrm
<devilsadvocate> http://pastie.org/private/nqddav49gqvkgmjh13zbq
<devilsadvocate> doesnt look very useful, though
<devilsadvocate> however, those last few folders there were part of the commits which i uncommitted
<devilsadvocate> and therefore shouldnt really be there
<devilsadvocate> so how do I _really_ back out some commit?
<devilsadvocate> hrm, I wonder if the : in that damn Thumbs.db:encryptable just irreversably destroyed my repository
<wilx> Colon in a name on Windows?
<wilx> That's syntax for data streams.
<devilsadvocate> I'm not sure where the : came from. I'm guessing it was made by windows along with Thumbs.db.
<devilsadvocate> maybe its a windows 7 thing
<toabctl> is there a good howto for handling debian packages with bzr and launchpad?
<toabctl> !launchpad
<ubot5> Launchpad is a collection of development services for Open Source projects. It's Ubuntu's bug tracker, and much more; see https://launchpad.net/
<zedtux> Hi all, I have a question: I've added the parameter create_signatures to my ~/.bazaar/bazaar.conf file and now when I do a commit it try to sign my commit (that's what I excepted) but my problem is that bzr don't take the right key. I have 2 or 3 GNUGpg keys. How to tell to bzr to use this other one ?
<lifeless> signing_command
<lifeless> see bzr help configuration
<zedtux> thanks lifeless
<zedtux> Thanks it works !
<zedtux> See u
<mementomori> hi
<mementomori> I've hit my first conflict and now I've meld with 3 panes: BASE, THIS, OTHER
<mementomori> which file will be the resolved one?
<mementomori> I suppose THIS but I'm not suse
<mementomori> sure
#bzr 2011-05-30
<poolie> hi spiv
<spiv> Hi poolie.
<poolie> hi there
* poolie changed the topic of #bzr to: Bazaar version control <http://bazaar.canonical.com> | try https://answers.launchpad.net/bzr for
* poolie changed the topic of #bzr to: Bazaar version control <http://bazaar.canonical.com> | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: jam
<fullermd> Aaugh, I'm channelling vila.  I just spent a good 30 seconds wondering how my bzr got broken so it didn't recognize the 'renvo' command.
<poolie> :)
<poolie> there is a bzr-autocorrect plugin
<fullermd> I'm holding off 'till it corrects bugs in the commits.
<poolie> :)
<poolie> spiv i might pull in jml's try_import idea
<spiv> poolie: ooh, that might be quite nice
<poolie> mgz: hello?
<poolie> oh actually i wanted martin vg
<poolie> so many of them
<vila> fullermd: glad to see you back ;)
<vila> fullermd: you want https://launchpad.net/bzr-guess so you get:
<vila> $ bzr renvo
<vila> Command 'renvo' not found, perhaps you meant 'revno'? [y/n]:
<vila> doesn't work for urls so I still needs hhtp to be defined in /etc/services though
<bob2> hahaha
<poolie> bonjour vila
<vila> poolie: hellllo !
<poolie> vila, are you actually the pp this week? or was that for last week?
<poolie> wow i like the pqm queue length graph
<vila> last week, sorry I wanted to send the mail earlier but...
<poolie> i think i understand now
<poolie> np
<poolie> i was thinking of doing a patch that takes jml's try_import function into bzr
<vila> hehe yeah, the pqm one is funny to look at for the spikes ;)
<poolie> probably just copying that file (which is MIT-licenced)
<vila> hmm, good idea (for the feature), I'm a bit at a loss for the license issues though...
<poolie> i puzzled about it for a while
<vila> you can include MIT-licensed stuff in a GPL project ?
<poolie> i'm pretty sure you can
<poolie> according to wp
<vila> yeah, it would make sense (but who is wp ?)
<poolie> wikipedia
<poolie> the mit licence text is a bit apparently selfcontradictory
<vila> bah of course :)
<poolie> also it's not actually labelled as "this is the MIT licenec"
<poolie> i recognize the general type of course
<vila> by the way, could you have a look at my two config-lock mps which are blocking 3 other mps to land ?
<poolie> yeah
<poolie> i'm going to stop in a bit; i'll do that now
<poolie> what are you intending for this week?
<vila> hmm, good question :)
<poolie> also, which two branches? i see several
<vila> config-locks and config-lock-branch
<vila> the three other are approved but have these ones as pre-requisites
<poolie> ok
<vila> sp this week I have a couple of mps I should keep reviewing, a patch-needswork bug, a bit more work on babune, windows corrupts the subunit stream, maverick is still hanging (I suspect paramiko there and/or some subprocess that needs its stderr handled with spiv's last trick), there is also a resolve --take-other bug or two
<vila> s/sp// wth ?
<vila> ha, s/sp/so/ gee I can't even understand my tyops no ? I blame fullermd
<poolie> did you ever see http://hyperboleandahalf.blogspot.com/2010/04/alot-is-better-than-you-at-everything.html :)
<vila> s/no/now/ eeerk
<poolie> (just cause you had 'abit' in your comment)
<poolie> maverick in the chroot is hanging?
<vila> hehe, yeah I read a bit a while ago
<vila> yees
<vila> there is a bug filed for that, let me see
<vila> and hardy is hanging too lately (but that's a vm)
<vila> bug 788235
<ubot5> Launchpad bug 788235 in Bazaar "blackbox.test_serve.TestBzrServe.test_bzr_serve_port_(readwrite|readonly) hangs on maverick " [High,Confirmed] https://launchpad.net/bugs/788235
<vila> and it's either paramiko IPv6 issue or a full stderr pipe
<vila> mwhudson: ping, AIUI you have some experience with using openID for jenkins, I have a couple of related questions
<poolie> why do the tests use threads?
<poolie> well, i suppose because you want to check that the lock guards the entire write operation?
<vila> to test concurrency
<poolie> :/
<poolie> i quite dislike thread tests
<poolie> they seem to often have spurious failures or hangs
<vila> I want to test things that are occurring during the lock
<vila> poolie: I'd like to debug this thread disliking :)
<poolie> and i'm not convinced they are always a reliable test of the real case
<poolie> :)
<vila> concurrency is hard, this doesn't mean threads are bad
<poolie> so threads give you concurrency that is by default uncontrolled
<poolie> things will serialize only as much as you specifically require
<vila> well yes, I test the problematic cases
<poolie> this means there may be different traces on different executions of the test
<vila> I could be wrong and miss some, but I have to start somewhere
<vila> I try to avoid that
<vila> (assuming that by 'traces' you mean threads could execute the tested code in different order
<poolie> so that's one way it seems likely to give tests that may pass or fail from one run to the next
<poolie> another is that our tests tend to make a fair use of monkeypatching
<vila> that would be a bug in the test
<poolie> or similar techniques
<poolie> (which may be an antipattern itself)
<vila> right, you need a way to inject sync points
<poolie> and that's going to interact very poorly with threading
<vila> not if done with care
<poolie> i do wonder if, if the right sync points exist, you can just do something synchronously there
<poolie> right, i'm not saying it's impossible to use it correctly, just that it has the possibility of problems that don't occur with synchronous code
<vila> that's what the tests aim for, make sure one thread always wait for the other
<poolie> my impression is the majority of our intermittent-failure tests have been concurrency related
<poolie> either threads or processes
<poolie> and also that server threads have caused a fair number of other hard-to-eliminate bugs
<vila> my experience is that fixing them has always mean add an explicit sync
<poolie> right, probably
<vila> i.e. we were using uncontrolled concurrency
<poolie> so in these tests, for example
<poolie> imbw but i tihnk if the background thread gets an unexpected exception, the test will just hang
<vila> which ones ? config-lock-branch ?
<poolie> config-locks
<poolie> my specific thing would be, why not just at the moment the config is saved, do the other operations in the same thread
<poolie> if it's totally synchronous, why do you need another threda?
<vila> hmm, generally, with synchronous code,  you can't just stop the execution exactly where you want
<poolie> what do you mean?
<vila> in test_writes_are_serialized, I want to stop when the lock is held but the write has just occurred
<vila> in test_read_while_writing, lock held, write hasn't occurred yet
<vila> and so on
<poolie> ok, but by overriding the method you can stop it at exactly those points
<vila> ?
<vila> and how would you resume ?
<poolie>  perhaps i'm missing something
<poolie> i was just going to say that in your c1_save code
<vila> perhaps me too :)
<poolie> rather than triggering the Event
<poolie> just actually do the inspections  or other manipulations you want to have happen, ie check that it's locked, that you get contention trying to address it from another object, that you can still read from it
<vila> hmm
<vila> you may be right
<vila> but this has a cheating smell...
<poolie> ?
<vila> testing concurrency in a single thread
<vila> now, these tests are hard to read, some helpers are needed
<poolie> hm
<poolie> so the thing is the concurrency we actually care about is between different processes, quite likely on different machines
<vila> I was kind of waiting for more examples to find them
<vila> right
<poolie> anything we do from within  a single test process is just an approximation to that
 * vila nods
<vila> but a bit closer than doing it in a single thread
<poolie> well
<poolie> how?
<vila> also, if I define hook for load/save/get/set (which I must do anyway) I should be able to write clearer tests
<poolie> yes
<poolie> i was thinking this the other day actually
<poolie> that perhaps we are too much in the habit of using knowledge about the implementation in writing tests
<vila> how ? Well, at least each thread is supposed to represent a different process which should help think about the issues
<poolie> eg overriding methods, rather than putting in hooks
<poolie> mm
<poolie> i just don't think it actually does help
<poolie> many of these things, we actually will have a separate in-memory object for each client
<vila> indeed, using threads is supposed to help focusing on specifying: what if this process is *here* and this other one try to do X
<poolie> like your c1 c2
<poolie> i think seeing a flattened trace of all of the actions across all actors is perhaps clearer
<poolie> anyhow
<poolie> does that help explain my dislike of them a bit more?
<vila> right, that's where I smell the cheating in the sense that flattening the trace is more arbitrary than setting *one* break point
<vila> yes
<poolie> what do you mean by 'one break point'?
<poolie> one synchronization point?
<vila> I think it's one area where I lack clarity and fail to explain why we should continue in this direction ;)
<vila> yes
<vila> I think about them as breakpoints: stop there while I look around
<poolie> right, it is more arbitrary
<poolie> but they're both arbitrary on any particular run of the tests; it's just that the threaded approach is arbitrary in an unpredictable way
<vila> and also that they don't exist in production, I need them only for tests
<poolie> it may just once happen to catch something interesting, but perhaps not be able to reproduce it
<poolie> this isn't good
<vila> well, it's arbitrary only on the parts I don't care about
<vila> so the idea is that if all parts we care about are covered by different tests, we're good
<vila> hehe
<vila> of course this isn't good
<poolie> well, but then why is this any better than having a totally deterministic trace?
<vila> because you still ignore all the other possible traces
<poolie> .. but you just said they don't matter
<vila> oh, sorry, wait a sec
<vila> right, we are both talking about what seems more natural I think
<vila> I start having some experience with threads so I'm less concerned about the related problems there
<vila> I still don't know if the same kind of tests can be written without them, it's possible but I have a vague feeling that some cases will be... either harder or less clear
<vila> Also I didn't focus on clarity for these ones, I just cargo-culted them (we have the same ones for the actual implementation)
<vila> all of them would benefit from hooks and helpers to make them clearer
<vila> hmm
<vila> but what you'd like is a try at not using threads for them I presume ? ;)
<poolie> http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.pdf "The Problem with Threads"
<vila> don't you have one with 'solution' in it ? ;D
<poolie> :)
<poolie> i'd like to avoid using threads where possible
<vila> ok, time to reveal the hidden agenda :)
<vila> I'd like threads to always be hidden behind generators
<poolie> i think both from a general-approach perspective (like in that paper) and also from the empirical results of tests that have caused problems, this is worthwhile
<vila> but we're far from that
<vila> you want to get rid of all the tests that needs a server running in a concurrent thread ?
<poolie> perhaps ideally yes, but that may be one of the harder ones to fix
<vila> just reading the abstract of that article, I agree with the problem
<poolie> i think code like this mp is a really easy case
<vila> but the solution is to teach developers to deal with it, not hope for a language to magically address it (hint: it won't)
<poolie> hm
<vila> so not using threads for simple cases... won't help us to learn
<poolie> :)
<poolie> it will help us learn how to avoid them ;-)
<vila> which will make threads even more scary because we'll have to deal with them on complex cases (and I suffered a lot from that in the thread/socket leaks saga)
<poolie> hm, maybe
<vila> bah, avoiding them is easy, we've done that for the last 20 or 30 years
<vila> now Intel is stuck with adding more cores and we're still not using them properly :)
<poolie> i think CSP-like architectures are one important way to go
<vila> I know I've been asking for grace periods on several other topics in the config loom, but I really think we *need* to go forward (not backward) with threads
<poolie> i think directly creating threads inside application-type code or individual tests does not seem like it's really learning?
<poolie> why?
<vila> threads and generators
<vila> once you start thinking about the data you need to process as generators instead of lists, you're reached the first step.
<lifeless> but python :P
<vila> The second step is then to split the data production into parallel producers
<lifeless> I don't think you want threads in general production code that doesn't strictly require them, do you?
<vila> GIL is not a concern anymore as soon as your producers involve IOs
<vila> today ? no
<vila> tomorrow ?
<poolie> are you really saying this is strictly needed for configs?
<poolie> for the first iteration of them?
<vila> poolie: certainly not
<vila> but I know of only two sites were threads are explicitly used in tests (here and in mass_import)
<poolie> there were some others, but i think they've Ã¿
<poolie> now been deleted or rewritten
<poolie> well, also servers
<vila> right, I excluded servers (you can't have servers without threads)
<vila> by the way, if we were to apply your approach to client/server tests....
<poolie> well, two things
<poolie> first, i'm primarily saying "don't use them where it's not necessary" and to test them at the moment it may be necessary
<poolie> secondly, it is at least conceptually possibly to make synchronous calls into the server code and back out
<poolie> and that might well make tests more deterministic and easier to debug
<poolie> so, can we split this?
<vila> It seems you're still thinking that using threads means non-determinist behaviour, that's may be true by default, but it's unfair to exclude synchronization from the picture, one way or the other you *have* to take it into account. Flattening a concurrent execution is just one way to express the synchronization
<poolie> please don't use threads to simulate multiple processes in the config tests
<poolie> yes, that's correct, but i think it's overall the best way
<poolie> to quote that paper
<poolie> " deterministic ends should be accomplished
<poolie> with deterministic means
<poolie> "
<vila> argh, would you at least accept a followup for that ? The intent here was to test the new design by re-using the existing tests :-/
<poolie> but they're new tests
<vila> copy/pasted
<poolie> are they copies of something that is already used?
<vila> yes, same file
<vila> same author :)
<vila> old bug
<poolie> :/
<poolie> a lot of stuff in bzr deals with concurrency across processes
<poolie> i can forsee the test suite getting pretty gross if that's all done with threads
<poolie> and these are actually _longer_ than they would be if written without it
<poolie> i need to go
<poolie> if you really want to do it as a follow on i could live with it
<poolie> but, i'd rather just have it fixed now
<poolie> hopefully the discussion was useful anyhow?
<vila> useful, yes, I think we still disagree but that shouldn't block progress ;)
<poolie> well
<poolie> i'd like to understand some time why you like them for testing
<poolie> and what you think we should do with them generally
<vila> sure, I will also think about how to write such tests in a linear way
<vila> I'm sure there is room for both ;)
<vila> So there is no need to force them on readers that dislike them when they don't buy us something else
<vila> poolie: I started on them when I *had* to (leaks). It turned out I gather valuable experience for the udd importer and continued there. I think it's a valuable long term goal we can't really afford to miss (and that's certainly where we need to discuss more).
<vila> poolie: I also failed to summarize what I learned there (what are the symptoms to look for, what are the common errors, what are the safe tricks, etc)
<spiv> vila: FWIW, I share poolie's dislike of threads
<spiv> I haven't read that PDF yet, but one aspect that really troubles me about using them in tests for concurrency is that they are always non-deterministic to some extent unless your analysis of how the states of the concurrent operations interact is perfect.
<vila> I realize they don't have a good press and I can see that python implementation is really minimal
<vila> spiv: right to the point
<spiv> If you fail to notice a race, you get intermittent problems.
<spiv> Now *finding* problems is great
<spiv> But we don't put random fuzz tests in our test suite
<vila> the other face of the coin is: how correct is our implementation regarding concurrency if we don't explore it with tests ?
<spiv> (Or perhaps I should say "in our unit test suite")
<spiv> I'm all in favour of writing tests to discover bugs.  But then I want small, focused, isolated, deterministic tests that those bugs are fixed as much as possible.
<vila> but poolie is right that there may be other approaches to explore that
<vila> me too
<vila> I think this is can *also* be achieved with threads
<vila> great power, etc
<spiv> So by all means write tools to race threads/processes/etc against each other
<spiv> And let's fix the bugs we find
<spiv> But not build our primary test suite on that.
<vila> eerk, generic tools to race arbitrary executions is a no-go, the combinatory (sp?) explosion wall is right there
<spiv> Same as fuzz testing.
<spiv> (Which really ought to doâ¦)
<vila> ?
<spiv> s/really/we really)
<spiv> http://en.wikipedia.org/wiki/Fuzz_testing
<vila> still ? :-/
<vila> yeah, same issue
<spiv> It's absolutely valuable to do that sort of testing.  It finds bugs.
<spiv> But I don't think it pays off to have that in the primary test suite.
<vila> meh
<vila> Oh
<vila> You meant " tools to race threads/processes/etc" but not in the core test suite
<vila> But the config tests starting the discussion are not fuzzy at all, they *are* deterministic
<spiv> Then I'd prefer them to not use threads
<vila> I think I heard the message :)
<spiv> Because our experience with threads in tests are that they often aren't deterministic even when we think they are.
<vila> I think I now that quite well...
<spiv> I'm sure you do :)
<vila> which is why I'm working on making them clearer by acquiring the knowledge about we fail to recognize the race conditions which requires sync points which in turn make it possible to re-gain determinism where we need it
<spiv> It's just not possible in general is my suspicion
<vila> But I'll repeat: "there is no need to force them on readers that dislike them"
<spiv> Because say you carefully analyse the code and add in all the necessary synchronisation points
<vila> spiv: well, my experience there is that it's not *that* hard
<spiv> As soon as someone changes the code it may invalidate that analysis
<spiv> But you can't know that without redoing it
<vila> this remark is not specific to threads
<spiv> (And even then, we get it wrong sometimes)
<vila> neither is this one :D
<spiv> Right, but normally mistakes in understanding code doesn't lead to non-deterministic tests
<vila> concurrency hard, let's have beer (TM lifeless) :)
<vila> s//is/
<spiv> Especially tests with failure conditions that include hanging!
<vila> yup, but some hangs are easier to avoid than others
<spiv> As opposed to a simple "state machine didn't end up in state X (and here's the sequence of transition it took)"
<spiv> If you want to argue we need more experience with threads, I'd argue we need more experience with explicit state machinees :)
<vila> spiv: you're preaching the choir :)
<vila> we need more experience with both anyway :)
<spiv> Well, let's start with the non-evil one then :P
<vila> spiv: are you suggesting rewriting our thread-based servers on top of asyncore (not over my dead body) ?
<spiv> asyncore over my dead body too!
<vila> hehe
<spiv> asyncore in fact is partly terrible because it doesn't separate out concerns like âstate of my protocol decoderâ from âstate of my IO event loop implemented on select on socketsâ
<spiv> You might notice that the bzrlib.smart.protocol module provides e.g. a decoder that is decoupled from any particular form of IO
<spiv> You just feed it bytes (however and whenever you acquire them) and it tells you what protocol events they generate
<spiv> So actually, yes, I do want to replace the vast bulk of uses of SmartTCPServer in the test suite with no threads and no real IO at all, just direct calls into the server logic from the client.
<spiv> It would have many benefits, like make walking through HPSS logic via pdb much nicer â you'd be able to follow the call from the client into the server's processing, and then follow the response out of the server and back into the client quite smoothly
<spiv> Whereas stepping through the multi-threaded interactions with pdb if you want to inspect more than one thread at once is quite painful
<vila> impossible even
<spiv> Nothing's impossible ;)
<spiv> But yes, close enough. :)
<vila> crossing the thread boundary is the key point and you generally don't know where you can safely step a single python line
<vila> and each time you fail you have to start all over again which is indeed painful
<vila> spiv: do you know any technic that would allow attaching a pdb session from a console to an existing python process ?
<vila> hmm
<spiv> vila: you can attach gdb
<spiv> which in natty is a bit more python-aware
<vila> ha, but I really want a pdb session ;)
<vila> anyway, even that sounds... complex, I'm not sure you can even reach a safe model where each thread can be stepped by a different pdb... so
<vila> spiv, poolie : I think one misunderstanding in this discussion is that if I indeed recognize that threads are non-deterministic but I try to use them in deterministic ways
<vila> and I'm not saying the later is easy, but it is achievable (since that's what I did with the thread/socket leaks (I know of at least one more pending bug which is triggering an intermittent failure on babune though))
<jam> vila: read the paper from poolie, it is quite interesting, and a nice structuredway of looking at "how do you make threading deterministic, and how can we do better"
<vila> jam: yup, I'm reading it
<vila> and I think I'm advocating the same thing: use idioms that ensure determinism
<vila> this is vastly obfuscated in the config tests, so I can understand the concerns here :D
<vila> it's just too bad I didn't commit this week-end while diagnosing bug 789167
<ubot5> Launchpad bug 789167 in Bazaar "bzrlib.tests.blackbox.test_serve.TestBzrServe.test_server_exception_with_hook is fragile" [Critical,Fix released] https://launchpad.net/bugs/789167
<jam> vila: can you change the topic to make me pp. For some reason Empathy doesn't want me to do anything with /topic or manually editing it.
<vila> at least two times I had examples where the tests were exhibiting a particular point very precisely and with only a few lines of code
<vila> jam: poolie already did that earlier
<jam> vila: hm... empathy still says "vila" for me...
<vila> jam: blame empathy :)
<jam> i blame you, but only because I have no other choice :)
<jam> back in a bit
* vila changed the topic of #bzr to: Bazaar version control <http://bazaar.canonical.com> | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: jam, yes jam not vila
* vila changed the topic of #bzr to: Bazaar version control <http://bazaar.canonical.com> | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: jam
<vila> jam: what topic do you see now ? (I made and revert a change while you were away)
<jam> I see my name on it now
<jam> not sure when that was fixed
<jam> and I restarted in the mean time
<vila> that probably fixed it
<vila> poolie's change went out of my scrollback so it was probably during our night, but I saw it this morning when scrolling, irc logs may still mention it (if you're interested)
<jam> vila: test_writes_are_serialized, why not just use a callback rather than thread locking?
<vila> primarily and as far as the current proposal is concerned: because I copied/adpated an existing test :)
<vila> secondarily: It sounded like the easiest way to test concurrency back when I implemented the test for the actual design to fix bug #525571
<ubot5> Launchpad bug 525571 in Launchpad itself "No locking when updating files in ~/.bazaar" [High,Fix released] https://launchpad.net/bugs/525571
<vila> and I think the related mp is https://code.launchpad.net/~vila/bzr/lockable-config-files/+merge/33424 and nobody mentioned threads in that time :)
<vila> at the time ?
<jam> at the time
<jam> anyway, I'll try to give a closer look tomorrow, but I will say event based interlocking seems like callbacks would be just as good, and much more straightforward.
<vila> these tests won't stay in the middle/long term, I don't really care about working on them
<jerryb> two bazaar questions:  1. Working on just part of a large project.  I have checked out the trunk and want to create a branch for my work BUT don't want to copy the whole trunk.  How can I do this with Bazaar?
<jerryb> Question 2.  If I propose a merge of my branch for a project and it is accepted and merged into trunk, can I then remove my branch from launchpad and remove my working copy?
<maxb> 1. You can't work with just a subtree of a branch.
<maxb> 2. Remove from Launchpad: sure, if you want, but why bother?  Remove local working copy: of course.
<cody-somerville> weird.
<cody-somerville> I'm using the pipeline plugin
<cody-somerville> I renamed the directory containing the pipeline
<cody-somerville> and now it isn't working. It says:
<cody-somerville> bzr: ERROR: Not a branch: "/home/cody-somerville/Projects/live-build/live-build.old/.bzr/pipes/sg-2.x/
<cody-somerville>  /".
<cody-somerville> (remove whitespace on second line)
<maxb> I believe absolute paths to other pipes in a pipeline are stored in the pipe branches config files
<cody-somerville> this is doing *any* command
<jerryb> maxb: Thanks!
<cody-somerville> its add \n/ to .bzr/branch/location for some reason
<cody-somerville> *adding
 * cody-somerville will try echoing into the file the current contents with the -n option to see if that fixes it.
<cody-somerville> and it does
<cody-somerville> how strange how that even happen
<cody-somerville> oh, I know
<cody-somerville> It was an absolute path so after renaming it, it didn't work anymore. I edited it to fix it, editor of course adds newline
<cody-somerville> How do I fix this error I get when trying to push a new branch to launchpad?: https://pastebin.canonical.com/47961/
<cody-somerville> seems second time is the charm
<beuno> cody-somerville, yeah, looks like some branches need upgrading
 * jelmer wavez0rs
<michaelh1> Morning.  Is there a way to turn revisions into patch files with one patch per revision, and each file automatically named?  (Google fails me...)
<michaelh1> Apparently git format-patch does something like this.
<jelmer> michaelh1: hi
<jelmer> michaelh1: if you have bzr-git installed, "bzr send --format=git" can do something similar
<jelmer> michaelh1: it's not quite as well polished though
 * michaelh1 tries it...
<michaelh1> Ah, it blows up with an exception.  I am running the dev ppa though...  I'll file a bug
<jelmer> thanks
<michaelh1> Is there a way of installing the latest release and latest dev side by side?
<jelmer> michaelh1: not easily, though I should note that if this is broken in the dev version it's probably broken (or missing) in the release version too
#bzr 2011-05-31
<spiv> Morning folks.
<poolie> hi spiv
<poolie> my turn to flip from waking at 3 to waking at 10 :)
<spiv> Heh
<poolie> lifeless: i don't totally understand your comment in https://code.launchpad.net/~gagern/bzr/bug421776-sftp-move/+merge/62708
<ubot5> Ubuntu bug 62708 in bluefish (Ubuntu) "Please sync bluefish_1.0.6-1 from Debian unstable (main)" [Wishlist,Fix released]
<lifeless> poolie: we don't know the provenance of the existing file
<poolie> hm
<poolie> we can safely assume it came from another bzr process?
<poolie> we don't know whether that process is still running, dead, etc
<lifeless> right
<poolie> so...?
<lifeless> I would be wary of assuming the file matches what we're uploading
<poolie> if it exists, the process that wrote it thought it was correct at the time it finished writing
<poolie> it may have been wrong (buggy)
<poolie> or there might have been file corruption
<lifeless> true. And either that process failed to link it in, failed to unlink it, died, or raced with us on linking it in and did so immediately before we last read the pack list
<poolie> but, those possiblities don't seem any more likely here than for any other existing pack file
<lifeless> well
<lifeless> Call me conservative :)
<poolie> if you're asserting for example "a race means it's more likely the file suffered corruption" that's fine, i'm happy to consider it
<poolie> i just want to understand what you're saying
<lifeless> I couldn't really put a probability on it
<lifeless> but I would worry about trusting something that may have crashed when we don't have to
<poolie> ok
<lifeless> for instance
<lifeless> if the machine powered off, without ordering between file renames etc, we might have a zero length file with the right name, not linked into pack-names
<poolie> yes, that's very possible
<poolie> it's also possible it would end up showing it mentioned in pack-names and yet also have the wrong content
<lifeless> yes
<poolie> so, being extra careful in this case seems a bit odd
<lifeless> uhm
<lifeless> this doesn't seem like being extra careful
<poolie> you say "we should check if the existing file is intact"
<lifeless> once its in pack names (in the absence of attackers) we know that the prior bzr process completed
<poolie> i don't understand why we would do that over sftp but not locally
<lifeless> we don't know if the fs went awol or not
<lifeless> poolie: we would do it locally too, wouldn't we ?
<poolie> hang on, "we know that the prior bzr process
<poolie> completed" --> that's not true if the machine crashed without an ordered journal of renames
<poolie> aiui this bug is sftp specific, about the general pack upload code not working the same way over sftp
<poolie> imbw
<poolie> i'm going to read the general pack code
<lifeless> poolie: so IIRC locally we rename over the top
<lifeless> we resolve by assuming our new file is correct - which is the ultimate form of lack-of-trust
<lifeless> so this case (which for -very- narrow windows win32 might display too) is when we cannot atomically rename over the top
<lifeless> and we don't have a safe rename-out-of-the-way dance that others could use to handle the file-is-temporarily-missing case
<poolie> right, we do
<poolie> ok, so using .move (which really means, force replace) would be most consistent with what we do locally
<lifeless> yes
<lifeless> I was suggesting a verification scan (for the pack and the indices) as a workaround to deal with the race condition.
<poolie> in other words you like his current patch?
<lifeless> uhm, I think its evolved since I commented
<poolie> yes
<poolie> perhaps rather than delete-and-replace we should move the existing pack into the obsolete directory, so if we're interrupted after deleting it, we won't lose
<lifeless> so move has this race condition
<lifeless> I don't particularly like that :)
<lifeless> I don't want to block anyone
<lifeless> I was trying to highlight the interacting constraints
<poolie> don't like moving it to obsolete-packs?
<poolie> thanks for the review
<poolie> i do appreciate it
<poolie> am just trying to understand it :(
<poolie> s//:)
<poolie> so there is actually an sftp rename operation argument saying what behaviour you want
<lifeless> ideally we'd make it behave like a local fs :)
<poolie> hm
<poolie> seems there is possibly a small race on windows too, if we delete then rename
<poolie> ok, thanks for that
<lifeless> its possible to address the race by having a predictable path to look for fallback files
<lifeless> or even just spin on the path in clients
<poolie> in the hope it will appear again soon?
<lifeless> right
<poolie> right
<poolie> they're probably separate bugs
<lifeless> but if its linked in pack-names
<lifeless> I think you need 2 paths - a normal one and a before-naming-into-place one
<poolie> for here, i think asking sftp to overwrite, and forcing the overwrite, is probably safe
<lifeless> so that repo recovery can do something sensible
<poolie> s/safe/an improvement
<lifeless> I think we have retry-on-missing-packs now
<lifeless> I worry about a network interrupt during that race though
<lifeless> how will the repo be recovered
<poolie> right, i'm most concerned by the connection dropping (or the server crashing) after it applies the deletion but before the new file moves into place
<poolie> spiv, teddy, should i actually do a patch for jml's try_import?
<poolie> it does clean things up and it should make pylint cleaner
<poolie> bit of an optional yak though
<poolie> (there are something like 100 'except ImportError' catches at present)
<jam> poolie: after it deletes but before it renames, is probably before we write pack-names
<jam> I was concerned at one point, but now... locally we overwrite on posix systems
<jam> and I think "crash" on Windows
<jam> it seems fine to overwrite on remote systems *without* validation
<jam> becuase we justuploaded content *we* are happy with
<jam> who cares if there is unreferenced garbage that we get rid of
<jam> corrupted or not
<jam> we aren't re-instating the pack file that we think was corrupted
<jam> "might have been"
<poolie> right
<jam> we are putting the new hottness there
<poolie> right
<poolie> hello btw
<jam> The only race I can think of is 2 processes both renaming into place, and being ready to update pack-names. p1's rename succeeds so it goes to write pack-names
<jam> p2 sees the collision, renames out of the way
<jam> then p1 writes pack-names, and the machine crashes
<jam> before p2 finallizes its insert
<jam> poolie: but, a) I think sftp rename dance does try to preserve the old file as a .tmp
<poolie> so you could possibly manually recover
<poolie> hm, fancy_rename asserts sftp rename won't let you overwrite
<poolie> perhaps either we didn't know of that option, or it wasn't supported then
<poolie> or still isn't supported by servers
<poolie> so it sounds like you're ok with my last comment
<vila> hi all
<jam> poolie: "rename" is intentionally for lock/held directories
<jam> we don't want to overwrite dirs that aren't empty
<jam> that happened accidentally on some sftp implementations, like launchpads
<jam> move is the "rename according to posix"
<vila> poolie, jam: Sounds like another concurrency testing case, how about trying the no-threads approach there to see how it works ?
<jam> vila: in this case, a callback at the right time seems very appropriate, because it is *very* sensitive to timing
<vila> that's why I suggest trying it
<jam> poolie: I'm checking your comments.
<jam> vila: I think there is a hole, I'm not sure it is worth fixing
<poolie> hi vila
<poolie> i agree using a callback and no threads would be good
<poolie> vila i will try to reply to your opus
<jam> poolie: I believe the stardand secsh spec is actually 3, at least back when I was researching it a lot, you couldn't guarantee support for anything newer
<vila> poolie: not urgetn, I'd rather be unblocked on the reviews (well, unless they are tied)
<jam> there were some file open apis and some remote hash apis that would have been promising at th etime
<jam> anyway, if we wanted to change Transport.move() to try to use that flag, i'm for it
<jam> but *not* Transport.rename
<poolie> jam btw you're pp this week
<jam> poolie: yep
<poolie> vila, i think the reviews are unblocked
<jam> for sftp we don't want to overwrite a held/info directory that already exists
<poolie> i would really rather the tests were not threaded
<poolie> but i won't absolutely block them
<poolie> otoh it seems easy to change them
<poolie> jam, right, the directory overwrite behaviour is very important it not change
<vila> meh, neither one got a vote, am I being too conservative reading the comments ?
<poolie> vila, i guess i'd put it in a similar case to tests that use subprocesses: use it if you have to, but if we end up doing it a lot something may be wrong, and we don't want to set a pattern of doing it
<jam> vila: I think the reason I haven't been faster at approving stuff is that I'm still pretty uncomfortable with lots of little bits across the whole stack. Which doesn't give me confidence in any given piece.
<jam> I do realize that you've had your head in it more
<vila> I agree with the principle, but I don't feel it applies to a case where tests were copied before you raised the issue
<poolie> vila, i think i meant them both to be +tweak
<jam> so I'm willing to defer to your focused insight where it matters
<poolie> vila i think this is kind of showing the cost of landing goes up more than linearly
<poolie> with the size
<poolie> otoh some things perhaps can't be done piecewise
<jam> I think I like the idea in broad terms
<vila> poolie: you mean that splitting this work in smaller pieces didn't help ?
<poolie> hm, not sure
<poolie> this was a bit like: write one big thing; chop it up; propose all the pieces
<poolie> as opposed to proposing smaller bits as you go
<poolie> but perhaps there are hidden costs to that
<vila> I think we discussed being a bit less risk averse so I'd delighted to see our policy go more in the direction: this bit is controversial, add A FIXME, address it later, rather than: this bit is controversial, let's reach a consensus before landing it
<jam> vila: I think I've tried to do that, I think the fact that it seems to come up at most stages concerns me
<vila> especially when there is not enough energy spent on reaching a consensus by all parties involved
<jam> (10 stages, and 5 of them have "FIXME" seems a bit odd, if only 1 or 2...)
<poolie> i think the thing is that when there are many related patches in flight the whole thing gets a bit harder to discuss
<jam> maybe I'm mis-estimating
<vila> but if they are all in the same patch they are hard (~impossible) to review
<poolie> well, there is doing without consensus; and then there is also being more willing to get consensus even on something that's imperfect
<poolie> personally i like the second concept better
<vila> the above remarks were general, in this specific case, I've been proposing scaffolding code (and tests) that I think shouldn't be reviewed as strictly as code that will stay (especially tests)
<vila> I can't reach a point where we can discuss on the end result if I had to constantly refine code I intend to throw away in the end, this start discussions on code that is not there to discuss about
<jam> vila: having code that you are throwing away in the end is odd, and inconsistent with how we usually do it, hence we don't really know how to act on it.
<jam> I understand your view point
<jam> just saying it is coming from a place we don't usually look at
<jam> hence confusion and delay
<poolie> right
<poolie> what's a good example of scaffolding here?
<poolie> are you talking about code to support apis you intend to get rid of?
<vila> this a good discussion, I'm not throwing stones, I feel there is several issues and no easy solution, so we should discuss
<vila> _CompatibleStack, the tests with threads are the most obvious ones
<vila> the Stores (already have FIXME), the xxxStacks (already have FIXME)
<poolie> hm
<poolie> i think generally speaking if there's some code that's a bit ugly or inefficient but there's a comment explaining it will be soon deprecated, people ought to take that into account in reviewing
<poolie> (they might still think it's too buggy or something)
<poolie> i think generally "I will throw this out in the future" is not very relevant to reviews
<vila> I don't think I can implement a full deployment, add new features, provide a migration path and only then break into pieces for review without incurring a huge push back... (not to mention the delay just to reach that)
<poolie> because it's hard to know for sure that you actually will come back to do it
<poolie> something more important could come up next week, or you could get sick or whatever
<vila> yup, it's hard to know
<poolie> so they need to make sense individually
<vila> which is why I insist on putting a name and a date in FIXMEs
<poolie> shrug, there are named dated fixmes from years ago
<poolie> it's a good practice but it is no guarantee they'll be fixed
<poolie> we should be ok with stepwise refinement; promises it'll be better in future are really not that important imo
<vila> I think it's better than not putting them
<poolie> the fixme comments?
<vila> yes
<poolie> i agree they're good
<vila> and my goal for config is to have none of them left in config.py
<vila> (I just review them and I strongly confirm)
<vila> so it's hard for me to buy the "you won't fix it" argument there and instead it makes my life harder to fix them *now*
<vila> which I think is close to the root cause of my frustration there
<poolie> hm
<poolie> well, it's good to talk it over
<poolie> one way to look at it, which might be oversimplified
<poolie> is that there are things that must be fixed before landing; and things that don't need to be
<poolie> we should be careful where we draw the line
<poolie> but, if something really is in the first class, then it actually must be fixed; an earnest intention to do it later is by definition not enough
<vila> right, I generally tend to fix things I don't fully agree with to make landing easier, if I don't intend to fix quickly, I file bugs or add FIXMEs, the distinction between the two may not be clear enough as sometimes I use FIXME for issues that are so big I don't even have a good answer for them
<vila> or are so unrelated to the proposal I just punt to avoid falling into yak-shaving mode
<jam> poolie: correct. Though if enough of "doesn't need to be fixed before landing's it gives some unease about the stack
<vila> like 'external_url should accepts an optional relpath' where the implications are all over the place
<vila> ha, no, I filed a bug for this one :)
<poolie> jam what do you mean "about the stack"?
<vila> the whole config work
<poolie> so, i haven't reviewed every branch
<jam> poolie: the stack of changes that are being proposed. If you have 5 patches pending, and each one has a FIXME or 2, it makes (at least me) concerned
<poolie> i think on the whole, having a bunch of branches that possibly interacts, or possibly fix some problems in lower layers
<poolie> it's actually harder to review than just one big patch
<jam> Sometimes unnecessarily so.
<poolie> possibly this is partly a bug inlp
<poolie> jam, right
<poolie> also it's harder to see what the actual eventual big picture will be
<jam> poolie: I think it depends on how inter-related the stack of patches is.
<jam> sometimes layering can easily separate out bits
<vila> also, the approach I tool was to (try to) minimize the scaffolding so adding each piece can raise its own issues (say: lock remote config files currently ignores control.conf which is used only on lp but doesn't have (AFAIK) corresponding tests to exercise against)
<poolie> probably
<jam> but if a later patch modifies *the same code*
<jam> then it isn't really separated
<vila> I tried to use devnotes to track the big picture, but the issue here is that it conflates know issues with solutions that requires new features and I'm only at the no-new-features replacement stage :-/
 * vila nods about higher threads fixing issues in lower threads
<vila> that makes reviewers life hard
<poolie> i'd like to be tracking it against a doc in the developer guide
<poolie> i'm not sure which active branch, if any, might be adding or updating that
<poolie> is there one? or is it landen?
<vila> on the other hand, the past experience with big patches is there to demonstrate this doesn't work either so I had to try something else which we are debugging right now :-}
<poolie> also, that's an issue with having a stack of patches
<poolie> you can't easily see the overall change to some thing
<poolie> (couldbe fixed with tooling, or even just having an overall integration branch)
<poolie> vila, so, i don't know
<poolie> it would be good to work out how to make this less frustrating
<vila> https://code.launchpad.net/~vila/bzr/new-config/+merge/56887 ?
<poolie> i feel it's a bit hard to see the big picture
<vila> right, so, do you confirm you're ok to land the current branches ?
<vila> The good thing I see in this approach is that we get rid of agreed upon code with some pieces still needing work
<vila> at least it becomes possible to make independent proposals for these pieces
<vila> As a reviewer myself, I prefer a smaller followup than a bigger proposal
<poolie> so to me the thing that seems to work best is to just have one mp at a time, make it self contained (both without introducing new serious problems, and hopefully also improving something) and then do a series of those
<vila> Sometimes it means *I* should do the followup though...
<poolie> is new-config current as the overall thing, or have the others moved?
<poolie> because i feel like that diff is not so big as to be impossible to review
<vila> argh, but the current series was pushed to the point I could actually present a use case because people weren't seeing how the lower threads will work !
<poolie> and it would address this thing of not having an overall picture
<vila> let me check
<poolie> hm
<vila> hmm, it seems to be current (in my local loom) , tip is pushed, but lp diff is bogus :-(
<poolie> re the issue of not seeing how lower levels will work
<poolie> i think
<poolie> it's not necessary to see them used from code
<poolie> but i would look for, either it makes the current code at that level cleaner by refactoring it
<poolie> or, at least the cover letter can tell a story about how introducing this will later let us do a particular thing
<poolie> a prose description of what you're steering for would i think be enough
<vila> hmm, you mean something with a restricted target compared to devnotes ?
<poolie> what's a good example
<vila> of what ?
<poolie> anyhow "weren't seeing how the lower threads will work" --> I think just a good cover letter should be able to solve this; we don't need hundreds of lines of code
<poolie> example of not seeing how the lower levels will work
<vila> well, the weakref branch ?
<vila> the _compatibleStack ?
<poolie> can you give me the url?
<poolie> so your current-config is everything merged in together?
<vila> https://code.launchpad.net/~vila/bzr/config-lock-remote/+merge/62418
<vila> poolie: don't know yet, waiting for lp to refresh
<vila> right, looks better, n oidea about the conflicts though...
<poolie> for instance, in that branch, i'd like to know whether there is developer documentation of .unload()
<vila> is the fact that 5 FIXMEs are in red there saying something ? :D
<poolie> it's not easy to see whether that's true
<poolie> well, that's good
<poolie> i guess i could just ask you
<vila> there is a doc string for unload()
<poolie> yes
<vila> argh, self._save() ??? Wtf
<poolie> which is good
<poolie> it's a bit like the conversation with jr at the sprint
<vila> hmm, which one ?
<poolie> that docstrings i think aren't so good at giving people an overview of what they'resupposed to know about
<vila> hmpf, you think the actual ones are better ? Not throwing stones again but... I try to improve and I try to not wait for perfection before proposing :D
<poolie> which actual ones?
<vila> hehe, exactly :)
<poolie> you're saying the developer guide is not better than the docstrings at the moment?
<poolie> well, i don't think we should block your landings on having a perfect developer guide
<poolie> i think it's reasonable to ask about it
<spiv> I don't think better/worse is the way to compare the dev guide to the docstrings
<poolie> and in fact that developer guide content could be a good way to communicate where this is going
<spiv> They serve different purposes I think
<spiv> "guide" vs. "reference manual" broadly speaking
<poolie> right
<poolie> the guide should tell you where to begin
<vila> right, I think issues about unload() would be encountered during tests for new Stores rather than by people using them
<spiv> Unfortunately I have to log off now due to ill wife, but it's an interesting discussion you've been having.
<poolie> :)
<poolie> hope she gets better soon
<vila> spiv: take care of her, there will be logs ;)
<poolie> i'm sure she'll find that reassuring :)
<vila> hehe
<vila> back to the dev guide, just at this minute, I don't know whether it's good or not
<vila> It may be a bit too soon to put too much effort into it though since I haven't reach the point where I can say: ok, I've been able to deploy for all actual uses (no new features), the Store implementation is complete
<vila> But at that point, I will be able to write a doc saying: this is how it works, this is what is needed to implement a new one
<vila> So I'd say a bug is appropriate to track this
<vila> hmm
<poolie> hm
<poolie> i think it's easier to write as you go along
<poolie> but perhaps i should do a followon patch that tries to explain it, as i understand it
 * vila falls to his knees
<vila> please do so !
<vila> That would be so much more productive as far as I'm concerned !
<vila> And probably illustrates how I think the reviews should evolve: many comments should just be : blah, blah, if you dont get the picture, look at lp:~bzr/bzr/blah-blah
<vila> will avoid a bunch of round-trips
<poolie> ?
<poolie> what do you mean?
<vila> followon patches could be done *during* review
<vila> to the reviewee (sp?) can just merge them
<gour> speed improvements are main thing arriving in 2.4?
<vila> a trivial example is spelling mistakes, it's almost as fast to fix them and push a branch for the reviewer, but it avoids a roundtrip for the reviewee
<vila> well, roundtrips may be more for less trivial stuff but you get the idea
<poolie> gour: probably the largest thing: http://doc.bazaar.canonical.com/bzr.dev/en/whats-new/whats-new-in-2.4.html
<vila> a more involved example would be the tests with threads ;-)
<poolie> vila, yes, and there too lp could handle it a bit better
<gour> poolie: thanks...i was looking for such doc, but could not find it
<poolie> arguably we should make some of these branches team-owned so that other people can directly commit to them
<poolie> perhaps
<poolie> vila, i'm reading your doc
<vila> the devnotes one ?
<poolie> no, the threads mail
<vila> oh, start with the followup :)
<poolie> you can just send it to the list if you want
<poolie> it's a bit rambly
<vila> and come back to the main one then
<poolie> i agree that these tests should mostly look like a sequence diagram
<poolie> that is a good way to express it
<poolie> so the question then i guess is, what way of writing the test best expresses the sequence diagram
<poolie> and, which way of writing it is least likely to have accidental problems
<vila> yup
<poolie> i think writing it as tests is no clearer (probably less clear); and much more likely to have bad consequences such as hangs
<vila> I don't think there is a clear cut to favor one above the other
<poolie> to me it is clear from our experience so far
<poolie> there are clear tests for concurrency that work in a single thread
<vila> I've made significant progress regarding hangs (and there really are several kind of hangs, the babune ones are only one)
 * gour considers that 2.4 will be one very fine release
<vila> s//are only one sort)
<poolie> well, i'm glad, and i appreciate that
<poolie> but, it's better if we can just avoid the issue
<poolie> gour :) me too
<vila> indeed
<poolie> for instance if you look at test_lockdir
<poolie> and perhaps as a single example test_20_lock_contested
<gour> i'm moving full to bzr now (will migrate some repos from fossil via git)
<poolie> this *could* be written with threads, but i think it's pretty clear, and much less likely to have weird problems, the way it is
<gour> *fully
<poolie> :)
<vila> poolie: right (nit:  addCleanup(lf1.unlock))
<poolie> good point
<poolie> it's a very old test, from before we had that
<poolie> (though it could have used finally, of course)
<vila> poolie: sure, it's fine as is
<vila> What I would love on this thread in test issue is that we go a bit further using the config ones as an example
<vila> I've looked at them again and frankly, they are old too
<vila> in the sense that in they were written for a bug which in the end is really addressed by using an atomic write
<vila> and since it's atomic, the initial issue of having two processes mixing its content is moot and the tests are just... relying on this assumption anyway
<poolie> hm
<vila> they *were* useful for me in my actual work as ~blackbox tests ensuring the new code paths were covered
<vila> but since the new code path *also* assumes an atomic write, the same remark applies...
<poolie> mm i see what you mean about you copying existing test
<vila> simply deleting them seems extreme though
<poolie> ok; i have to talk to jam now
<vila> poolie: before you left: you didn't answer to the "meh, neither one got a vote, am I being too conservative reading the comments ?"
<gour> AfC: hiya, is bzr still your preferred dvcs? (/me still remembers your 'orthogonal patches' post)
<poolie> config-lock is needsinfo
 * vila blinks
<vila> not approved then ?
<AfC> gour: hello
<gour> AfC: hiya
<AfC> gour: yes, I still use Bazaar pretty much exclusively.
<gour> AfC: that's nice to hear...i did experiment (after leaving) darcs with mtn and fossil for some time, but now i'm moving fully to bzr
<AfC> gour: that puts me at odds with most of the other hackers I collaborate with, but I don't really care. Our having switched to Bazaar predates their having switched from CVS to Subversion, and their subsequent Git infatuation doesn't impress me much either.
<gour> he he...i also cannot grok git and use bzr-git in such cases...it's quite good
<fullermd> I always assume that when I disagree with everyone around me, it's 'cuz I'm right and they're wrong.
<fullermd> ...  of course, when I _agree_ with everyone around me, that's also because I'm right and they're wrong.  They're just wrong in more subtle ways.
<AfC> fullermd: have you ever considered moving to a medium sized mountain top in India and becoming a guru?
<gour> lol
<fullermd> Oh, absolutely.  But have you priced out decent 'net connectivity on mountain tops lately?!
<AfC> wisdom is not bought without sacrifice.
<fullermd> Sure, but couldn't I just trade a firstborn or a limb instead?  A man's gotta draw the line somewhere.
<gour> here is some wisdom from the vedas: "In a place where there are no scholars, even a men of petty knowledge is worshiped just as in the land devoid of trees, even a castor oil plant is considered as a big tree."
<vila> gour: castor is the new kid in town but I'd rather stick with goats
<AfC> Goatherds Unanimous
<phanatic> hi, do you have any suggestions how i could fix an inventory corruption? https://bugs.launchpad.net/bzr/+bug/620684
<ubot5> Ubuntu bug 620684 in Bazaar "ERROR file id "None" is not present in the tree when checking the root entry" [Medium,Confirmed]
<gour> vila: ;)
<vila> poolie: just foudn you comment on config-lock-remote with needsinfo (which *is* approved), but I was referring to config-locks and config-lock-branch :-/
<poolie> vila, sorry, i want to get these fixed up and landed but it's getting too late here
<vila> poolie: I'll switch to something else then, enjoy your evening
<poolie> jam or i or both will concentrate on them later this week and try to get you unblocked
<jam> vila: actually I'd like to do some phone chatting with you if you want. *right* now I need to go eat some food.
<vila> hehe, jam (and I) won't be there that much later this week :D
<vila> Thursday is a holiday here
<vila> jam: sure, I will eat a bit later though. What subjects do you have in mind ?
<jam> vila: just to go over your config stuff in a live chat and get it done, rather than high latency email/irc
<jam> vila: I feel like we had you do a big work on your own, and we need to rectify that. "big" (more than 1 weeks worth of work) should really be a collaboration.
<jam> for config, you're the only one that really has the state in your head, and we've had disjoint reviewers, etc.
<jam> so nobody else really understands it. So either we are rubber stamping because we know you're smart, or we are fragmenting on details we don't understand.
<vila> jam: interesting point of view, I'm glad you discussed with poolie :D
<vila> Indeed, I should have realized it sooner...
<vila> I guess it's hard to realize how much people understand without seeing code so the devnotes document wasn't that useful (or too broad or aiming too far in the future)
<jam> vila: it has been a general issue for us. I've hit it as well when I do major work. It is really hard to get major work landed, if it wasn't a collaboration.
<vila> That reminds me of the i18n effort too
<jam> so lets make them collaborations.
<vila> yup, I welcome that !
<poolie> :) hooray, i can sleep soundly
<poolie> good night, gets
<poolie> *gents
<vila> yeah, I corrected the typo before seeing the fix !
<poolie> hi jelmer, welcome back
<jelmer> hi poolie, thanks :)
<jelmer> things appear to have been busy here last week :)
<vila> jam, poolie: I thing there are far enough itches there for anybody to find several to scratch...
<vila> jelmer: yeah, when we woke up from your patch avalanches we realized we had some of our own :D
<vila> jelmer: but please, keep the snow balls rolling !
<poolie> i wonder where jr is
<poolie> on holiday this week maybe
<poolie> anyhow, see you tomorrow
<jelmer> have a good night poolie
<jelmer> vila: :)
 * vila lunch time
<gour> i'd like to convert all my old fossil repos into bzr. fossil has --git export command which can create fast-import stream...now i wonder if i could do fossil --> bzr in one step?
<gour> i've tried with the following: fossil export --git -R ~/repos/fossil/admin/cfgfiles.fossil| bzr fast-import -
<gour> but bzr crashes
<gour> here is the paste - http://pastebin.com/zT10Re96
<fullermd> That sounds like bzr and the fastimport plugin being mismatched.
<fullermd> Though at least you're using a sensible OS   :p
<gour> :-)
<gour> here it is https://bugs.launchpad.net/bzr-fastimport/+bug/485788
<ubot5> Ubuntu bug 485788 in Bazaar Fast Import "bzr fast-import fails: AttributeError: 'CHKInventory' object has no attribute 'copy'" [Medium,Triaged]
<jelmer> gour: looking..
<jelmer> gour: still there? Can you try a different fastimport on that fastimport file?
<gour> jelmer: will do...after lunch
<gour> jelmer: what do you mean 'different' ?
<gour> another format?
<jelmer> gour: latest revision
<jelmer> see the bug report
<gour> ok
<CaMason_> hi guys. I have a branch with several merges that may be missing some revisions - is there a command to show a list of 'tips' or old commits?
<jelmer> CaMason_: hi
<CaMason_> hello
<jelmer> CaMason_: bzr heads (from the bzrtools plugin) should be able to help
<jelmer> in particular, "bzr heads --dead"
<CaMason_> thanks. blank.
<CaMason_> I might have to take a look through a backup. Thanks
<mvo> hi, a quick question, if I want to copy a file (not rename) and retain history, is there a way to do that with bzr? i.e. bzr copy gtk2.py gtk3.py and then going wild on gtk3.py
<jelmer> hi Michael
<jelmer> mvo: No, there's no way to track files across copies at the moment
<jelmer> we have some thoughts on how to do so, and bzr is will probably support it in some form or another in the future - but today it's not supported
<mvo> jelmer: ok, thanks!
<jam> hey Riddell, just looking at your zlib patch now
<Riddell> thanks jam, if it's rubbish feel free to tell me so :)
<gour> jelmer: http://pastebin.com/YReiaLQ0
<jelmer> gour: try again?
<vila> what happened to bzr-2.3.3 for natty ?
<jelmer> (r319)
<jelmer> vila: I'm not sure - were we going to do a SRU?
<vila> same here, searching for poolie's sru page (or was it maxb's page ?)
<vila> a wiki to keep track of the srus
<maxb> http://wiki.bazaar.canonical.com/UbuntuStableReleaseUpdates
<vila> maxb: you rock :)
<vila> google: can you beat maxb and mgz for *my* requests ? Bah, of course you can't !
<vila> maxb: If I read this page correctly, 2.1.4 is still in the pipe and 2.3.3 hasn't been started, right ?
<vila> bug #494221 is marked fix released, rmadison still says 2.1.1 for lucid, 2.1.4 for lucid-updates
<ubot5> Launchpad bug 494221 in Bazaar 2.1 "KeyError in remove_recursive_id during commit" [High,Fix released] https://launchpad.net/bugs/494221
<vila> so the SRU for 2.1.4 is completed no ?
<gour> jelmer: http://pastebin.com/BS2HbXV1
<jelmer> gour: that fastimport stream must be quite unusual :-/
<jelmer> gour: is the stream public?
<gour> jelmer: no, but i can try with another one which is public...wait a minute
<jam> jelmer: https://code.launchpad.net/~nmb/bzr/merge-force-doc/+merge/62938
<jam> you voted approve after poolie asked for some changes
<jam> was that just delayed email?
<jelmer> jam: Uhm, yeah, let me retract that
<jelmer> jam: Done - thanks
<vila> PP ftw :)
<maxb> vila: Ah, right, looks like 2.1.4 has been promoted
 * maxb wonders what the dates symbolise
<vila> maxb: last modification of the topic ?
<maxb> oh. "The date is the upstream source release date." a bit below
<vila> damn, good catch
<maxb> I wonder why that's useful
<vila> I think it gives some rough idea of how long it took to complete the SRU
<vila> well, rather since when it has started
<vila> -ish
<vila> :)
<vila> . o O (That was really a clear summary, your S/N ratio sky-rockets !)
<fullermd> Well, if it's TOO clear, it's a full report, not just a summary   :p
<gour> jelmer: i cloned fossil repo available with fossil clone http://www.fossil-scm.org/ myclone.fossil and then try to fast-export/import and got - http://pastebin.com/czLmWLdb. Fossil is available at http://www.fossil-scm.org/download.html and compiles into single-file executable.
<jelmer> gour: can you upload the problematic fast import file to the bug report?
<gour> jelmer: you mean git-export format created by fossil?
<jelmer> gour: yeah
<jelmer> the bit you pipe into bzr fastimport
<gour> ok
<gour> jelmer: it's 471M...shall i compress it somehow?
<jelmer> gour: can you perhaps see if it's possible to reproduce the issue from a trivial fossil repository?
<gour> ok
<maxb> So, yes, it would be appropriate to get the 2.3.3 SRU underway now
<maxb> bug 616878 is a non-trivial behaviour change which would require particularly careful analysis
<ubot5> Launchpad bug 616878 in Bazaar "bzr commit error because of no identity (should look at /etc/mailname)" [High,Fix released] https://launchpad.net/bugs/616878
<gour> jelmer: small file is attached to the bug report
<jelmer> h
<maxb> We'll need to be particularly careful, as it's not the sort of change normally SRUed
<jelmer> gour: thanks
<vila> jam: finally available, are you ? Mumble ? Phone ? Here ?
<jam1> hey vila, probably about 20min for me
<jam1> then mumble or phone
<jam1> or sip if you have it set up
<vila> no, only mumble and phone, but I think I can call you for free
<vila> mumble leaves both of my hands free though and I suspect I may need them :)
<jam1> uhm.... heh heh
<jelmer> gour: fixed
<jelmer> gour: though I should note that the way fossil uses fastimport seems really odd
<gour> jelmer: let me try...otoh, i just want to convert repos to bzr...one-time event
<gour> jelmer: drh also complained how git handles it
<jelmer> gour: drh?
<jam> vila: logging into mumble now
<gour> jelmer: dr richard hipp, author of fossil & sqlite
<jelmer> gour: I agree with him fast-import isn't ideal (it's very git centered), but the way fossil seems to use it is inconsistent with how all other systems (including git, where it originated) use it
<gour> jelmer: i see...otoh, attempt to import my 'olod' repo gives - http://pastebin.com/CSAZGPfp
<jelmer> gour: can git import that file without problems?
<gour> let me try
<gour> jelmer: it does import
<jelmer> gour: are you trying to import into a clean bzr branch?
<gour> jelmer: yes
<jelmer> gour: in that case I'm out of ideas
<jelmer> gour: an alternative might be to import via Git
<gour> that's what i'm trying now
<gour> import via git fails as well
<smoser> hm... i had a link to a list of packages that were broken for udd, but i can't find that link.
<smoser> anyone?
<smoser> found it.
<smoser> http://package-import.ubuntu.com/status/
<gour> jelmer: i've tried to export git repo and import into fossil & bzr...former works, the latter fails
<smoser> my next question would be "how does one get a package removed from that list"
<jelmer> smoser, by fixing the relevant bugs in the package importer
<jelmer> gour, how does importing into bzr fail?
<gour> jelmer: http://pastebin.com/CvwEcVaH
<gour> i used: git fast-export --all
<jelmer> gour, what version of git?
<gour> git version 1.7.4.5
<jam> vila: http://paste.ubuntu.com/615364/
<jelmer> gour, I'm afraid I'm out of ideas in that case
<jelmer> gour, or perhaps clone the git repository with bzr-git?
<gour> jelmer: ok
<gour> jelmer: you can export from git and import into bzr?
<gour> jelmer: i clone many repos with bzr-git, but i wanted to test whether bzr fast-import cam import from git
<jelmer> gour, I haven't seen a lot of issues with bzr-fastimport, its testsuite also covers a fair number of corner cases
<jelmer> that said, you seem to've hit an open bug
<gour> i've tried from random git repo to export and import into bzr...same error
<gour> so, it's not just cae with fossil-exported repos
<jelmer> in that case there might be an external thing
<gour> ?
<jelmer> I've never seen that particular error with bzr-fastimport and I've done dozens of imports
<jelmer> are you using python-fastimport trunk?
<gour> i just tried with https://github.com/cournape/Bento  -same problem
<gour> yes, trunk version
<jelmer> gour, what exact command are you running to export that repo?
<gour> jelmer: git fast-export --all > ../repo.fi
<jelmer> 15:39:01 Imported 1826 revisions, updating 1 branch and 1 tree in 0:00:19
<gour> and then: bzr fast-import ../repo.fi fro mwithin newlly-init bzr repo
<gour> strange
<jelmer> gour: trunk bzr-fastimport *and* trunk python-fastimport?
<gour> jelmer: found what's the problem
<maxb> Oh, I've been meaning to ask - does this look like a transient error?     bzrlib.errors.TooManyConcurrentRequests:<module>:main:import_package:make_db_set:get_branch_parts:open:open:open_from_transport:open:_open:__init__:_probe_bzrdir:_rpc_open_2_1:_call:call:call_expecting_body:_call_and_read_response:_send_request:_construct_protocol:get_request:__init__
<gour> the directory which i used for testing was somehoe, initiliazed as shared-repo
<gour> jelmer: now it works directly piping it from fossil
<gour> but import is only partial..another problem
<jelmer> gour, partial in what way?
<jam> vila: http://paste.ubuntu.com/615380/
<gour> jelmer: not all revisions are imported...fossil --> git has all revisions
<jerryb> Question:  I'm learning bazaar after a while with svn.  I'm wondering if/how I can do "bzr diff <path>" to show the last set of changes like I can with "svn diff -rprev <path>".
<gour> now i'll try git --> bzr
<jam> vila: http://paste.ubuntu.com/615383/
<jam> http://paste.ubuntu.com/615384/
<gour> jelmer: fossil --> git imported only ~300revisions, while fossil --> git --> bzr all of 'em (~500)
<gour> s/fossil --> git/fossil --> bzr
<maxb> smoser: Did you have a particular package in mind?
<smoser> i dont care a lot about 'nut' i was just doing a merge and saw it broken.
<smoser> i have to say that doing merges with bzr is a whole lot nicer than with 'grab-merge'
<jelmer> gour: bzr fastimport only imports trunk, not other branches by default (see its default output)
<gour> jelmer: i'm aware of it..the problem was that i did tests in ~/ff dir in which i, by mistake did bzr init ., which was supposed to be done in ~/ff/dir and then, everything was done as within bzr repo which was otherwise empty, but having ~/ff/.bzr greatly confused bzr, as you can see
<gour> jelmer: maybe something can be done to detect it instead of spitting "BadRestart: Bad restart - attempted to skip commit 39 but matching revision-id is unknown" ?
<jelmer> gour, well, that would require us to know *why* you're getting that error first
<gour> trying to reproduce it now, but it stubbornly works :-)
<jerryb> Question:  I'm learning bazaar after a while with svn.  I'm wondering if/how I can do "bzr diff <path>" to show the last set of changes like I can with "svn diff -rprev <path>".
<maxb> -c-1
<maxb> oh, the last set of changes that touched <path> ? That may not be so easy
<vila> 'bzr diff -r-1 <file>' works fine
<maxb> even if <file> didn't change in the last revision in the branch?
<jerryb> vila: doesn't work.  e.g. I got a diff with 'bzr diff -rlast:2 <file>' but nothing with zr diff -r-1 <file>
<jerryb> maxb: yes
<vila> oooooh, sorry, missed this bit
<vila> bzr log -l1 <file>
<vila> will tell you the rev
<cr3> how can I branch just the code from a project with minimal .bzr overhead where I don't intend to make any commits nor pulls
<maxb> I don't think the bzr remote protocol offers a convenient way
<cr3> maxb: something minimal would be fine too
<vila> mgz: around ?
<mgz> ue.
<vila> mgz: about cleanups and cycles
<vila> when the test has run (or fail) the cleanups are run and deleted right ?
<vila> so any reference in a cleanup method can't be involved in a cycle, still right ?
<mgz> yup, though it's not always obvious if there are other cycles.
<mgz> it's safe to pass a bound method as a cleanup callback though
<vila> right, in my case it's not even a bound method ;)
<vila> mgz: thanks, that answers my question
<chx> hi. in the past there was a Drupal mirror on launchpad. We built the site based on that. Now Drupal uses git (*weep*) and I am trying to merge. This is not trivial to say the least. How can I tell bzr that the other tree (i created with bzr-git or fastimport, doesnt matter much) revision 14503 is pretty much the same as r17861 here? (It wasnt the same but close enough that merge can work from there)
<chx> bzr merge -r 14503..-1 gives me a content conflict for every file.
<jelmer> chx: that's the "parallel import" problem - it's a nontrivial thing to fix
<chx> Yes.
<chx> I figured as much.
<chx> hey you are the guy who write dulwich arent  you
<maxb> Anyone with jubany access got a moment? I'd like a ./requeue_package.py --auto xbl
<chx> and fastimport too
<chx> and bzr-git as well?
<chx> jelmer: Hi! You are my guy that's for sure :D
<jelmer> chx: Yeah, I'm active in all three projects by coincidence :)
<jelmer> hey maxb
<maxb> Hello
<chx> jelmer: so... are there some docs i should rtfm to deal with the problem? or just give up, roll a monster patch apply and struggle?
<chx> hehe googling bzr parallel import leads to http://wiki.bazaar.canonical.com/ThreeWishes here where it's one of jelmer's wishes
<jelmer> chx: I'm not aware of any docs; you should be able to do some sort of fancy rewrite of the old branch to make it use the same file ids as the new (git) branch
<jelmer> chx: however, there is no command that can do that at the moment
<maxb> I wonder if it's possible to contrive something useful by means of rm / add --file-ids-from=
<jelmer> chx: it might be worthwhile to ask on the list, other people might have better ideas
<chx> jelmer: https://lists.canonical.com/mailman/listinfo/bazaar this?
<jelmer> chx: yep
<maxb> chx: Is there an import of drupal's git registered on Launchpad?
<chx> maxb: no :(
<chx> maxb: David owns the Drupal branch
<maxb> Well, I suggest making one, then :-)
<chx> ok wrote David Strauss an email so we can do that
<maxb> Do you need to?
<maxb> The drupal website is pretty unfriendly to people looking for its VCS
<maxb> Hm. Looks like a bzr-git import may be frustrated by bzr-git's current lack of support for importing anything other than the repository's HEAD branch
<chx> maxb:  i have a fastimport to work from tho
<maxb> Fastimport is considerably less convenient to incrementally update
<chx> thats for sure :/
 * maxb ponders putting "UDD failure ratchet: 487" in the topic
<chx> 487
<chx> 487?
<chx> maxb: well, i can do the bzr rm ; bzr add --file-ids-from dance for sure
<maxb> chx: So, I'd be inclined to do a bzr-git branch from a local git clone of whichever drupal branch you want to track
<chx> maxb: and then bzr rm --keep ; bzr add --file-ids-from ?
<maxb> (487 Ubuntu/Debian packages currently failing to import into Bazaar branches)
<chx> ah
<jelmer> maxb: How will "bzr add --file-ids-from" help, it means losing the history of all existing files. In that case, why not simply discard the existing history and rely on the new git history?
<jelmer> maxb: also, nice work on the UDD progress :)
<maxb> I was thinking that with some combination of rm / add --file-ids-from / merge / revert . it might be possible to make bzr behave in a roughly desirable manner
<chx> i am happy to lose core history
<chx> i have more copies of core history than i can possible care for :P
<maxb> Though I've had a fair amount of beer, so I might be missing something :-)
<chx> yeah that's what i am trying to do now
<maxb> I think it would roughly play out as:
<maxb> 1) Check out the latest upstream revision in the ancestry of your old site branch
<maxb> 2) bzr rm --keep everything; bzr add --file-ids-from the-new-import .
<maxb> 3) bzr merge -r 0..-1 the-new-import; bzr revert .
<maxb> with a commit after 2) and 3)
<maxb> 4) bzr merge the result of 3) into the tip of the old site branch; bzr revert .; bzr commit
<maxb> 5) bzr merge the new upstream import (with fingers crossed) :-)
<maxb> or something like that
<chx> maxb: this bzr rm // bzr add --file-ids-from worked beautifully
<chx> maxb: we dropped from 1042 content conflicts to 31 text conficlits and they are going fast (i am down to 14)
<poolie> hi maxb, jelmer
<jelmer> g'morning poolie
<poolie> i hope you had a good trip
<jelmer> yeah, it was great - nothing but sun and nature for a week :)
<jelmer> how was yours?
<poolie> nothing but motorcycles and mountains and rain for four days
<poolie> also great
<poolie> the rain is a mixed blessing
<poolie> it feels good when you get out of it ;)
<jelmer> :)
<jelmer> Just because it's rain, or does it also make for slippery driving?
<poolie> it's potentially a bit slippery, but i just go gently and it doesn't bother me
<poolie> it's more just getting cold and wet
<poolie> i had not reckoned on how much colder andwetter wales was than london
<poolie> it must have been something like 10C over 200km, without much change in elevation
<poolie> just more exposed to the Atlantic I suppose, and less human heat sources
<jelmer> oh wow, that's quite a bit colder indeed :)
<chx> maxb: OH at https://code.launchpad.net/~vcs-imports/drupal/head
<chx> maxb: you recreated this?
<chx> maxb: this needs to be , imo, git://
<chx> maxb: or maybe just the trailing slash is wrong?
#bzr 2011-06-01
<poolie> hi spivvo?
<spiv> Hi poolie!
 * spiv waits for the cold&flu pills to kick in
<poolie> hullo there
<poolie> oh what a shame
<poolie> spiv are you well enough to talk over the gc cycle thing with me
<spiv> poolie: probably
<poolie> here or phone?
<spiv> Here's probably better given the state of my sinuses
<poolie> yeah
<spiv> I might make the odd unpleasant sound :)
<poolie> :)
<poolie> so basically, vila implies that we ought to manually use weakrefs between application type objects
<poolie> even when we don't want actual weakref type behaviour of "i don't care if it's there or not"
<spiv> I do feel like a missed a memo about that somewhere
<poolie> me too
<poolie> hm
<spiv> I don't really know what the justification is, exactly
<poolie> so, for example
<poolie> if python was not capable _at all_ of dealing with cycles
<poolie> we would need a strict design rule about avoiding them, either by this method or something else
<poolie> (and i'd mostly prefer the "something else")
<poolie> but... is it really that bad?
<spiv> I'm sure it probably helps memory be reclaimed sooner, but I'd really like to see some quantification of how much and how soon.
<spiv> I guess my big question is: why do we (or at least vila) believe avoiding these cycles is significant benefit?
<poolie> yes
<spiv> I can certainly imagine it *might* be
<poolie> and, secondly
<poolie> if that problem exists, are weakrefs the best solution to it?
<spiv> And I could also perhaps be sold on an argument that this forces a bit more thoughtfulness about object lifetimes
<spiv> Hmm
<poolie> i think a design rule of "be thoughtful about object lifetimes" makes sense
<spiv> Weakrefs are certainly the most obvious solution :)
<poolie> hm
<poolie> i think the most obvious solution is to refactor the objects so there are no cycles
<poolie> sometimes this is hard
<spiv> But I suppose there are other options like splitting apart the objects more â right.
<poolie> but, here, having both the branch and the config each point to a lock would do
<poolie> and it doesn't seem that hard
<poolie> (modulo foreign format and api versioning stuff)
<spiv> I'm also not sure if the benefit is meant to be for CPython or some other VM
<poolie> right, obviously this will vary by vm quite a lot
<spiv> Right.
<spiv> (And it wouldn't totally shock me to find that weakrefs cause surprising differences in GC behaviour on some VMs)
<poolie> right, or that they make things much slower
<poolie> or more precisely access through them may be slower
<spiv> So I'm quite looking forward to the mail you asked vila to send, in the hope it answers some of these questions.
<poolie> i might send one first
<poolie> and he can respond
<spiv> More mail == more good!  At least in small doses :)
<poolie> lifeless: does that ring any bells with you (https://lists.ubuntu.com/archives/bazaar/2011q2/072972.html) ?
<lifeless> mmm
<lifeless> so I think some python implementations are worse than others
<lifeless> would you like me to reply to the list ?
<poolie> probably yes
<poolie> s//yes, unless you'd really rather prefer irc
<lifeless> list is fine
<lifeless> you pinged me is all :)
<poolie> this ws doc is very good :)
<lifeless> ?
<poolie> your service analysis proposal
<lifeless> ah, cool.
<lifeless> thanks!
<lifeless> poolie: replied to that gc mail
<poolie> thanks
<spiv> Hmm, what version of testtools does PQM have?
<maxb> Hopefully whatever is codified in bzr-landing-dependencies
<maxb> http://package-import.ubuntu.com/status/php5.html#2011-05-30%2002:58:42.080261 feels potentially transient - can I get a requeue to check?
* maxb changed the topic of #bzr to: Bazaar version control <http://bazaar.canonical.com> | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: jam | UDD failure ratchet: 487
<spiv> maxb: hmm, I suspect it's not, but sure.
<spiv> eglibc also has the same issue
<maxb> oh
<maxb> Whoops, I thought this was a unique new one
<spiv> Oh well, requeued anyway, just in case :)
<spiv> I think this is a failure revealed by the "remove stale connections from possible_transports" fix
<poolie> hi maxb
<poolie> ooh nice topic
<maxb> :-)
<maxb> So, somehow, the UDD importer has sprouted another test failure on natty since the sprint
<maxb> It doesn't feel particularly complex, but I've no idea what's changed to cause it to happen now but not then
<poolie> hm
 * maxb wonders why BzrDir.sprout takes a source_branch argument, and then ignores it
<spiv> maxb: it doesn't?
<maxb> It certainly seems to in my vim :-)
<spiv> Or with less layers of negation: it isn't ignored, it's passed to _find_source_repo
<spiv> (in trunk; the code was a little different in 2.3, but still not ignoring source_branch IIRC)
<maxb> whoops. too many matches in close proximity, I didn't spot that one
<poolie> ok, no more mail for today
<spiv> maxb: yep, php5 still fails the same way
<maxb> hm
<maxb> I have it running locally, and all it has accomplished so far is to make my laptop quite toasty warm to the touch :-)
<spiv> maxb: I suspect the possible_transports includes a smart transport that is still in use, or something like that
<spiv> Or that a transport that's not safe to re-use there, e.g. you can't pull from a repo (get_stream) and push back to a repo (insert_stream) on the same smart connection at the same time.
<spiv> It's interesting to me that it's a condition that's hit so rarely though.
<maxb> hm. I wish we had a command "bzr delete-tags-not-in-ancestry"
<spiv> maxb: should be easy enough to write that plugin...
<maxb> yes. It's more of a case of "Nooooo! Not another mental context switch!" :-)
<spiv> As always, it'd be good to know what the pre-existing request is in the TooManyConcurrentRequests traceback
<spiv> Hmm,
<spiv> I filed a bug about something that would address that a few weeks ago
<spiv> https://bugs.launchpad.net/bzr/+bug/745477
<ubot5> Ubuntu bug 745477 in Bazaar "Keep a record of recent events from bzrlib subsystems to use in crash reporting" [Medium,Confirmed]
<poolie> :)
<vila> hello guys, how are your cycles today ?
 * vila ducks
<vila> kidding, poolie: I answered your email
<vila> in summary: let's not start a jihad against gc cycles, this has never been my intent
<vila> spiv: /me blinks, the failure for your start_bzr_subprocess log details was related to testools ?!?!  :-(
<poolie> vila, what do you mean by
<poolie> " Such discussions tell me that this
<poolie> > doesn't work. That is far more concerning that using weakrefs or not to
<poolie> > me."
<vila> That trying to do minimal implementations to make reviews easier tend to trigger issues unrelated to the proposal slowing down the whole landing
<vila> There should be a better way to deal with that
<poolie> hm
<vila> Either there is an obvious better solution to use and the proposal and that should be done before landing
<vila> Or the issue should just be discussed and a new proposal will address it
<poolie> hm
<poolie> i agree in general
<vila> I ran into the case (as a reviewer) with i18n : I can't see an obvious way to address an issue and I tell Naoki: sorry, you can't land this
<vila> I feel really bad saying that :-(
<poolie> using weakrefs where they're not obviously necessary doesn't seem like the minimal implementation
<poolie> this is one case where we can probably land things and continue the conversation
<poolie> as i think you have
<vila> right, but what do you propose as an alternative, I'm fine doing a followup for that
<vila> just tell me "I'd prefer this" not "I don't like that"
<poolie> do you know whether weakrefs increment the referents refcount?
<vila> the former leaves me with a way to go while the later is just blocking me
<poolie> i guess no
<vila> ('you' and 'me' being general, not specific)
<poolie> well, i think many of your things it's just been "I don't understand this"
<vila> so, since the proposal, I had several discussions and I'm not sure anymore weakref is as simple as I thought
<poolie> :)
<vila> I still think it's less costly than leaving python handle it but... meh, I can live with just a comment saying, hey look, we create a cycle there, gnark gnark, go python have fun
<poolie> why do you think that?
<vila> think what ? That it's harder for python to break this cycle than to not have to worry about it ?
<vila> AIUI python gc will break it, it just requires more work
<vila> so 'have fun' == 'go, try harder'
<poolie> i can believe it takes more cycles
<poolie> is it more, or less, than dealing with the weakref?
<vila> my gut feeling is that it will be very surprising that it takes less
<vila> the weakref "just" dereferences once
<vila> and only for lock/unlock which doesn't occur often either
<vila> don't
<vila> let's try again
<poolie> ok, so it's basically just gut feel
<vila> For me, here, using a weakref is as prophylactic as using free(ptr) ; ptr = None
<poolie> hm
<vila> so I know for sure I won't try to call free again on ptr (free implementations that barf on ptr == NULL (gha NULL not None) should just die)
<poolie> sure
<poolie> though, today, in C, with valgrind, that code is no longer such a good idea
<poolie> or not unambiguously good
<poolie> but anyhow
<vila> I can change my habit and forget about it
<poolie> mm
<vila> It would make a bit more happy to understand what problems *you* have with weakref here though...
<poolie> i think having one person adding weakrefs out of habit would be bad
<poolie> also, relying just on gut feel as to what ought to be faster is pretty unreliable
<vila> hmm
<vila> And what is your gut feel here ?
<poolie> i am trying to avoid making assumptions about how python performs
<poolie> i think the reasonable base assumption is that it works as documented, ie unreachable objects will be gc'd
<poolie> if we find a particular case where it's slow, let's work out how to fix it
<poolie> if we can generalize from evidence that a particular pattern ought to be avoided, great
<poolie> i don't think we have that evidence yet so let's just write the simplest thing
<vila> haaaa, that I can buy easily, so what you're proposing is to just use self.branch and be done with it !
<poolie> yes, of course
<poolie> sorry if that wasn't clear
<vila> gee, no it wasn't
<vila> but s/wasn't clear/vila didn't get it/ :)
<spiv> vila: I replied to your mail
<spiv> vila: to add to the conversation in here, I wouldn't assume that weakrefs are necessarily less work for the GC implementation than a regular reference.  They're certainly *different* work.
<spiv> vila: and yes, +1 to just ignoring cycles and letting Python take care of garbage collecting them.
<vila> right, so basically we don't know, I'd be happy to write tests so we all get a better understanding but I believe this is not a priority
<spiv> Right
<poolie> no, it's really not
<vila> s/believe/damn well know/
<spiv> If we had infinite spare time I'd be curious to know how CPython copes with e.g. 10000s of weakrefs
<spiv> And of course there's the runtime cost in our code of resolving the weakref.ref instance to the actual object
<vila> yup, I start to realize weakref *implementation* doesn't match my mental model which roughly was more along the lines of: takes a ref but don't increment the refcount
<spiv> Right, the implementation has to be more complex than that
<poolie> so
<poolie> fewer lines of code, faster reviews, generally
<spiv> So that if e.g. that object is deallocated and a new one allocated at the same memory location the weakref doesn't accidentally hand you the new object
<spiv> vila: it may also interest you to know that it took a few releases of CPython before they really worked out all the bugs in how weakrefs interacted with the gc
<spiv> vila: there's some interesting comments in gcmodule.c and a .txt file near it in the source with some of the gory details
<poolie> so are we all agreed?
<awilkins> The default is now urllib2 isn't it? Not curl?
<jam> morning all
<awilkins> The reason I'm asking is essentially about SOCKS proxy support, in both bzr and ubuntuone-client
<poolie> hi jam
<awilkins> ubuntuone-client at least uses python-libproxy, which means it can cope with a PAC script, but then does not know what to do about SOCKS proxies. Bazaar does not use python-libproxy, and presumable doesn't know what to do about PAC scripts.
<poolie> hm
<poolie> requires running arbitrary javascript iirc?
<awilkins> Both of them are high-profile Canonical projects, written in Python, so it would seem that they could both benefit from coping with SOCKS and doing it the same way... the personal itch I'm scratching is that I have a PAC script I use to switch proxies at work / home, but it doesn't really work very well with many things that don't support SOCKS
<poolie> without checking, i think we do use urllib2 by default
<awilkins> poolie, libproxy provides the PAC script runner - ubuntuone-client uses the python binding of this library
<poolie> patches to use libproxy would be welcome
<awilkins> poolie, I looked at ways of handling socks with urllib2 and they involve monkeypatching it's socket implementation, I think
<poolie> :/ probably
<poolie> how does u1 do it?
<awilkins> Not to say I want to see a switch to curl - it was far more hassle AFAIR
<poolie> jelmer: hi?
<awilkins> U1 doesn't - it only copes with HTTP proxies
<jam> poolie, spiv, vila, jelmer: time for standup?
<poolie> yes
<poolie> spiv gave his apologies
<poolie> also, jr, hopefully
<poolie> but jelmer and jr seem to be asleep
<Riddell> morning
<jam> Riddell: ^^
<poolie> ... or, to have adifferent nick to what i thought :)
<poolie> hello
<Riddell> I'm not asleep, I'm the only one in the mumble chatroom
<poolie> touchÃ©
<vila> hehe
<awilkins> I guess you boys will be back in 20 mins or so if you are having a stand-up
 * awilkins contemplates monkeypatching sockets
<jam> awilkins: I know there was a python-dev discussion about how hard it is to override the socket interface for the http libs
<awilkins> jam, A common answer seems to be "PySocksify", which involves patching the whole "socket" implementation
<awilkins> http://stackoverflow.com/questions/2317849/how-can-i-use-a-socks-4-5-proxy-with-urllib2
<awilkins> Does setting socket.socket affect everything, or just the module-local import of socket?
<bob2> global
<maxb> I'd suggest just using a LD_PRELOAD socksifier
<bob2> yes
<bob2> tsocks or socksify
<maxb> tsocks is what I use
<maxb> it has the very useful feature of conditionally socksifying based on destination address
<awilkins> I use tsocks also, but it's awkward to use it on things that start up with your session.
<awilkins> Like ubuntuone-client
<poolie> jam:  oh, i guess in particular, reviewing udd mps too would be good
<poolie> i have some alpha code that gives you a tun device that redirects into socks
<poolie> i wonder where
<vila> jelmer: looms push don't know about lossdy, 1 failure (well 3 times the same really)  http://paste.ubuntu.com/615680/
<poolie> https://code.launchpad.net/~mbp/+junk/tunnel-forward
<jelmer> vila: I'll have a look - thanks
<vila> jelmer: great, thanks to you, the hidden question was: will he look or should I ? :D Not urgent
<jelmer> vila: :)
<vila> all: false alarm regarding pure python compat, it was just out-of-date extensions
<poolie> maybe in july we should try the sip conference system
<jelmer> That might be nice; mumble is still flaky here
<jelmer> I'll be sure to boot into natty rather than oneiric for next weeks' standup
<poolie> wow, oneiric already?
<poolie> is it good?
<jelmer> It's pretty good, a lot of it is already GNOME3, and it's fairly stable usually
<poolie> ok; good night
<jelmer> have a good evening, talk to you later
<jam> Riddell: I'm back around whenever you are
<jam> jelmer: Do you have SIP set up already?
<jam> we could try it (I have it set up here, and I know poolie does)
<Riddell> I've not used sip
<jam> Riddell: I found it reasonably easy to set up ekiga, as we have instructions on the canonical wiki
<jam> I used it for the sprint
<jam> since paying for 8hrs of phone time would have been bad :)
<jelmer> jam: I don't have it set up yet, but I might as well have a look now if we're going to use it later
<jam> jelmer: any chance you can kill jelmer_ ?
<jam> anyway
<jam> jelmer: I think poolie would like to switch, but I don't know any time frame
<jam> mumble tends to work better for large groups (IME)
<jam> but still has stuff like poor echo cancelation
<jam> actually, Skype still has the best echo cancelation of any programs I've used
<jelmer> Skype has worked best for me too, both on Ubuntu and Android
<jelmer> I find Mumble works reasonably well compared to most SIP apps on Ubuntu, but the Android app is still not quite there yet
<Riddell> ah, I need to ask sysadmin for a SIP account first
<Riddell> jam: well shall we chat on mumble?
<jam> Riddell: mumble's fine for me
<jam> and yes, you have to email rt@ to get your voip account
<Riddell> jam: you can't hear me?
<jam> Riddell: I can't hear you now, it isn't turning your lips read
<jam> red
<jam> so it isn't getting your "activation" volume, or whatever
<Riddell> jam: still no?
<Riddell> the icon goes red here
<jam> still nothing here
<jam> Riddell: I still don't see your lips go red
<jam> I can try relogging if it is maybe on my side. but you can hear me, right?
<Riddell> jam: no I can't hear you
<jam> relogging now
<jam> Riddell: can you still hear me?
<Riddell> jam: nope
<jam> Riddell: ok, I'll reconnect
<jam> I can hear you
<jam> Riddell: Did I go silent again?
<Riddell> yes
<jam> :'(
<jam> Riddell: do you have another voice program we can try?
<Riddell> jam: could try skype
<jam> Riddell: see private message
<jelmer> jam, vila, Riddell, poolie, spiv: UDD meeting in #ubuntu-meeting for those interested
<jam> jelmer: are you sure it is this week? I thought this was the off-week
<jelmer> jam: Yep, at least according to the wiki page
<jam> mgz: when you get this, I think we just need a live chat about: https://code.launchpad.net/~gz/bzr/lazy_hook_test_cleanup_785054/+merge/61586
<jam> I don't think I can just review the patch
<sbarcteam> hi guys.
<sbarcteam> I have failed to commit into a folder I have write access to with bzr.
<sbarcteam> the folder is owned root:root, and I'm committing as another "regular" user.
<sbarcteam> BUT
<sbarcteam> There are ACLs, and the user can create files/folders inside repository's folder with UNIX shell.
<sbarcteam> Is it possible bzr assumes UNIX permission model and avoids trying operations on files/folders owned/permitted badly by "UNIX" convention ?
<sbarcteam> I did dig the bzrlib code.,
<spiv> sbarcteam: IIRC bzr doesn't check first (in this scenario), it just attempts to create (trusting that the OS will return a permission error if it doesn't have permission, etc).
<spiv> sbarcteam: pastebin the error you get?
<sbarcteam> the specific operation bzr fails upon is this locking LockDir
<sbarcteam> and it gives me some kind of file.
<sbarcteam> does lock files creation require special kind of access list entry ?!
<spiv> Please, paste the text of the actual error into http://paste.ubuntu.com/.  Perhaps run the command with -Derror to force bzr to give a traceback too.
<spiv> That way we can tell which specific filesystem operation is failing.
<ScottK> I'm having trouble fixing a mistaken tag.  It seems no matter what I do I get conflicting tags when I try to push the change.  Would someone point me to some documentation about how to handle this (I did what I thought bzr help tag was suggesting)?
<spiv> ScottK: 'bzr tags -d $source' is presumably listing a different rev for that tag than 'bzr tags -d $dest'?
<spiv> ScottK: either reapply the tag delete/rename/update directly to dest too, or just delete it in dest then push.
<ScottK> spiv: Thanks.
<mgz> jam: I'm around briefly, but out again shortly. I should be around all tomorrow though.
<jam> mgz: either way
<vila> spiv: eerk, you're around ! I think I fixed bug #788235 ;)
<ubot5> Launchpad bug 788235 in Bazaar "blackbox.test_serve.TestBzrServe.test_bzr_serve_port_(readwrite|readonly) hangs on maverick " [High,Confirmed] https://launchpad.net/bugs/788235
<jam> I'm gone the rest of the wek
<jam> week
<mgz> okay, let's go over it quickly now
<mgz> vila and I discussed it a little a few evenings ago, my real problem is I don't get how hooks are meant to work now
<jam> they aren't  (?) :)
<vila> hehe
<jam> mgz: so is the issue you aren't sure if hook dicts should be completely empty?
<jam> or whether we should be able to reset them, or what?
<mgz> I'm not sure what work needs to be done to get the level of hook isolation tests expect
<mgz> currently the old code iterates over known hook objects and fiddles with their attributes
<mgz> and when lazy hooks were added, some (broken) code for emptying and refilling the new _lazy_hooks dict was added
<mgz> but when trying to make that code do what it appeared to be wanting to, I found 1) it made no difference in practice and 2) when I tried to test with a new hook point rather than a known one, isolation didn't work at all
<vila> 2) is because you didn't register your hook (not hook point)
<mgz> I call install_lazy_hook / the other install method
<mgz> what else needs doing?
<mgz> anyway, apart from some ugliness in the tests, what I'm trying to verify should be pretty clear from the code
<vila> the misunderstandings are because we tend to call hooks what the code calls hook points (except for lazy_hook which tends to blurry the lines even more)
<vila> mgz: have you tried registering your hook ?
<mgz> I... don't know what that would look like
<vila> I take that as a no then ;)
<vila> something like hooks.known_hooks.register_lazy(your_test_module, your_hook, your_hook_class)
<mgz> okay, so how do I isolate *that* to the test...
<vila> hehe
<vila> with a lot of effort ?
<jam> mgz: presumably you'll have 2 levels of TestCase, right?
<jam> the inner one which actually does some trivial thing, asserting it is isolated
<jam> and the outer one as the bzrlib test case
<jam> the bzrlib case can register the hook point
<jam> and the inner one then fiddles with registering a test-spceific callable
<jam> then when the outer one finishes running the inner one, it asserts that everything is cleaned up.
<mgz> yup.
<mgz> the current tests have an inner case that installs and calls a hook
<vila> a hook point
<jam> mgz: why is it "_clear_hooks" and "_restoreHooks" one of those is misrepresented :)
<vila> but don't install the hook in known_hooks
<mgz> installs a hook point and triggers a hook callback
<mgz> ...some name cleanup really would help
<jam> mgz: I use the terms HookPoint and callback
<mgz> then the outer case triggers the hook again, the theory being that the hook callback should then *not* be called
<jam> I think the code is a bit confused as well.
<mgz> anyway, I'd like this isolation code to just be test.overrideAttr(_mod_hooks, "_dict_where_all_hook_callbacks_live", {})
<mgz> but life isn't that simple.
<jam> mgz: so are your tests not failing? or failing too much?
<mgz> yup, both.
<mgz> the lazy one using the lock hooks doesn't fail
<mgz> and the new hook point that doesn't get into known_hooks fails by,
<mgz> never triggering the callback for lazy installation
<mgz> and always triggering the callback for eager installation (ie, doesn't get cleaned up)
<mgz> ...I think I have those two the right way round
<mgz> so, "hooks not in known_hooks are broken" is a fine answer for those two
<mgz> ...would be nice if the code actually asserted that
<mgz> anyway, I think I don't want to rewrite the hooks code, so may just delete the bogus tests and the redundant cleanup and see if anything else breaks
<mgz> okay, I'm off.
<jam> mgz: have a good evening
<vila> argh, the new SSD arrived too late :-( The old one died in flames...
<maxb> literal flames?
<maxb> :-)
<fullermd> Probably.  Somebody sent it too many nasty emails, and it committed suicide.
<gour> am i right that qbzr is more advanced than bzr-gtk and therefore recommended to be used withing explorer?
<gour> i'm familiar with cli using freebsd (and before that linux), but would like to know to recommend right tool for (potential) contributors who are GUI-fans
<jelmer> gour: yeah, qbzr is definitely more advanced and better integrated into bzr-explorer
<gour> jelmer: thank you
<gour> cool, it's possible to convert branch into colbranch :-)
<vila> sigh, lots of lossage, all restored except for babune which I will need to restore from a  3 weeks old backup (of course) and some bits I managed to get back from the ashes
<vila> now to turn the bits into files...
<fullermd> So, that counts as a test failure, right?   8-}
<vila> hehe, thanks, I will end on that, couldn't have dream better ending :)
<vila> bye folks, have fun !
<fullermd> Better hope it's transient, and not repeatable   :p
<EM03> how is performance now of the system?
<lifeless> good
<EM03> i remember it used to be not to good lifeless
<lifeless> EM03: sure, it used to be slowed
<poolie> hi all
#bzr 2011-06-02
<jelmer> hey poolie
<jelmer> hi maxb
<maxb> hello
<poolie> hi jelmer, maxb
<poolie> thanks for the reviews jelmer
<lifeless> jelmer: if you're still aroud
<lifeless> jelmer: can we talk about geoffs patch ?
<jelmer> lifeless: sure
<lifeless> so, he put that patch together based on a description of what I wanted in loggerhead
<lifeless> I'm worried that its being parleyed into a bigger, different change.
<lifeless> I don't think loggerhead should need to know about doing iter_tree_entries etc for the export.
<jelmer> lifeless: I'd prefer to change this to be more flexible for other callers as well if we're going to change it, and both options seem to be roughly equally trivial
<lifeless> jelmer: the implementation you suggested doesn't meet loggerheads needs
<jelmer> lifeless: what's the context?
<lifeless> jelmer: we need a generator
<lifeless> to let us return control to the wsgi framework
<jelmer> lifeless: but you're not actually going to stream the data, just send it all in a bulk at the end?
<lifeless> we are streaming
<jelmer> lifeless: the generator still takes a tarball argument, and adds the data there as well
<lifeless> I would like it if geoffs patch were evaluated directly on its impact on bzrlib: is it sufficiently tested, will it decrease performance, or make things be structured badly.
<lifeless> jelmer: that doesn't matter.
<lifeless> jelmer: loggerheads tarball object is mapped to a file object that accumulates the bytes in a buffer; when each yield occurs the accumulated bytes are handed off to the wsgi stack
<spiv> Good morning.
<mgz> special mailing list post of the day: <http://lists.ironpython.com/pipermail/users-ironpython.com/2011-June/014868.html>
<jelmer> lifeless: that seems more complicated than just iterating over the items and files and writing out item.tobuf() + file.read()
<lifeless> jelmer: that would a) not work with zip files, b) not stream.
<jelmer> lifeless: this function doesn't work with zip files anyway
<lifeless> but the structure will
<jelmer> lifeless: both ways stream per file
<lifeless> shrug
<lifeless> I don't really want to overdesign this
<lifeless> I don't want geoff blocked on something that makes it harder for him or loggerhead
<lifeless> and he is right now
<lifeless> if the design is poor, we should ask him to fix it
<jelmer> anyway, I haven't voted on this, and I don't feel strongly about it. I was just saying it seemed simpler to factor out the body of the loop, rather than creating a generator which makes things more complex imho
<lifeless> but you seem to want to solve different problems
<lifeless> jelmer: it requires a generator
<lifeless> _requires_
<jelmer> that generator can be in loggerhead
<jelmer> and just be a three line loop
<lifeless> jelmer: Well, that won't work for .zip files (which folk will want), because they don't have the same output model
<lifeless> I don't think it makes sense to make the loggerhead code simpler for tarballs at the cost of needing two codepaths in loggerhead for zip/tarballs
<jelmer> IIRC zipfiles in Python don't stream anyway
<lifeless>                 zipf.writestr(zinfo, content)
<lifeless> is the per-file stuff
<lifeless> so, it needs a similar tweak to permit this in loggerhead for zip files
<lifeless> I think writing to the file is simple and clear
<lifeless> we can have the same contract for both generators, both live in bzrlib.export.*, and one driver for adapting them to wsgi streaming
<lifeless> if we have /any/ tar specific code in loggerhead that won't work.
<lifeless> which is what I don't like about your proposal
<lifeless> mgz: win
<lifeless> mgz: I presume you know about the great regex mistake ?
<mgz> I thought you'd appreciate that lifeless :)
<jelmer> lifeless: I don't see how that helps; ZipFile's constructor requires a filename or seekable file object
<lifeless> jelmer: we manage to export to stdout
 * jelmer gets some sleep
<lifeless> jelmer: which is nonrewindable
<jelmer> lifeless: charis:~/src/bzr/bzr.dev% bzr export --format=zip -
<jelmer> bzr: ERROR: [Errno 29] Illegal seek
<lifeless> ah! ok, so bugs to fix there.
<lifeless> still, i think making the contract be tied to tar would be a mistake
<lifeless> sleep well
<mgz> the zipfile module is pretty useless unfortunately
<mgz> it's been multiply threatened with a rewrite that's never arrived
<lifeless> we have/had a fixed copy
<lifeless> bbiab, grocery shopping needs doing
<jelmer> I think one of the problems is that the zip file format requires the compressed/uncompressed sizes to be known up front
<jelmer> anyway, really gone now.. :)
<mgz> hm, really? I thought the header was minimal and everything that mattered was in the tail.
<mgz> hence the gif/zip hacks.
<jelmer> yeah, you're right
<jelmer> wikipedia confused me because it still calls them headers
<mgz> beheaded headers
<mgz> they're severed and placed in a basket at the end
<gour> i'm converting all my old repos to bzr and while doing it i just wanted to put one old project under bzr (no conversion from some other DVCS), but bzr failed with: http://pastebin.com/Jtt4HtAP
<gour> i've found it as https://bugs.launchpad.net/bzr-diffstat/+bug/56680
<ubot5> Ubuntu bug 56680 in Bazaar Diffstat Plugin "uncaught exception: bzr: ERROR: exceptions.UnicodeDecodeError:" [High,Confirmed]
<gour> and it's more than 4yrs ago since it's reported...it would be cool to fix it before 2.4
<gour> another one is https://bugs.launchpad.net/bzr-submit/+bug/67973
<ubot5> Ubuntu bug 67973 in Bazaar Submit By Mail Plugin "exceptions.UnicodeDecodeError" [Medium,Fix committed]
<gour> the most recent activity in regard to this problem seems to be https://bugs.launchpad.net/bzr-explorer/+bug/735349
<ubot5> Ubuntu bug 735349 in Bazaar Explorer "UnicodeError while converting BzrError to unicode" [High,Confirmed]
<AuroraBorealis> does anyone know if launchpad will be getting a wiki?
<AuroraBorealis> cause ive been contributing to a project on github and its a much nicer site :<
<gour> AuroraBorealis: there is discussiion about it atm
<AuroraBorealis> hmm
<gour> AuroraBorealis: check https://bugs.launchpad.net/launchpad/+bug/240067
<ubot5> Ubuntu bug 240067 in Launchpad itself "Launchpad projects need wikis" [Low,In progress]
<AuroraBorealis> i think its a bit more then low priority =/
<spiv> AuroraBorealis: note that that the 'launchpad' project only really uses Critical, High, and Low.  https://dev.launchpad.net/BugTriage#Importance
<gour> this is certainly one of the features i really miss in LP, but i prefer bzr much more than git
<gour> ..which i simply cannot stand
<gour> i even use bzr-git for fetching github projects
<thumper> AuroraBorealis: low means it isn't being worked on by lp devs
<AuroraBorealis> i see
<thumper> AuroraBorealis: I'd like to see LP get a wiki...
<thumper> but I keep spending time writing other stuff
<thumper> perhaps I'll instigate my own 20% time
<AuroraBorealis> cause my projects on launchpad just seem confusing compared to github
<spiv> I'm not sure adding a large complex feature to Launchpad will automatically reduce that confusion :)
<spiv> I agree a wiki for projects would be nice.
<AuroraBorealis> i feel the entire website needs to be revamped hehe
<AuroraBorealis> but a wiki just seems like another tab
<AuroraBorealis> also i'm confused on the little history graph things launchpad branches have
<AuroraBorealis> https://launchpad.net/inkscape for example, does it go up then right?
<spiv> AuroraBorealis: does the larger view at https://launchpad.net/inkscape/+series make it clearer?
<AuroraBorealis> so it seems like 'trunk' is the vertical line
<AuroraBorealis> and they keep branching off
<spiv> Or for comparison, https://launchpad.net/bzr/+series
<AuroraBorealis> but am i right that it seems the main trunk branch is on the left?
<spiv> The bzr example is a bit more interesting perhaps because you can see the dates of releases from different series overlapping.
<spiv> It's not a graph of branches or revision history.
<AuroraBorealis> so its just a graph of versions?
<AuroraBorealis> or 'series'
<spiv> It's a visualisation of release series and their milestones.
<AuroraBorealis> ah. k
<AuroraBorealis> so i take it launchpad doesn't have a graph of revisions
<spiv> Someone really ought to integrate one into loggerhead.  You can browse the revision history by following the âBrowse the codeâ link on e.g. https://launchpad.net/inkscape
<spiv> It doesn't yet do the sorts of pretty graphs you get with bzr GUIs like 'bzr qlog', but I'm sure someone will do one for it eventually.
<AuroraBorealis> which take like 5 clicks to get to
<spiv> Which do?
<AuroraBorealis> to get to the link to 'view all revisions' hehe
<AuroraBorealis> and yeah i was just using github to contribute to some project and i liked their revision graph
<spiv> I count 2 clicks.
<spiv> From https://launchpad.net/inkscape click âBrowse the codeâ, from there click âview branch changesâ
<AuroraBorealis> ah that. i clicked code at the top
<spiv> Yes, it's a nice graph.  Fortunately you can get the same thing in a local GUI via 'bzr qlog' (qbzr plugin) or 'bzr viz' (bzr-gtk plugin).
<AuroraBorealis> yeah i use bzr explorer which i think has qlog in there
<AuroraBorealis> https://github.com/sr/git-wiki/network is sweet :>
<spiv> Which isn't quite as convenient as having it in a web page, but it's good enough for me at least.
<AuroraBorealis> yeah
<AuroraBorealis> geez branching the bzr source is taking forever xD
<spiv> Have you done "bzr lp-login"?
<AuroraBorealis> i have not
<AuroraBorealis> is that why its taking forever?
<thumper> AuroraBorealis: yes
<thumper> AuroraBorealis: it'll be going over http
<thumper> AuroraBorealis: instead of the bzr+ssh protocol
<AuroraBorealis> doh
<AuroraBorealis> well i'll do that after it finishes
<AuroraBorealis> does it not need my password?
<thumper> AuroraBorealis: it needs an ssh key on LP
<AuroraBorealis> yeah i have that
<thumper> then you're good
<AuroraBorealis> but i just typed launchpad-login <username> and it didnt output anything
<aurora|game> it seems to be working. thanks =)
<gour> aurora|game: have you tried github's bug tracker?
 * gour grins :-)
<AuroraBorealis_> sorry gour , no i have not, is it crappy?
<gour> AuroraBorealis_: i'd say, yes
<gour> it cannot compare with LP's features
<AuroraBorealis_> haha
<AuroraBorealis_> cool.
<AuroraBorealis_> im just experimenting with a lot of stuff. I like bzr cuase i can host my private code (stuff for school) on my own server and stuff
<gour> AuroraBorealis_: i used darcs for many years, tried hg, touched git, played with monotone and recently used fossil, but now i'm moving to bzr which is simply the most intuitive & complete dvcs ("..for human being.")
<AuroraBorealis_> hehe
<AuroraBorealis_> yeah, i like it
<AuroraBorealis_> plus its python, git seems to be very linux centric.
<gour> darcs was(is) great tool, but it does not have LP or any similar, even less featured, public hosting solution
<AuroraBorealis_> never heard of darcs
<gour> git looks to me as a big hack, without real design behind it...monotone is nicely designed, but it's niche
<AuroraBorealis_> i installed git
<AuroraBorealis_> and it installed a shitty ssh.exe to my path which screwed up bazaar
<gour> AuroraBorealis_: http://darcs.net/ it has patch theory and it's quite different and very intuitive
<gour> bzr is 'sweet spot'
<AuroraBorealis_> yeah =)
<jelmer> gour: still there?
<jelmer> gour: those two bugs you mentioned are unrelated to the issue you're seeing
<gour> jelmer: yeah, i'm here
<gour> hmm
<gour> last one is relevant?
<jelmer> gour: they're indeed UnicodeDecodeError tracebacks too, but raised from a different location
<jelmer> gour: the bzr-explorer one?
<gour> yes
<gour> so, it looks all are from different locations, but same symptoms
 * gour was pointed at the right one - https://bugs.launchpad.net/bzr-explorer/+bug/735349
<ubot5> Ubuntu bug 735349 in Bazaar Explorer "UnicodeError while converting BzrError to unicode" [High,Confirmed]
<gour> ahh...wrong one
<gour> this one is correct: https://bugs.launchpad.net/bzr/+bug/715547
<ubot5> Ubuntu bug 715547 in Bazaar ""bzr add" crashed ERROR: exceptions.UnicodeDecodeError" [Medium,Confirmed]
<spiv> maxb: around?
<jelmer> 'morning spiv
<spiv> Good evening jelmer :)
<gour> seeing that SF has support for web pages and wiki, i wonder what do you think about LP vs SF for hosting projects under bzr?
<spiv> Depends on what your project needs.  You can always use both of course!
<spiv> I find the SF bug tracker to be much, much worse than LP's.
<gour> problem is that LP does not have neither space for web page nor wiki
<fullermd> Not only that, it doesn't even provide CVS.
<spiv> Sure.
<gour> i do not worry for lack of CVS :-)
<spiv> It is an issue for many projects.  Some are small enough that a link in the project description to the contents of the README file in bzr is plenty, and some are large enough that they have their own website anyway.  But there's a big set of stuff in between those that want that sort of feature, and LP doesn't yet cater well to that.
<gour> but LP is the only one from {github,bitbucket, google,sf,lp} missing wikis
<spiv> Sure.  We know.
<spiv> Pretty much everyone thinks LP should have them too, including the LP dev team I think :)
<gour> and the 'bug' is quite old already
<spiv> Right.  The paid LP devs are already pretty busy with other work: <https://dev.launchpad.net/RoadMap>
<spiv> But if someone were to help write the necessary bits I'm sure it'd be welcomed!
<gour> lack of wiki is turning many people to 'competition' which is sad
<spiv> It would be nice to have, but getting free or cheap webhosting elsewhere for those bits isn't too hard, so I understand why it isn't an urgent priority for the LP team.
<spiv> Is it?
<gour> i believe it is...having code on one site, tracker on another, wiki on the 3rd...not pretty
<gour> considering that other hostings have all-in-one
<gour> {github,bitbucket, google,sf} probably support wiki with a good reason ;)
<lifeless> wiki != webhosting fwiw
<gour> lifeless: i'd be satisfied with just having wiki on LP
<lifeless> well, its getting specced at the moment
<lifeless> its still ill defined what that actually means
<gour> even just to render sphinx-generated pages
<gour> lifeless: why don't you inspect what's offered at {github,bitbucket, google,sf} instead of reinventing the wheel
<lifeless> gour: uhm, we have and are?
<spiv> gour: what makes you think that's not happening?
<lifeless> gour: they all have quite different offerings
<lifeless> gour: and none of those commercial, proprietary services have been kind enough to share their user and market needs analysis with us.
<gour> the point is the many people/projects would like to have wiki, that's why {github,bitbucket, google,sf}  have it...it's only question to adjust to the LP
<gour> here i'd say that "even blind uncle" applies
<spiv> gour: if it's that easy, then please go ahead and do it!
<spiv> gour: it's open source, and patches are certainly welcome.
<gour> it's not that the rest of LP is perfect in the 1.0 release
<gour> spiv: i do not have neither required skills nor time to work on it...wikkid is a project launched for that purpose, afaik
<spiv> gour: Ok.  Apparently no-one else has had the skills and time yet either, though.
 * gour is thankful to have free LP, but lack of wiki might move me to SF
<spiv> Which, as one of those people who also lacks the time, I completely understand!
<gour> spiv: pls. don't think i am criticizing LP...just want to improve it...because, let's face it - less LP customers also means less bzr ones
<lifeless> gour: we want it, but we want it done well. Getting a free wiki with links to it from LP is -dead- easy - heck we even model links to the wiki in LP today.
<fullermd> I note that when I put a project on SF, I don't think it had any wiki support.  And I think it's had 3 different wiki generations since then.
<gour> i strongly believe github is not popular just because of git
<spiv> gour: I agree, github does many things quite well
<gour> fullermd: how are you satisfied with SF & bzr?
<fullermd> Well, I've never yet used bzr on SF.  My project there is in CVS   :p
<lifeless> we're not short on desire, we're short on elbow grease; doing a system that will run 20K wikis with no page renders over 5 seconds and 99% under 1 second, no single points of failure and embeddable in the same domain [so entirely xss free] is -nontrivial-
<maxb> spiv: Now I am
<fullermd> Their docs on bzr aren't seemingly maintained at all.  Last I looked, they still said they support bzr 1.10, when it was easy to tell they were running 2.1 or 2.2.
<spiv> maxb: oh hey, I was just having a temporary thinko with the kde-l10n-* command
<spiv> maxb: it's requeued now, although I see kde-l10n-th has developed a new and interesting failure
<spiv> Perhaps an empty bzrdir on LP or something as a remnant of the previous failures?
 * maxb looks at kde-l10n-th and thinks "WTF!?"
<gour> according to wikipedia, github was launched in feb 2008, and wiki 'bug' at LP is from june same year
<spiv> maxb: previous line in log is about opening the working tree for kde-l10n-th/karmic-backports
<lifeless> gour: yes, the desire has been around a while
<spiv> gour: I'm really not sure what your point is?  LP does many things github doesn't, like PPAs
<spiv> gour: because while they may have overlapping goals, they also have differing ones too, and accordingly differing priorities.
<gour> spiv: aren't PPAs rlevant only for Ubuntu?
<spiv> gour: they're pretty relevant to where the LP dev spend their time as well :)
<gour> spiv: maybe only to change priority from Low :-)
<spiv> gour: see https://dev.launchpad.net/BugTriage#Importance
<lifeless> gour: low is accurate: we're not going to try and make this happen using paid developers in the next 6 months. And as priorities change, we don't try and assess priorities more than 6 months out.
<gour> spiv: Low - We mark as Low any bug that we recognise as legitimate but that we have no plans to fix.
<spiv> gour: right â and the paid LP team doesn't plan more than 6 months in advance.
<spiv> (Not in this sense, at least)
<lifeless> hmm, I think thats confusing
<lifeless> so I will edit
<gour> and it's already 3years...the whole point, and here i can stop from my side, is that lack of wiki at LP causes harm to the LP & bzr since people/projects needing one go to {bb,github.sf, google}...
 * gour is researching about SF now...
<spiv> gour: sure, but so do all the other bugs and missing features of LP
<spiv> gour: and so far it's been the opinion that those are even more important to address using the finite resources available
<spiv> Your opinion is obviously different, but stating it here isn't going to change matters.
<gour> one of the first hits - http://amanica.blogspot.com/2011/05/bazaar-on-sourceforgenet.html
<gour> spiv: i'm aware of it and won't discuss it any longer
<spiv> You could try to advocate for it on the launchpad-dev list perhaps.  If you present evidence that it really is a huge factor in driving potential users away that would be useful I think.
<spiv> maxb: those kde-l10n-* are failing due to branches on LP that are just empty directories, not even a .bzr dir.  I guess we try deleting them from LP and requeuing.
<EM03> why bzr over git?
<EM03> git is faster? I mean whats a killer feature?
<spiv> Many people find it nicer to use.
<EM03> an example?
<Riddell> poolie: I still can't access jubany, what's the rt URL to complain on?
<gour> EM03: git help log vs. bzr help log ;)
<EM03> hehehe
<EM03> i know git very well and its quick just curious why one would choose bzr
<gour> "it's for human being"
<EM03> can i have an example were thats true?
<EM03> (not saying it isn't)
<gour> i'm spoild by darcs ui, and bzr is quite pleasant to use...with git one has to think too much about the tool
<gour> git's ui, model...
<gour> EM03: have you tried monotone?
<gour> e.g. i tried to become power user of orgmode, but it required too much time...otoh, taskwarrior was so intuitive...same with git vs. bzr
<gour> EM03: otoh, if you like git, be free to continue with it ;)
<maxb> spiv: Right - if only all the failures were that easy :-)
<EM03> gour: not that I'm in love with it just want to see se bzr is better :P
<gour> EM03: just try to use it for some time and don't think that some extra ms are worth the effort to think how to avoid shooting one's own feet ;)
<EM03> oh gour , you make it sound so easy
<gour> EM03: on which platform you are?
<gour> EM03: http://doc.bazaar.canonical.com/bzr.dev/en/mini-tutorial/index.html
<gour> and http://doc.bazaar.canonical.com/bzr.dev/en/tutorials/tutorial.html
 * gour was playing with bzr when changing the format was the rule :_)
<spiv> maxb: still failing; but updated
<spiv> s/but/bug/
<maxb> "There is already a branch merge proposal registered for branch lp:~ubuntu-branches/ubuntu/hardy/kde-l10n-th/hardy-201106020937 to land on lp:ubuntu/hardy/kde-l10n-th that is still active."
<jelmer> gour: we still seem to have that image, while in fact the last change of the default format was quite some time ago (2 years?)
<gour> jelmer: yeah, labelling is hard..just ask lightttpd guy about memory leaks
<gour> *guys
<fullermd> Funnily enough, every time I use monotone, I get another round of "sorry, I can't do anything until you 'mtn db migrate' to update the database structure".
<gour> i'm also tired about git's tspeed-talk as it's the only relevant feature of dvcs
<maxb> tspeed-talk?
<gour> speed-talk
<gour> fullermd: heh, foosil borrowed some stuff from mtn
<gour> *fossil
<maxb> Well, in fairness to git, there are some applications where I'd rather use bzr, but am compelled to use git for the performance
 * gour cannot type properly... :-/
<lifeless> maxb: you know jam will fix those :)
 * gour does not work on kernel-sized projects ==> no need for git
 * maxb is keeping the revprops tree of a Subversion repository with >1 million revisions in Git
<maxb> bzr doesn't really like a tree with >1 million files and 1.9GB in size
<lifeless> maxb: hmmm, it should handle it
<lifeless> maxb: the dirstate would be sizable
<maxb> It probably can handle it, but not quickly enough to be palatable for a human user
<maxb> Even git is far from instantaneous on a tree that size
<lifeless> sure
<lifeless> file a bug ?
<lifeless> gnight all
<maxb> A bug on "Performance on big trees does not compare favourably to Git" feels a bit like bug
<maxb> A bug on "Performance on big trees does not compare favourably to Git" feels a bit like bug 1
<ubot5> Launchpad bug 1 in Ubuntu "Microsoft has a majority market share" [Critical,In progress] https://launchpad.net/bugs/1
<maxb> jelmer: You seem to have push --overwritten me in pkg-bazaar/bzr/2.4 :-/
<lifeless> maxb: 'bzr takes 60 seconds to st a 1M file tree with hot cache'
<lifeless> maxb: you don't need to say git in there at all
<maxb> fair enough
<jelmer> maxb: Yeah, sorry about that - I'd already done the merge locally too, with some additional changes and there weren't any other changes than the merge
<jelmer> I tried merging your branch, but I got conflicts on the generated files so I opted to --overwrite instead
<maxb> Unfortunately those revisions are already merged into the beta-ppa branches
<maxb> I guess I'll sort out a merge
<jelmer> maxb: sorry, I hadn't realized it was there as well
<deni> hi guys
<deni> can anyone tell me how to start the freaking olive gui? i installed bzr-gtk which should be the package for olive
<maxb> Not any more. Olive has been split from bzr-gtk and is now a wholly separate project
<deni> maxb: can i find it debain repos?
<maxb> I am uncertain whether it has been packaged
<maxb> I'd search on the BTS, but bugs.debian.org seems to be down right now
<jelmer> I'm pretty sure it's not packaged
<maxb> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=598703
<ubot5> Debian bug 598703 in wnpp "RFP: olive-gtk -- Graphical frontend for Bazaar" [Wishlist,Open]
<deni> on the main page it says i can install it via leeny-backports
<deni> i tried to install bzr via squeeze backport and i don't think it installed any gui frontends
<jelmer> deni: it should install a olive-gtk executable in /usr/bin
<deni> jelmer: nope
<deni> also it can't find it in the repos
<jelmer> deni: it's there, see http://packages.debian.org/lenny/all/bzr-gtk/filelist
<deni> i hva the bzr-gtk package
<deni> ]don't know how to start that though
<deni> autocomplete says there is no olive or bzr-gtk app
<jelmer> deni: it's not in squeeze, you need the lenny package
<deni> jelmer: still not luck
<deni> meh
<deni> will try tomorrow
<deni> thank for your help
<jelmer> deni: see that page, it's definitely there in the lenny package
<deni> jelmer: ok, tnx
<jelmer> deni: that said, I'm not sure if it will work with newer versions of bzr, for example
<jelmer> you might have more luck just pulling down the source from lp:olive
<Riddell> jam: able to take another (hopefully final) look at https://code.launchpad.net/~jr/bzr/598572-zlib-error/+merge/62966 and https://code.launchpad.net/~jr/bzr/707274-commit-message-hook/+merge/62334 ?
<jelmer> hi Riddell
<jelmer> Riddell: It's ascension day here in .nl, IIRC John is away for the next couple of days
<Riddell> ah, religion leaving us without a patch pilot
<ovnicraft> hello i am testing a bzr oodifff plugin i get this error: http://pastie.org/2009130
<ovnicraft> i cant fixed so i see is based in bzr api
<ovnicraft> any hits to fixed ?
<ovnicraft> fix it ?
<ovnicraft> its in your doc http://doc.bazaar.canonical.com/plugins/en/oodiff.html
<jelmer> Riddell: reviewed the zlib error MP
<jelmer> ovnicraft: hi
<ovnicraft> jelmer, hi
<ovnicraft> i see in that plugin is trying to use get_default_plugin_path()
<ovnicraft> jelmer, can you help me  ?
<Riddell> jelmer_: what does it mean if you approve it in your review but the status is still Needs review?
<maxb> Usually means the reviewer forgot that LP's review model has that distinction :-)
<jelmer_> Riddell: what Max says, it means I'm stupid :)
<Riddell> groovy, I'll self approve
<ovnicraft> hello i have this error with my oodiff plugin http://pastie.org/2009303
<ovnicraft> bzr needs any explicit configuration with ASCII ?
<jelmer> ovnicraft: that looks like a bug in the plugin
<jelmer> ovnicraft: please file a bug against the bzr-oodiff project
<jelmer> hmm, it doesn't appear to have been touched since 2009 :-/
<ovnicraft> jelmer, yes
<jelmer> Riddell: ooh, that builddeb hook is neat
<ovnicraft> and i want to support it
<ovnicraft> jelmer, method implemented is working now
<ovnicraft> jelmer, you can see the method http://paste.pocoo.org/show/399537/
<jelmer> ovnicraft: I think you need to pass in plain strings to the diff function
<jelmer> the XML document probably contains unicode strings, which you'd have to encode (to utf-8, perhaps?)
<ovnicraft> so i need encode to utf-8 my files ?
<jelmer> no, in bzr-oodiff before you call text_differ(), you need to encode the strings you pass to it
<jelmer> from_text = [l.encode("utf-8") for l in from_text]
<ovnicraft> so with utf-8 files encoded is working ok
<jelmer> cool :)
<ovnicraft> now will apply your changes and see waht happen
<ovnicraft> what*
<dcoles> Hm. Here's a bit of a worrying one. Should bzr-svn ever eat a svn revision.
<dcoles> As in running svn log on trunk shows the revision yet bzr log doesn't.
<jelmer> dcoles: there's an open bug report about that - it's fixed in zbr-svn trunk
<jelmer> at least, if I think it's the issue I think you mean
<dcoles> Basically the svn revision appears invisible to bzr-svn (I can't -rsvn:# it)
<dcoles> It resulted in a rather interesting "Why did you revert my change. I didn't revert anything. You never made that change" *grin*
<dcoles> I'll try trunk.
<jelmer> dcoles: it's a race condition
<jelmer> dcoles: upgrading to trunk won't fix the earlier revision, but it will prevent the race in the future
<dcoles> Was that lp:515850
<dcoles> Bug #515850
<ubot5> Launchpad bug 515850 in Bazaar Subversion Plugin "Revisions added while a commit is happening are ignored" [High,Fix committed] https://launchpad.net/bugs/515850
<jelmer> yep
<jjohansen> I have been trying to setup a git clone of a bzr tree and have run into a problem.  Basically the tree has some tags with ~ in the name which git doesn't like
<jjohansen> is there any way to work around this?
<rattasak> Hi, I just started using bazaar and believe i am misunderstanding something about shared repositories.  i have a project with code files in ~/projectA.  i create a repo on a mapped network drive by using 'bzr init-repository --trees /drive/repo' and then create an branch for the project i want to track in the repo using 'bzr init /drive/repo/projectA'
<maxb> jelmer: https://code.launchpad.net/~dulwich/dulwich/unstable mirroring has stopped due to the failure of alioth. Could you update the URL to include a /bzr/ path segment and restart it?
<rattasak> i then do 'bzr checkout /drive/projectA projectA'
<rattasak> add and commit the files in that working directory using bzr add and bzr commit
<rattasak> but when i check the repo at /drive/repo, i don't see a working tree there
<maxb> Ok, so a couple of things
<maxb> First, why would you even want a working tree on a shared drive?
<maxb> Second, the act of sending revisions to a remote branch does not cause its working tree to be updated.
<rattasak> ah, reliability of the network drive is a slight issue atm so i would like to have a working copy there in case the history files get corrupted during the push (which is something i'll fix with the network drive soon and is not ideal)
<rattasak> ah
<rattasak> doing a commit locally on something that was checkouted does a puch to the corresponding remote branch right?
<rattasak> push*
<maxb> Yes
<rattasak> i see
<rattasak> is there a set of conditions or a command to explicitly update the remote working tree?
<maxb> "bzr update"
<maxb> https://launchpad.net/bzr-push-and-update may be of interest to you
<lifeless> (run on the remote machine)
<maxb> Although I'm not sure it will work with a checkout, from its description
<rattasak> aaah gotcha, bzr update within the repo's working tree then (e.g. /drive/repo/projectA)?
<maxb> Yes
<rattasak> aah great!  just tried it out.
<rattasak> thanks for both of your guys help
<maxb> Although, as a backup methodology, I think you would be better off setting up an automatically updated copy of the *branch* elsewhere
<rattasak> ah i see
<rattasak> maybe do a sync instead of the local working directory?
<rattasak> sync with an external program i mean
<maxb> It is usually a lot better to use "bzr push" or "bzr pull" than an external program
<maxb> You cannot guarantee that an external program will do the right thing if the source is being written to
<rattasak> push to a standalone branch stored elsewhere?  (if standalone branch means something not stored within a repo...i am migrating from hg so my terminology is a little mixed up)
<maxb> Yes (and yes, that's what a standalone branch is)
<rattasak> ah ok.  thanks for your help clearing that up for me.
<poolie> hi all
#bzr 2011-06-03
<jelmer> maxb: dÃ¸ne
<maxb> thanks
<poolie> lifeless: hi, re your comments on the export patch
<poolie> is a do-nothing generator really the cleanest thing?
<poolie> jelmer: ^
<jelmer> hi lifeless, poolie
<poolie> this seems redundant with observing the exporter writing to the file object
<lifeless> wsgi needs a yield in there
<poolie> it must pull rather than being pushed to?
<lifeless> yeah
<poolie> ok, not quite
<poolie> there is a write function you can use
<poolie> which is what i was remembering
<poolie> but it's deprecated
<spiv> Good morning.
<lifeless> poolie: so you're ok with the approach I suggested?
<poolie> it seems a bit ugly
<poolie> would be better to actually generate the bytes or something
<poolie> but i suppose if you're writing to a local file, it is better to have them written directly
<lifeless> its complex generating the bytes:
<lifeless>  - first you need the archive layer to put them together
<lifeless>  - then pass into the compression layer (when its separate)
<lifeless>  - then flush that (which most/all compressors do by pushing through write)
<lifeless>  - and finally pull that out of a buffer to yield it
<poolie> right
<jjohansen> is there a way to get bzr-fastimport to do character mapping to do tag name translation
<jelmer> jjohansen: hi
* spiv changed the topic of #bzr to: Bazaar version control <http://bazaar.canonical.com> | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: jam | UDD failure ratchet: 484
<jelmer> jjohansen: not at the moment
<poolie> hi spiv
<jjohansen> jelmer: thanks
<poolie> the failure rate went down?
<poolie> lifeless: otoh this will buffer up whole files
<lifeless> poolie: yes
<lifeless> poolie: however once we emit our first set of bytes haproxy and apache will become happy
<poolie> it will avoid them thinking we've died
<lifeless> poolie: also, this provide an abstraction layer
<lifeless> bzrlib could change this to a threaded implementation
<lifeless> and yield multiple times in a big file
<spiv> poolie: yes, https://bugs.launchpad.net/udd/+bug/790733 resolved.
<lifeless> and loggerhead wouldn't need to change
<ubot5> Ubuntu bug 790733 in Ubuntu Distributed Development "Manually clear stale imports on jubany - due to failure whilst filing merge proposals" [Undecided,Fix released]
<poolie> oh thanks
<jelmer> lifeless: the existing patch doesn't make an abstraction layer possible though, as it still requires a tarfile object to be passed in
<poolie> there are a few others from max, you probably saw
<lifeless> jelmer: I think geoff has updated it
<lifeless> jelmer: I wanted him to do the public api at a slightly higher level
<jelmer> l
<jelmer> lifeless: there's also some overlap with the existing abstraction layer for exporting to files
<maxb> jelmer: Your git and bzr trunks of dulwich appear to have diverged?
<jelmer> lifeless: that's not to say I don't like the idea of an abstraction layer for exporting to streams, but it'd be nice to avoid duplicating all that code
<lifeless> jelmer: the reason I asked him to patch bzrlib was to avoid duplication
<lifeless> jelmer: I haven't re-read his patch yet
<poolie> so there's going to be higher-level code that, each time the generator yields, sucks out the file object and sends it back to wsgi?
<poolie> in loggerhead, taht is
<lifeless> loggerhead will have a file object that acts as a buffer
<lifeless> it will pass that file object into bzrlib along with the tree to export etc
<lifeless> and then on each yield handoff to wsgi
<jelmer> it seems like that sort of code would be nice to have in bzrlib too - so it can be used when e.g. streaming to stdout
<poolie> so it will pass something like a stringio?
<poolie> and then do yield buf.getvalue()
<lifeless> a list of bytes
<lifeless> but yes
<poolie> hm
<lifeless> there is a patch up on loggerhead with his original code
<poolie> it does seem a bit like we're reimplementing something that already exists in wsgi or paste
<spiv> maxb: hmm, looks like kde-l10n-tg and bittorrent may be the same issue
<lifeless> poolie: possibly.
<poolie> do we know who blackbug-nx is?
* maxb changed the topic of #bzr to: Bazaar version control <http://bazaar.canonical.com> | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: jam | UDD failure ratchet: 483
<spiv> Hmm, I think 'bzr upgrade' is broken for upgrading stacked-on shared repositories
<spiv> Because it tries find_branches which tries to open a branch which is stacked on a different format, which is why I'm running upgrade in the first place
<spiv> The other question though is why is e.g. lp:~ubuntu-branches/ubuntu/natty/bittorrent/natty a shared repo?
<maxb> That's... interesting
<spiv> Heh, and pushing to ~ubuntu-branches/ubuntu/gutsy/bittorrent/gutsy-proposed warns me it won't update its working tree!
<spiv> I guess some of these old branches were copied via directly sftp'ing up the local files and directories rather than pushing.
<spiv> Ok, looks like I've got the bittorrent package import doing real work now.
<lifeless> poolie: thanks for reviewing xaavs thing so clearly
* spiv changed the topic of #bzr to: Bazaar version control <http://bazaar.canonical.com> | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: jam | UDD failure ratchet: 482
<poolie> lifeless: oh are you talking about the little tags?or the review itself?
<lifeless> both
<poolie> thanks :)
 * maxb is working on the residual weirdness of the rxtx import from the bzr sprint
<poolie> should we let this blackbug guy into ~udd?
<poolie> i'm guessing no, because it would allow merging to the package importer branch
<spiv> It's not like udd needs more bugs either ;)
<spiv> What do they want to do that requires membership of ~udd?
<poolie> i don't know
<poolie> this is a persistent problem with moderated teams
<lifeless> Decline with a message asking.
<poolie> yes
<poolie> i filed https://bugs.launchpad.net/launchpad/+bug/792155
<ubot5> Ubuntu bug 792155 in Launchpad itself "hard to understand what effect approving a membership will have" [Undecided,New]
<poolie> probably a dupe of a six year old mpt bug
<lifeless> I think its new actually
<lifeless> strongly related to some other things
<poolie> yes
<poolie> istm there could be a pretty cheap page that just lists every privilege of the team
<poolie> or even just _some_ privileges "and more" would be a start
<poolie> like: "it has a ppa"
<lifeless> mm
<lifeless> its a transitive thing
<lifeless> it can scale poorly
<lifeless> but yes, it should be done
<poolie> uh
<poolie> knew you were going to say that :)
<poolie> cheap to write; perhaps not easily cheap to compute
<poolie> which almost implies not cheap to write :)
<poolie> but even if you said "plus, all the privileges of _link_ _link_ ..."
<lifeless> one of the problems is that 'has privilege' is turing complete
<lifeless> it would be good to fix that
<poolie> indeed
<poolie> i think listing just some of them, the ones that are cheap,
<poolie> would let me quickly say "no, i'm not letting random people commit to that branch"
<poolie> what is the answer to this? https://answers.launchpad.net/bzr/+question/160044
<spiv> poolie: first I'd need to figure out what the question is!
<dcoles> Sounds almost like he's talking about multiple repositories in one directory.
<dcoles> Rather than two branches from the same project.
<spiv> I'm not sure it is actually a question.  It reads more like a blog post about an idea that occurred to the author.
<dcoles> But yes. I kind of agree. Sounds like they wanted to give feedback on the colocated branches spec and used the Answers system to do it.
<poolie> i agree
<poolie> spiv, re bug 792193, it seems like the 500 should be an lp bug
<ubot5> Launchpad bug 792193 in Ubuntu Distributed Development "'linux' import fails due to deleted librarian file (orig.tar.gz) in .dsc for 2.6.24-5.9 in hardy" [Undecided,In progress] https://launchpad.net/bugs/792193
<spiv> Yes.  It'd be noticed by the OOPS reports I guess?  It does generate an OOPS code.
<poolie> oh maybe
<poolie> i believe the practice is to file one anyhow
<spiv> I'd imagine it's not too hard for them to fix that 500 to be a 404
<spiv> Or maybe 410 Gone?
<poolie> yes, let's protect http status biodiversity
<spiv> :)
<poolie> if it knows it used to exist i think Gone would be good
 * spiv files
<spiv> wgrant: you maybe know this: where, if anywhere, would I be able to find the conflicting version of linux_2.6.24.orig.tar.gz from https://bugs.launchpad.net/launchpad/+bug/663562 ?
<ubot5> Ubuntu bug 663562 in Launchpad itself "duplicate orig for "linux" package in hardy" [High,Fix released]
<wgrant> spiv: We swore that that file would never see the light of day again.
<spiv> Yes, I can imagine :)
<spiv> It leaves the package importer in a bit of a quandry though
<wgrant> I think we may have deleted it.
<wgrant> But let me see.
<wgrant> Oh?
<spiv> Because it wants to turn that package version into a revision
<spiv> And it can't because it can't find the source for it.
<wgrant> spiv: Both are still there. Do you know the md5/sha1 of the one you need?
<wgrant> b7b63f52551f9e4bf2e5ba902f8385fbefc5d80c is the purged sha1.
<spiv> Yes, f09806748f6809d5f7d2a1859240e1a5, a.k.a. not the one currently published
<wgrant> I presume that's it.
<spiv> (that's an md5, obviously)
<wgrant> Right, that one.
<spiv> Well, I can sneak it onto a directory on jubany where the importer will find it
<wgrant> http://launchpadlibrarian.net/11930615/linux_2.6.24.orig.tar.gz, but don't tell the kernel or security teams.
<spiv> Thanks!  I won't :)
<wgrant> Or they will find a way to sneak it into the primary archive and destroy a few days again.
<spiv> (And I'm glad to see the original bug that allowed it in the first place is fixed)
 * spiv hmms
<wgrant> It gave us a very unpleasant couple of days, so yes, it was fixed :)
<spiv> The importer understandably doesn't really expect this scenario, so I made need to do some hackery beyond just putting that file thereâ¦
<spiv> But this is a good start, thanks!
<wgrant> Yeah.
<spiv> (if it finds it has the right filename but wrong md5 it just shrugs and redownloads, but that means it's likely to overwrite the manually downloaded copy in its cache.  we'll see how I go.)
<spiv> Once we get past this tricky revision we hopefully never need to care about this situation again.
<glob> is it possible to set a 'related branch' on an existing branch?
<spiv> glob: probably, what do you mean by ârelated branchâ though?  Something that appears in the âRelated branches:â section of 'bzr info' output?
<glob> spiv, yes; i am talking about the 'related branches' section of bzr info
<spiv> So you can set any of those locations via 'bzr config' (except perhaps âstacked onâ, but you can use 'bzr reconfigure' for that one).
<glob> spiv, ah, thanks :)
<spiv> But there's a fixed set of relationships there, just public, parent, push, submit and stacked-on.
<spiv> (Most of those can also be updated by using --remember with the appropriate command, e.g. bzr push --remember NEW_LOCATION)
<spiv> Goodness, I think I really have convinced the package import of 'linux' to make more progress
<glob> spiv, are those config changes local only?  can i make them the default for anyone else who checks out the branch?
<spiv> If you set them on the branch (bzr config --scope=branch, or by editing .bzr/branch/branch.conf by hand), then yes they'll be the default for other people.
<glob> excellent, you have been a wealth of knowledge, thanks :)
<spiv> (Well, the stacked on location won't be, but again it's a bit special)
 * glob is setting submit_branch
* spiv changed the topic of #bzr to: Bazaar version control <http://bazaar.canonical.com> | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: jam | UDD failure ratchet: 481
<poolie> jam: don't suppose you're here yet?
<maxb> So, since people are busily UDD-ing, what do you think of my either-or on bug 708655 ?
<ubot5> Launchpad bug 708655 in Ubuntu Distributed Development "sysvinit package import failing" [Undecided,New] https://launchpad.net/bugs/708655
<poolie> oops
<poolie> i actually did the deletion and requeeu
<poolie> oh, actually only the deletion
<poolie> will do the other part now
<spiv> maxb: have you seen my latest comments on https://bugs.launchpad.net/udd/+bug/792193 ?
<ubot5> Ubuntu bug 792193 in Ubuntu Distributed Development "'linux' import fails due to deleted librarian file (orig.tar.gz) in .dsc for 2.6.24-5.9 in hardy" [Undecided,In progress]
<maxb> um
<maxb> Thorny problem. I don't have an answer without studying the code for a while
<spiv> I'm getting close to the end of my day (and week!) but if you can help me understand the impact of that situation that'd be lovely
<poolie> good morning vila
<spiv> Ah, that'll do for now :)
<poolie> spiv, i'm getting close to the end too
<poolie> i was thinking a bit about bug 257217
<ubot5> Launchpad bug 257217 in Bazaar "closing terminal causes stale lock" [High,In progress] https://launchpad.net/bugs/257217
<maxb> Presumably I can set this import up myself by just seeding the download cache with the "odd" version from the librarian?
<poolie> and the conversations in london about this kind of thing
<spiv> But I do see light at the end of the tunnel for that import, which is nice.
<poolie> about error handling and so on
<poolie> perhaps i should post to the list
<spiv> maxb: yeah, although of course it's a pretty resource-intensive import
<poolie> the idea of a crash-only design seems to make sense
<maxb> I'll abuse my office workstation with it over the weekend :-)
<spiv> maxb: FWIW it took ~1400s to reach the point where it used to crash on jubany, and if left to run to completion would probably take... hmm, not sure, but possibly days!
<spiv> I suspect when 2.4 is released and we put that on jubany it'll help the performance somewhat.
<maxb> Maybe I should hack the code to ignore the existence of all series after hardy
<spiv> Maybe only a little, but I can be optimistic :)
<poolie> there's no reason we can't run the betas
<maxb> lamont was definitely working on a 2.4b2 IS-blessed package
<spiv> poolie: well, except that the last time we updated to a beta on jubany there was some fallout due to plugin breakage or something like that IIRC
<poolie> mm
<poolie> could well happen
<poolie> we could just try running it from source
<spiv> It was fairly easily resolved, but it does push the âupgrade bzrâ task past the <"trivial, just do itâ threshold.
<poolie> true
<poolie> so essentially i'm thinking of marking 257217 wontfix
<poolie> to say that we handle closing windows by detecting the lock is stale
<spiv> Hmm, I think so.
<spiv> In general I think it's nice to make a best-effort attempt to cleanup when things go wrong or the process gets interrupted.
<poolie> i'm coming to think that it may be 'nice' but it's not actually sensible
<spiv> But in this case the risk of EINTR etc by intercepting SIGHUP means it's probably not worth the tradeoff.
<poolie> like, the general skew should be more towards nicely recovering from an interrupted situation
<spiv> And I definitely agree that it's far more important to recover gracefully on the next run
<poolie> because you will hit that anyhow
<spiv> So I'd much rather we put effort into graceful recovery than dubious cleanups while crashing.
<spiv> Which is a long-winded +1 for me for Won't Fix.
<poolie> :) thanks
<spiv> Ok, I'm off.  Have a good weekend everyone!
<poolie> cheerio, have a good weekend
<poolie> maybe i will stop too
<spiv> poolie: perhaps take a final re-review of that export patch first?
<spiv> (if you haven't already?)
<spiv> Ok, really gone now :)
<poolie> which?
<poolie> oh from um xaaz?
<poolie> ok
<maxb> poolie: Can I ask you to kill the sysvinit import? Ironically I've just found and fixed a bug I introduced during the bzr sprint which will cause the importer to produce slightly suboptimal history for packages being freshly imported with history in etch and earlier.
<poolie> spiv, beyond my sure
<maxb> So, I'm hoping we can defer the sysvinit import until that can get reviewed and deployed
<poolie> blah
<poolie> maxb, sure, how?
<maxb> figure out the pid and kill -INT it?
<poolie> done
<maxb> thanks
<maxb> I'll update the bug
<poolie> thank you
<jelmer> Riddell: do you know if syncs are happening at the moment?
<jelmer> Riddell: I mean, whether manually requested syncs are processed?
<Riddell> jelmer: yes should be
<poolie> hello riddell, jelmer
<Riddell> good morning poolie
<jelmer> hey poolie
<lifeless> poolie: hi
<lifeless> poolie: you're not in #launchpad-dev
<poolie> huh
<lifeless> poolie: but I don't agree with your approach on the mail handling patch; I've replied in mail - and had already suggested an approach in the bug.
<lifeless> poolie: I'm glad you're hacking on it.
<poolie> hm, i thought my approach was consistent
<Riddell> poolie: what was the rt ticket for adding me to jubany (asks the sysadmin vanguard)?
<poolie> 45864
<lifeless> poolie: if my mail resolves things great; if not I can chat about it so we get a consistent view on things anytime
<gour> are you aware that PHP is considering switch from SVN and only hg & git are discussed?
<AuroraBorealis> so?
<AuroraBorealis> post on on the mailing list advertising for bzr, if not then oh well :>
<gour> such tasks are for bi fishes since the migration is very often not based on technical merits but it's political issue
<gour> *big
<AuroraBorealis> pretty much
<gour> i'm reading about Advanced shared repository layouts (http://doc.bazaar.canonical.com/bzr.dev/en/user-guide/shared_repository_layouts.html) and wonder how relevant it is when one uses LP to host project's branches? to me it seems not so much and for my local organization it's anyway not a problem..
<AuroraBorealis> it seems that launchpad is the repo
<AuroraBorealis> and you can branch and submit those branches to lp like you would anywhere else
<spiv> gour: Launchpad automatically arranges for branches to be stacked, so you don't need (and actually can't use) shared repositories on its code hosting server
<gour> spiv: good...one headache less ;)
<spiv> (And Launchpad also enforces a particular, consistent hierarchy; typically ~owner/project/branch-name, with some shortcuts and a slightly different scheme for branches of distro packages)
<gour> now i'm researching about rebase7rewrite plugin...not considering git's feature but more from the darcs/fossil perspective and their 'private' branches which help to have 'nicer' history
<spiv> The first question is âwhy do you care about making 'nicer' history?â  bzr's default presentation of just the mainline in 'bzr log' etc typically gives a similarly nice view without throwing away any history.
<gour> in case when i do some 'experimental' commits in a 'feature branch' and then would like that during merge it's presented as 'one nice patch', is it the right use-case?
<spiv> Well, you get to choose the use cases, you're the user ;)
<gour> heh...doing commit/uncommit, making mistakes etc. is, maybe, not so nice/important to keep in the history
<spiv> But I'd first check if the default operation of "bzr merge" and "bzr commit" for that does something you like or not.
<spiv> I think you may find that actually you're happy with that without rebasing.
<spiv> (Or maybe not.  Personally it suits me quite well.)
<gour> spiv: you mean, you don't have need for rebase?
<spiv> I do use uncommit quite frequently :)
<spiv> I can't remember the last time I rebased.  Probably many months ago.
<AuroraBorealis> what is rebase?
 * gour is re-reading http://bemusement.org/diary/2008/July/29/rebase-criticism
<spiv> gour: that would be my website :)
<Riddell> yay, I have access to jubany
<gour> AuroraBorealis: http://wiki.bazaar.canonical.com/Rewrite?action=show&redirect=Rebase
<gour> spiv: heh, interesting...i remember it was good read, but it looks i forgot the wisdom ;)
<AuroraBorealis> ah
<spiv> gour: :)
<spiv> gour: thanks!
<spiv> To an extent I don't think it matters hugely if you rebase or simply merge; it's usually pretty rare for someone to actually spelunk through old history in enough detail that the difference would matter much.  But given that, you may as well do the simpler of the two: just merge.
<spiv> It mostly is a question of how you want to present your changes to someone else to get them accepted to their branch.
<gour> it makes sense...
<gour> btw, i've decided to use LP with or without wiki ;)
<spiv> gour: :)
 * spiv wanders off for dinner
<gour> now we're coming to looms..
<gour> now, after brief look at looms, i wonder i part of its functionality is available by using shelves to keep it simpler
<Riddell> jelmer: thanks for the changelog-closes-bugs review, I didn't write a test because I've no idea how to run the test suite for bzr-builddeb, can you tell me how?
<jelmer> Riddell: anytime, this will be a neat feature to have :)
<jelmer> Riddell: You can run them using "bzr selftest bzrlib.plugins.builddeb" or (shorter variant) "bzr selftest -s bp.builddeb"
<jelmer> Riddell: if you're not working in the version of bzr-builddeb you currently have active, you can use BZR_PLUGINS_AT
<jelmer> I usually run something like this in my active bzr-builddeb branch:
<jelmer> BZR_PLUGINS_AT=builddeb@`pwd` bzr selftest -s bp.builddeb
<Riddell> ah hah right, I should have been able to work that out
<jelmer> Riddell: just noticed - there's a find_bugs_fixed convenience function in builddeb's util.py you should be able to use
<Riddell> I'll take a look
<Riddell> jelmer: updated
<jelmer> Riddell: reviewed.
<Riddell> thanks jelmer, do you know if bzr-builddeb has a NEWS type file?  I can't see one
<jelmer> Riddell: that's a good point
<jelmer> Riddell: it's a native package, so we add entries to debian/changelog
<Riddell> ah right
<Riddell> well it can't be merged in until https://code.launchpad.net/~jr/bzr/707274-commit-message-hook/+merge/62334 gets merged anyway
 * jelmer takes the hint
<jelmer> ;)
<jelmer> I'll have a look after I wrap up my current branch
<Riddell> jelmer: "We usually stick to one single summary line in docstrings"  why, surely it should be as long as it takes to clearly describe it?
<jelmer> Riddell: sorry, that could've been worded better
<jelmer> Riddell: we usually have one sentence on a single line with the summary and then more lines for further explanation
<jelmer> doc generators often only display the first line in various places so if the initial sentence spans multiple lines it cuts the sentence off halfway
<mgz> it's also a good habit to say what a function's for in ~60 characters
<jelmer> mgz: I guess that's what I'm trying to say.
<jelmer> mgz: But you managed to do it in 60 characters rather than 4 lines :)
<mgz> :)
<mgz> gah, will have to leave bzr things for another day again
<mgz> still haven't replied to that cycles thread on the list
<jelmer> lifeless: hi
<lifeless> hi
<jelmer> lifeless: what's the best way to QA the code importers? As I understand qastaging doesn't come with its own import slave?
<lifeless> dunno
<lifeless> have a chat with losa
<jelmer> hmm, ok
<lifeless> generally we can't run stuff that talks to external servers in *staging
<lifeless> so its tricky
<jelmer> lifeless: thanks; that's not the answer I was hoping for.. :)
<jelmer> I'll talk to a losa first thing on Monday
<maxb> jelmer: Hi. Your bzr and git branches of dulwich seem to have diverged
#bzr 2011-06-04
<gour> does bzr send has support for --format=hg ?
<gour> *have
<jelmer_> gour: yep
<jelmer_> gour: though, as with all other write operations in bzr-hg, it's still somewhat experimental
<gour> jelmer_: thanks...i wonder whether it's better t ocreat project at LP and work with bzr and then 'bzr send' to bitbucket upstream or use bzr-hg directly with bitbucket
<gour> if it makes much difference at all
<gour> main point is i want to use bzr only :-)
<jelmer_> it wouldn't make much of a difference - the code that creates changegroups (which are used for hg bundles, and for hg pushes) is the same
<jelmer_> bundles are probably more trouble
<gour> thanks
<jelmer_> gour: as mentioned earlier, the write support in bzr-hg still has some rough edges
<gour> jelmer_: ok..we'll put it under some testing
<workthrick> jelmer_: poke?
<workthrick> jelmer_: bzr-git triggers bug #370710
<ubot5> Launchpad bug 370710 in Bazaar "bzr: ERROR: File id {TREE_ROOT} already exists" [Medium,Fix released] https://launchpad.net/bugs/370710
<workthrick> jelmer_: is there any way you could make it pick a unique name?
#bzr 2011-06-05
<jelmer_> workthrick: that's not really possible without breaking all git imports in existance or changing the way nested trees work
<workthrick> jelmer: can't you make it happen only on new imports, and/or only if you opt-in with an option?
<bignose> Attempting to work with Gitorious repositories
<bignose> $ bzr branch --bind git://git@gitorious.org:dive-into-html5/dive-into-html5.git devel/
<bignose> bzr: ERROR: The remote server unexpectedly closed the connection.
<bignose> I can clone it with Git, but then attempting to branch locally from a Git repository fails
<bignose> probably because I don't know how to tell Bazaar that the local directory is a Git repository.
<bignose> same failure if I try âgit+sshâ
<bignose> bzr branch --bind git+ssh://git@gitorious.org:dive-into-html5/dive-into-html5.git devel/
<gour> bignose: have you tried cloning something from github? i also get error with the above branch
<maxb> bignose: You have a colon between the hostname and the path. That's not an URL
<bignose> maxb: thanks. I was (obviously) cribbing from a URL designed for use with Git.
<bignose> jelmer: now I get âAttributeError: 'RepositoryFormat2a' object has no attribute 'supports_full_versioned_files'â
<maxb> Huh. It's news to me that git doesn't use standard URLs too
<bignose> from /usr/lib/python2.6/dist-packages/bzrlib/plugins/git/fetch.py
<bignose> maxb: I'm sure it does, but being Git, it probably supports a zillion different syntaxes also.
<maxb> bignose: I'd suggest version skew between bzr core and the bzr-git plugin
 * gour suggests (most of) people to move to bzr :-)
<lifeless> bignose: strictly speaking, its not a URL, whether git accepts it or not
<bignose> lifeless: is this a âURI versus URLâ distinction?
<lifeless> no
<bignose> 'cos the âgit+ssh://git@gitorious.org/dive-into-html5/dive-into-html5.gitâ looks like a URI to me
<bignose> I'm pretty sure it meets the URI standard also
<lifeless> thats a url
<lifeless> git+ssh://git@gitorious.org:dive-into-html5/dive-into-html5.git isn't
<bignose> lifeless: yes, agreed.
<lifeless> per std66
<lifeless> the new error you are getting
<bignose> my point being that while I'm sure Git accepts standard URIs, I'm sure it *also* accepts loads of things which aren't URIs
<lifeless> is a version skew in the bzr-git <-> bzrlib version you're working with
<bignose> and those creep into documentation (such as the âhow to branch this repoâ instructions on Gitorious)
<bignose> okay. [insert standard until-OpenID-relying-party-support-on-Launchpad-no-bug-report-from-me] I hope it can be reported and fixed.
<lifeless> jelmer is busy refactoring a tonne of stuff to get better test coverage
<bignose> great.
<lifeless> (making good use of his full time work on bzr ;))
<bignose> I'm madly impressed with Jelmer's work of late
<lifeless> one of the things is that he's adding flags indicating what features the repository implementations handle
<lifeless> anyhow
<lifeless> point is, this is transient
<lifeless> next stable bzr release will make the bzr-git version work
<gour> 2.4?
<lifeless> something like that
<maxb> Yikes, importing the linux kernel into an UDD branch from scratch looks like it's going to take days
<maxb> 8 hours runtime, and it's still not done hardy yet
<spiv> maxb: trying with trunk bzrlib?
<spiv> I have a suspicion that jam's speed improvements will probably help a least a bit there, maybe a lot.
<maxb> hmm, actually this machine is still on 2.3.x
<jelmer> bignose: that issue has been fixed in bzr-git trunk a while ago.. where are you getting your bzr-git?
<bignose> jelmer: Debian, as usual.
<bignose> bzr-git 0.6.0+bzr1223-1
<jelmer> bignose: I'll upload a new version to sid
<bignose> jelmer: a new release?
<jelmer> new snapshot
<bignose> hmm. isn't such a fix worth at least a point release?
<jelmer> bignose: the regression isn't actually in any release
 * bignose laments that people seem to avoid releases more often these days
<bignose> ah okay.
<jelmer> I don't want to do a new release for every single bugfix :)
<bignose> jelmer: congrats on what appears to be some pretty awesome improvement to Bazaar performance
<jelmer> bignose: blame jam :)
<bignose> ah, hm, wrong âJ'mâ person :-
<bignose> )
<jelmer> :)
<bignose> jelmer: well, congrats on making my current job far nicer: âbzr-svnâ saves me heaps of frustration
<jelmer> thanks - that's great to hear
<maxb> Someone declined bzr-core from bzr-codereview-subscribers
<jelmer> maxb: see the email
<jelmer> maxb: Aaron did
<maxb> yes
<maxb> But then I figured out how to make it a member myself anyway
<maxb> :-)
<maxb> jelmer: By the way, what's going on with the dulwich trunks? ~vcs-imports/dulwich/trunk and ~dulwich/dulwich/trunk have diverged
<jelmer> maxb: should be fixed now
<maxb> thanks
<jelmer> hmm, the integration to make dulwich use bzr's ssh integration seems busted
<maxb> jelmer: I'm still occasionally running into BzrCheckErrors manipulating dulwich branches, relating to the improper dpush-ing that I've mentioned in the past. What do you think about doing this:
<maxb> Erase the published shared repository on samba.org and replace it with one not suffering from the problem. Rename the old ~dulwich/dulwich/trunk to trunk-broken, and create a new one. This would at least prevent the bad data from spreading further, though it won't help with the cleanup.
<jelmer> maxb: I'd like to get rid of the remaining inconsistent parent issues in bzr-git before doing that
<maxb> Well, maybe just rename ~dulwich/dulwich/trunk to trunk-broken for now, then to communicate that people shouldn't be using it?
<lifeless> jelmer: maxb: what are the symptoms of that bad dpush ?
<lifeless> bzrlib.errors.BzrCheckError: Internal check failed: Cannot add revision(s) to repository: missing referenced chk root keys: [StaticTuple('sha1:d34f39faee56e120a83e7cec4fe01c4fd5fd32f6',)] one of them ?
<jelmer> lifeless: yes
<lifeless> ah
<lifeless> so this has broken launchpad's deployment now
<lifeless> a) how do we fix?
<lifeless> b) how do we stop it breaking it again ?
<lifeless> jelmer: ^
<lifeless> wgrant: ^ may be useful for you later today
<lifeless> heh
<maxb> lifeless: Hmm. I usually get "missing text keys" when I'm being bitten by this dulwich issue
<mgz> is bugs.debian.org the upstream tracker for etckeeper?
<lifeless> I don't thinkso
<mgz> I'm not seeing anything on Joey Hess' webpage about where he wants bug reports
<mgz> I imagine there's a file in the package that tells you
<elmo> mgz: bugs.debian.org, I'd imagine
<mgz> we've got a report against bzr over non-ascii filenames that seems to be being hit because etckeeper has some bogus environment for a cron script
<mgz> there's an existing bug entry for the issue our end, but it looks like it's worth filing something for the other part too
<mgz> might just be a problem with the guy's system but I don't know enough about locale weirdnesses on nix to tell
<lifeless> maxb: hi
<lifeless> nvm
<lifeless> actually yes, need to check
<lifeless> maxb: why are bzr and bzr-core members of bzr-codereview ?
<mgz> it's a temporary measure until all the people who want to subscribe have a chance to
<maxb> lifeless: It's a transitional measure, did you see my email on bazaar@l.c.c ?
<lifeless> we only need -core
<lifeless> bzr is a member of -core
<lifeless> with -core and bzr both non-open, we should change the owner to be -core too
<lifeless> [or change it to be -council, but -council perhaps wants more members]
<maxb> Actually, having stared quite a bit at how the teams are configured in preparing for this, I'm planning to propose deleting ~bzr-core eventually
<lifeless> we can do a merge into ~bzr at that point
<maxb> True
<maxb> So: short-term: Once one week is up, I will remove ~bzr(-core) from ~bzr-codereview-subscribers
<maxb> Long-term: I want to continue working on obsoleting the existence of ~bzr-core
<lifeless> man
<lifeless> putting together custom pc's got -hard- over the last 10 years
<lifeless> but no mainstream vendor seems to want to sell a 32gb config :(
<fullermd> It's awful hard to do that on client hardware.
<lifeless> fullermd: awful hard to do which bit?
<lifeless> jelmer: :
<lifeless> 08:45 < lifeless> jelmer: maxb: what are the symptoms of that bad dpush ?
<lifeless> 08:45 < lifeless> bzrlib.errors.BzrCheckError: Internal check failed: Cannot add revision(s) to repository: missing referenced chk root keys: [StaticTuple('sha1:d34f39faee56e120a83e7cec4fe01c4fd5fd32f6',)] one of them ?
<fullermd> 32 gig (of RAM, I'm assuming)
<lifeless> 08:55 < jelmer> lifeless: yes
<lifeless> 09:03 -!- BasicOSX [~BasicOSX@c-75-73-131-27.hsd1.mn.comcast.net] has joined #bzr
<lifeless> 09:03 < lifeless> ah
<lifeless> 09:03 < lifeless> so this has broken launchpad's deployment now
<lifeless> 09:03 < lifeless> a) how do we fix?
<lifeless> 09:04 < lifeless> b) how do we stop it breaking it again ?
<lifeless> fullermd: i-2600 + 4*8GB DDR3 sticks
<lifeless> 09:04 < lifeless> jelmer: ^
<lifeless> 09:04 < lifeless> wgrant: ^ may be useful for you later today
<fullermd> Yeah, and 8 gig DIMMs mean 4Gb DRAM chips, which are still quite rare.
<lifeless> fullermd: http://ark.intel.com/Compare.aspx?ids=52213,52214,52215
<fullermd> (or buffered DIMM's, in which case you're out of the client world)
<fullermd> Sure, that's what it's rated for.  Doesn't mean the DIMMs are at all easy to come by.
<lifeless> fullermd: sure
<fullermd> (and I'm awful suspicious of that sort of 'memory size' rating on a memory controller anyway...)
<fullermd> 2Gb DRAMs are relatively common now, which gives you 4 gig [unbuffered] DIMM's.  If you go to a 1366 socket or wait for 2011, that'll give you 3*2 of those, for 24 gig at least.
<lifeless> fullermd: it is 2011
<fullermd> Socket 2011.
<lifeless> ah
<fullermd> Q4 this year maybe?  Dunno offhand.
<fullermd> I don't pay that much attention to schedules for Intel client chips, since they're out of my to-buy list.
<lifeless> the 3* is the gutfeld stuff isn't it ?
<lifeless> anyhow, I want 4GB/thread
<fullermd> The top Nehalems and Westmere are tri-channels.  The tri Sandy Bridges are the 2011 stuff.
<lifeless> yeah, I'm replacing my i920 - a trichannel
<jelmer> lifeless: how has this broken launchpad deployment?
<fullermd> Of course, I'm pretty sure they're all lower single-thread perf than the 2600.
<lifeless> jelmer: see buildbot
<lifeless> jelmer: what happens on buildbot will happen to the deploy path
<lifeless> fullermd: the 920 has 4 cores 8 threads but w/6GB of ram as soon as I start to throw parallel work at it it thrashes :(
<jelmer> lifeless: ah, hadn't seen that. I'll look into it tomorrow
<lifeless> jelmer: well we kinda have to fix it today
<lifeless> jelmer: or we'll mess up the schedule for db deploy this week
<lifeless> jelmer: so if you want evidence captured or whatever, say so now ;)
<lifeless> otherwise I suspect wgrant/spm are going to get rm-ing on the symptoms
<lifeless> fullermd: so whats the cl7/cl9 refer to ?
<maxb> Number of clock cycles it takes the DRAM to set up for reading an address, I think?
 * maxb wonders if we *really* need an UDD import of the kernel :-/
<maxb> This Soyuz duplicate .orig.tar.gz is proving irksome
<lifeless> skip that revision?
<jelmer> lifeless: I'll see about having it cleaned up now
<lifeless> jelmer: thanks, but there won't be a losa around for another hour or so - rather than working your weekend, you might like to just note what evidence you'll want kept
<jelmer> lifeless: I have all that, I'd just rather get it cleaned up than to get that particular MP reverted
<lifeless> jelmer: Oh, I wasn't thinking reversion
<lifeless> rather widespread rm -rf of the working area and fresh pull
<lifeless> s
<lifeless> I wonder if you can shove a server 240 pin 8gb dimm into a 'client' motherboard
<lifeless> successfully
<jelmer> lifeless: Ah, sorry - I thought you meant removing the revision in question. In that case I won't worry.
<lifeless> that wouldn't be my first choice as it would require another 10 hours of percolating test results to do that
<workthrick> jelmer: did you see my question from re: can't have unique root IDs without breaking existing checkouts, yesterday/yestermorning?
<jelmer> workthrick: I think I replied to that
<workthrick> might be, but I don't think I got any answer, it was probably after I disconnected
<workthrick> if you don't mind repeating, I'd appreciate
<jelmer> I thought it was a question on Launchpad?
<workthrick> ah, no
<workthrick> might I have a link then?
<workthrick> <workthrick> jelmer: can't you make it happen only on new imports, and/or only if you opt-in with an option?
<workthrick> that's what I meant
<jelmer> workthrick: there's no way to tell is a new import - somebody else with bzr-git may have done an import of the git repository
<fullermd> lifeless: CL == CAS latency, which has to do with activating a column.  It's not exactly read access latency, but it's close enough that you can read it as a relative proxy.
<lifeless> k
<fullermd> (there are like a dozen different latency measures in DRAM, all of which give me a headache trying to understand)
<lifeless> fullermd: do you happen to know if the i-2600 has rank limitations ?
<lifeless> or do they not apply in ddr3 ? [all the docs I found so far talk ddr/ddr2]
<fullermd> I think it just doesn't get talked about anymore; everybody handles dual-ranked DIMMS (16 chips, or 18 for ECC), and everything about that is in buffered territory.
<fullermd> s/about/above/
<lifeless> fullermd: do consumer motherboards deal with buffered dimms ?
<workthrick> jelmer: yes, but I can always opt into that, and even if that fails, I can always sync the two imports going through an intermediate git stage which is sure to interoperate. I'm much more concerned about the ability to interoperate with myself (and the ability to join multiple git checkoiuts into my project's repo) than potential somebody which might or might not exist. If I need to exchange patches with them, that's why I have a github branch in the fi
<workthrick> rst place
<fullermd> Nope.  That's all Xeon/Opteron territory.
<lifeless> ah
<lifeless> maybe I should look at a mac pro
<fullermd> (if they could, I'd have more than 8 gig.  ZFS == hungry!)
<workthrick> jelmer: in other words, I don't care whether bzr will consider new-style and old-style imports related as long as the history is equivalent and the mapping to/from git is stable within a checkout
<workthrick> and as long as you can get a related checkout by specifying explitictly which style you want, of course
<fullermd> I don't remember offhand if it's the board or the memory controller that's overridingly important for buffered vs non.
<fullermd> If it's the board, you may be able to get a e.g. S1366 workstation board that will handle it.
<jelmer> workthrick: in other words, you would want an option to specify a custom bzr<->git mapping to use
<jelmer> workthrick: patches that make it easier to specifying the mapping are welcome, though I don't have any plans to work on this myself in the near future
<workthrick> jelmer: rather something like --with-unique-roots or something, which'd tell bzr-git to create unique (but deterministic) root ID
<jelmer> workthrick: that requires a new bzr<->git mapping
<workthrick> jelmer: the problem is that the lack of that creates interoperability problems for me _right now_, because I wanted to go keep a local temporary checkout of upstream github projects until my patches get accepted, by having a bzr-git checkout outside of my project repo, joining a copy into the project repo, working on patches on the bzr-git checkouts, then merging them into my project for immediate use at the same time I send pull requests upstream, so t
<workthrick> hat I can switch transparently over to the upstream once they merge my patches
<workthrick> but I can't join more than one bzr-git checkout into my repo
<workthrick> jelmer: right, but that mapping would be possible to create, right? Does git have something equivalent to root IDs, or something that can be deterministically transformed into one?
<jelmer> workthrick: I'm sorry this is creating problems for you at the moment but it's a nontrivial problem to fix properly; you're welcome to register your own custom mapping that has more unique file ids
<jelmer> workthrick: It's not just the root that's not unique, if two git repositories that are joined have a file named "README" this will also cause problems
<workthrick> jelmer: sure, I understand it might not be trivial, I was just presenting the use case which I know creates problems (as opposed to wanting to merge with an independent old-style checkout, which is hypothetical for me at this time)
<workthrick> jelmer: hmm, and is there something which somehow identifies a "repository" in a stable way?
<jelmer> workthrick: supporting the joining of multiple git-imported trees into a single bzr branch is not on top of the todo list at the moment
<workthrick> from what I understand, bzr in 2a does that explicitly at the time you commit the first revision, creating a unique ID which then needs to be repeated for the trees to be considered related, right?
<jelmer> workthrick: there isn't really anything unique to identify a repository
<workthrick> jelmer: is there some fastimport transformation I could apply mechanically to make it happen perhaps?
<jelmer> workthrick: you can use fastimport itself, without involving bzr-git at all
<workthrick> jelmer: hmm, so if I have two unrelated fastexports of a the same repo, which ordinarily would be considered unrelated in bzr, will git treat them as related if I dpush?
<jelmer> workthrick: you can't dpush branches imported with bzr-fastimport
<lifeless> fullermd: hah - http://www.asus.com/Motherboards/Intel_Socket_1155/Maximus_IV_Extreme/#specifications 'According to IntelÂ® SPEC, the Max. 32GB memory capacity can be supported with DIMMs of 8GB (or above). ASUS will update QVL once the DIMMs are available on the market'
<workthrick> jelmer: oh
<workthrick> jelmer: so only branches bzr-git as marked as its own can be dpushed?
<workthrick> *has
<jave> I hve a branch which contains chonges I want to remove: http://bazaar.launchpad.net/~joakim-verona/inkscape/dbus-fixes/changes
<jelmer> workthrick: it's not whether they're marked or not, it's that branches created by bzr-fastimport don't contain the same data (and the history has to be *exactly* the same)
<workthrick> jelmer: even if no filtering is done on fastimport? WHat's lost in this case?
<jave> the undesired change is the removal of a file.
<jelmer> workthrick: how do you want to use dpush though, if the branches were joined with "bzr join" ? dpush would dpush the root branch
<workthrick> jave: do you want to remove it from history, or just revert its effect?
<jave> the problem is that the maintainers cant read the diff because the diff now is too large
<fullermd> lifeless: Yah.  4Gb DRAM chips are somewhat beyond the "look, we can make this" stage, but aren't in mass prod yet.  And we're probably 2 or 3 memory shrinks away from them really filtering into the client market.
<workthrick> jelmer: nono, that's why I have a separate bzr-git clone outside of the repo; I then copy it inside and join, so that I can still merge *from* the bzr-git (but not to, so the work happens on bzr-git copy)
<jave> workthrick: so, the shortest path to inclusion in trunk i guess
<fullermd> lifeless: I was guessing 2014-5 the other day for when 8GB DIMMs get down to near $/gig parity.
<workthrick> jave: I don't understand
<jelmer> workthrick: filtering is possiblein theory, but would have the same effect of using bzr-git to do the clone
<workthrick> jave: but the maintainer can always say bzr st -c $revno
<jelmer> workthrick: it creates a branch with file ids that are based on the paths
<workthrick> that will show them additions and removals without showing a full content diff
<fullermd> (2Gb DRAM's were in real, though limited, production in like 2009, but it's only this year that 4GB DIMMs got down close to pricing parity)
<workthrick> jelmer: ah, so bzr won't assign a root ID upon the first commit?
<jave> workthrick: the burden seems to be on my shoulder if I want the patch accepted
<workthrick> jave: I still don't understand what you want to do
<jave> workthrick: http://bazaar.launchpad.net/~joakim-verona/inkscape/dbus-fixes/revision/10013#po/inkscape.pot
<jelmer> workthrick: it still would - the branch would be exactly the same as if it were imported with bzr-git
<jelmer> workthrick: even if it wouldn't, bzr dpush would rewrite the branch to have a non-unique root file id
<jave> workthrick: po/inkscape.pot was removed there. Then I tried adding it back later but that didnt help
<lifeless> fullermd: mmm, ugh.
<workthrick> jelmer: xchat crashed, sorry
<jelmer> <jelmer> workthrick: it still would - the branch would be exactly the same as if it were imported with bzr-git
<jelmer>  workthrick: even if it wouldn't, bzr dpush would rewrite the branch to have a non-unique root file id
<workthrick> jelmer: okay, and would it be technically possible to register a mapping that synthesises IDs based on the first revision in the history? If so, I'd be satisfied with this measure of "identity", I don't really see much use in desperately trying to intermarry histories which differ on the first commit
<lifeless> ahha
<lifeless> F3-16000CL7Q-8GBFLS(XMP)
<jelmer> workthrick: the root id isn't used to identify the tree in any way - it's just the file id of the root directory
<workthrick> jelmer: so the ids would be, say, history[0].sha1 + path
<workthrick> jelmer: I understand that
<workthrick> but we're talking about a custom mapping which creates unique IDs while being stable amongst related trees
<jelmer> workthrick: that would be possible to do for simple histories, not in all cases
<workthrick> jelmer: oh, can you describe a case in which it'd fail?
<jelmer> the very first left hand side ancestor doesn't have to be the same for all revisions in a revision graph
<workthrick> I can't really see a situation in which the first parent would be different
<fullermd> lifeless: *blink*  That's a 4x set of 2GB's.
<workthrick> jelmer: but wouldn't bzr then see them as unrelated?
<maxb> jave: Is there still a problem? It looks like you put things right in 10022 ?
<jelmer> workthrick: http://pastebin.ubuntu.com/619457/
<jelmer> workthrick: for D and E that revision is different than for C and F
<jelmer> workthrick: for D and E that revision is different than for C, F and G
<workthrick> jelmer: yes, but that's a situation in which you have two completely independent trees being merged, which won't arise unless the tree joins in another tree. I'd be happy to give up the ability to merge automatically git trees which join in other trees in exchange for being able to join in multiple trees myself
<jave> maxb: heres the merge discussion: https://code.launchpad.net/~joakim-verona/inkscape/dbus-fixes/+merge/59877
<jelmer> workthrick: it doesn't have to involve a join - you can merge arbitrary trees together any time
<workthrick> jelmer: unless I'm not seeing something and such a situation can arise in the course of normal single-tree history, I'm perfectly happy to work only on simple histories
<workthrick> jelmer: sure, I know, a join is nothing else than an automated way to do a specific type of two-tree merge
<jelmer> workthrick: so, in that case you can add a custom bzr plugin which registers a new bzr-git mapping that does what you want
<workthrick> but it's a tradeoff I'm willing to take
<workthrick> jelmer: mhm, would you mind outlining how that is done?
<jelmer> workthrick: it wouldn't be something that's suitable for inclusion in bzr-git itself, because of the limitations mentioned
<lifeless> fullermd: yes, bad QVL bad
<jelmer> workthrick: sure
<lifeless> fullermd: took me a bit to work that out
<maxb> jave: Did you actually intend there to be any modifications to the pot file on your branch? Can we just throw it away and revert to trunk's version of it?
<jelmer> workthrick: you would need to create a subclass of BzrGitMapping (see mapping.py in bzr-git)
<jelmer> workthrick: and then register it
<workthrick> jelmer: what about making it an default-off switch you have to specify explicitly to get that? The very reason I'm using bzr-git is because it allows me to play with github upstream trees without touching git, so I imagine I'm not the only person ever to have the problem
<jave> maxb: yes if I ca revert to the trunk version that woulb be fantastic
<workthrick> jelmer: ah, cool. And how do I get at the first revisions sha1?
<jave> maxb: I have no idea why it got removed in the first place
<maxb> jave: People seem to have given an answer to why in the merge proposal comments
<workthrick> jelmer: so basically bzr clone --with-unique-ids git://foo.git?
<maxb> jave: Anyway, I think "bzr revert -r ancestor:lp:inkscape po/inkscape.pot; bzr commit" should sort things out
<jave> maxb: thanks!
<jelmer> workthrick: it's not suitable for mainstream use because of the corner case mentioned, it's a nontrivial amount to support that too
<jelmer> workthrick: adding options to bzr clone isn't possible from within bzr-git at the moment- it would need patching of bzr itself
<workthrick> jelmer: even if it'd be documented to have that limitation and that it's intended to support a specific use-case you're supposed to understand?
<workthrick> jelmer: oh
<jave> maxb: well obviously I made an error. what I meant is that I cant figure out how I made that error. I dont recall doing "bzr clean>
<jelmer> workthrick: it's too much effort to support that properly, I would rather work on fixing the more structural issues with file ids
<workthrick> OK
<workthrick> jelmer: and I'll be still able to push to github and interoperate within imports using that mapping afterwards?
<jelmer> workthrick: you should be able to, in theory
<jelmer> workthrick: this is all untreated territory so you might run into bugs
<workthrick> that's what I'm after, otherwise I can just import the files without history and not bother pulling in the history
<workthrick> jelmer: aha
<workthrick> I'll take a stab at it tomorrow-ish then
<jelmer> I'm happy to give advice and help fix the more structural bugs in bzr-git you might run into
<workthrick> jelmer: one more thing, what does getting the first revision and its sha1 involve?
<workthrick> do I use pure bzr APIs, or some bzr-git/dulwich specific ones
<workthrick> ?
<workthrick> jelmer: sure, thanks. That's one thing I've never had any reasons to complain about in your plugins :)
<workthrick> and I sure ran into more bzr-svn bugs than I can count
<jelmer> workthrick: you might have to patch bzr-git to allow it to do something like that
<workthrick> jelmer: aha, I will bother you tomorrow then. Will you accept such patches as long as they're clean and don't change the default behaviour?
<jelmer> workthrick: depends on the patch I guess; I don't mind e.g. passing along the revision id of the current revision, but not the revision of the first one in the ancestry (which would impact performance)
<workthrick> jelmer: yes, I suspected it'd impact performance, but exposing an on-demand pathway to it would be kosher?
<jave> maxb: the diff seems much better now. thanks again
<jelmer> workthrick: again, really depends on the patch
<workthrick> jelmer: also is there a mechanism bzr-git can use to mark trees it created with that mapping to recognise them later on?
<jelmer> workthrick: the first bit of the revision id identifies the mapping
<workthrick> aha, cool
<jelmer> e.g. if you look at the revision id of standard bzr-git created revisions you'll find "git-v1:..."
<jelmer> that name comes from the mapping subclass, you'd probably want to set 'prefix = "git-worthrick"' or something like that
<workthrick> jelmer: hmm, thinking of relatively least bothersome way to integrate it into the UI, do you think creating a custom URL handler (something like uniquify:git://...) would be reasonable to do?
<workthrick> and/or git+fileids://
<jelmer> workthrick: it should be possible to do something like that, but you'd need to patch bzr-git
<workthrick> ok
#bzr 2012-05-28
<sarcasticCat> Does bazaar have some equivalence functionality as GIT Blame?
<spiv> sarcasticCat: have you tried 'bzr blame'? :)
<sarcasticCat> lol that's that first thing I tried :P
<spiv> What does it lack that you're looking for?
<sarcasticCat> spiv: Uhm, there's this source file (that has been worked on by multiple people), I'd like to know who've made what changes
<sarcasticCat> spiv: git blame would do just that. But at my place, the cvs is bazaar, and I'd like to know if bzr is capable of this
<spiv> sarcasticCat: bzr blame should tell you that.
<spiv> sarcasticCat: is it not doing that for y ou?
<spiv> (you may also find GUI implementations nice, like 'bzr qannotate' from the qbzr plug, or 'bzr gannotate' from the bzr-gtk plugin)
<sarcasticCat> spiv: Oh, ok. Yeh, it worked. (It didn't work the first time because I was at the wrong directory)
<sarcasticCat> thanks
<spiv> You're welcome.
<sarcasticCat> spiv: Uhm, now I get <filename> is not versioned sometimes.
<sarcasticCat> What might be the reason for ths? (i'm pretty sure people have made a lot of changes gradually in these files)
<sarcasticCat> *this
<spiv> sarcasticCat: hmm, when you try "bzr blame <filename>"?  what does "bzr status <filename>" report?
<bob2> how sure are you that it is versioned
<sarcasticCat> bob2: almost 100%. (This file has different blocks of code written in different styles, so it must've been written by multiple people, obviously not at the same time. So it must be versioned)
<bob2> :/
<bob2> er, use bzr status or bzr log to find out
<sarcasticCat> well, bzr log would give me > 2000 lines (from 2009 till now) :(
<bob2> bpaste.net shell session of 'bzr log somefile | head ; bzr blame somefile | head'
<sarcasticCat> Oooh, bzr status <filename> gave me "nonexistent", which doesnt make anysense
<sarcasticCat> I'm staring at the file right now. o_O
<sarcasticCat> the syntax is [bzr status <path to file>] , right?
<bob2> == not in bzr
<bob2> (this is all the same as git btw)
<sarcasticCat> bob2: Sorry, i'm not quite following. What do you mean by "not in bzr"
<sarcasticCat> ?
<bob2> the file isn't in bzr
<bob2> or your path is screwed up somehow
<sarcasticCat> uhm, yeah. there's a typo in it! Sorry for the noise!
<sarcasticCat> btw, is there a way to check who first added a particular file?
<bob2> bzr log --help
<bob2> -> reverse -> | head
<sarcasticCat> bob2: uhm...? reverse what?
<bob2> ?
<bob2> the output of log
<bob2> prety sure it's the exact same answer as in git, just with the word 'bzr' instead of the word 'git'
<sarcasticCat> Well, I know what the output of log looks like. But I dont see how that relates to my question.
<bob2> ? the first commit is the one that added it
<sarcasticCat> oh, I see what you're saying. I thought you said to do a [bzr log] (w/o the filename)
<mgz> morning
<fullermd> Humbug.
 * jelmer waits for the 2.5.1 SRU tests to pass..
<mgz> how parallel are you going?
<jelmer> mgz: 4 I think
<jelmer> thunderbird is also keeping one of my CPU cores busy though
<mgz> ehehe
<mgz> thunderbird is the antivirus of nix.
<jelmer> what it's doing, I have no clue..
<fullermd> Some things man isn't meant to know.
<frathgeber> hi, all. i've been googling for an answer to this question for quite a while but can't seem to find an answer
<frathgeber> is it possible to configure which shared repository a branch uses?
<frathgeber> situation as follows: i have a co-located workspace in /path/to/colo and a legacy shared repo in /path/to
<mgz> yes, but depends what you mean by 'configure'
<frathgeber> i want to choose the shared repo location
<frathgeber> e.g. with bzr reconfigure
<frathgeber> or by editing .bzr/branch/branch.conf or any other configuration
<mgz> it will just use the one closest as it climbs the directories
<frathgeber> which break my co-located workspace
<frathgeber> because i want my branches to use /path/to/colo/.bzr/branches
<mgz> there's no problem having a repo in colo
 * jelmer luncheons
<jelmer> fsvo lunch
<frathgeber> yes, but for some reason the branch suddenly picks up the shared repo in the parent
<frathgeber> which obviously doesn't contain its history
<frathgeber> so as a consequence my co-located workspace is now broken
<mgz> jelmer, not quite yet! is there some command that will make a colo branch init a repo where it lies?
<frathgeber> :)
<jelmer> mgz: a bzr-colo branch or a bzr-core colocated branch?
<frathgeber> i'm using bzr-colo
<frathgeber> but i don't think it matters
<frathgeber> it's related to the bug i just reported: https://bugs.launchpad.net/bzr/+bug/1005532
<ubot5> Ubuntu bug 1005532 in Bazaar "bzr reconfigure --standalone has no effect on lightweight checkouts" [Undecided,New]
<jelmer> frathgeber: that does matter
<frathgeber> ok
<jelmer> the way in which bzr-colo stores it branches is confusing bzr
<mgz> frathgeber: so, in theory there's no problem with the layout you want, just some of the conversion commands are likely too zealous about sqiushing things together
<frathgeber> jelmer: yes, i realised it's confusing bzr
<frathgeber> and now i'm looking for a way to un-confuse bzr
<jelmer> I would be inclined to reassign this to bzr-colo
<frathgeber> i.e. make it use .bzr/branches as the shared repo again
<frathgeber> instead of ..
<frathgeber> i think what i'm really asking is: how does bzr-colo make a branch use a shared repo in a subdirectory
<frathgeber> and how can i restore this configuration if it's broken?
<jelmer> frathgeber: if a branch itself doesn't have a repository bzr will look upwards
<jelmer> so if you remove .bzr/branches/foo/.bzr/repository it will start using .bzr/repository again
<frathgeber> there seems not to be a .bzr/branches/foo/.bzr/repository
<jelmer> if .bzr/branches/foo is a standalone branch there would be
<frathgeber> ok
<frathgeber> so i need to bzr reconfigure --standalone .bzr/branches/foo
<frathgeber> oh bugger, i see what has happened
<jelmer> frathgeber: I don't think bzr-colo branches would ever want to be standalone?
<jelmer> shouldn't they use the repository in .bzr/branches ?
<frathgeber> my failed attempt to reconfigure did actually delete the shared repository in .bzr/branches/.bzr/repository
<frathgeber> they should, yes
<mgz> right, go and eat some things jelmer :)
<frathgeber> but my failed attempt to reconfigure it as per bug #1005532 seemed to have killed that shared repository
<ubot5> Launchpad bug 1005532 in bzr-colo "bzr reconfigure --standalone has no effect on lightweight checkouts" [Undecided,New] https://launchpad.net/bugs/1005532
<jelmer> anyway, "lunch" first.. back in 45 min :)
<frathgeber> thanks, enjoy your lunch
 * frathgeber just had 'lunch' a few min ago
<mgz> frathgeber: the interesting thing for that bug is probably the steps to get into that situation
<mgz> if you can reproduce from scratch, that would be usefulful to include steps for
<frathgeber> yes, it actually started earlier, but i hadn't expected that that would be relevant
<frathgeber> situation was as follows (and i think will be subject of another bug report):
<frathgeber> co-located workspace in /path/to/colo
<frathgeber> now i did bzr colo-checkout ../mybranch as described in the bug report
<frathgeber> subsequently however, i rebased /path/to/colo (which in fact is also a lightweight checkout of mybranch)
<frathgeber> actually, that should be legal, shouldn't it? rebasing a branch that has 2 lightweight checkouts shouldn't break either of them?
<mgz> shouldn't have any impact, indeed
<frathgeber> anyway, i noticed that bzr info in ../mybranch gave me the 'wrong' shared repo and indeed all bzr operations were broken
<frathgeber> bzr: ERROR: Revision ... not present in ...
<frathgeber> so i was looking for a way to point it back to the 'right' shared repo
<mgz> right, but you're not sure which command actually broke the repo, correct?
<mgz> for the bug report, that's what we need
<frathgeber> correct
<mgz> for recovery, it sounds like you want to make a fresh branch from another copy of the repo, as at some point the current one got deleted
<frathgeber> indeed
<mgz> possibly during recovery attempts after the layout got confused rather than at the same time
<frathgeber> i think i had pushed everything upstream before
<frathgeber> i've repeatedly done bzr reconfigure --standalone followed by bzr reconfigure --use-shared to figure out what actually happened
<mgz> remember .bzr.log also records your past commands and might be useful in working out what happened when
<frathgeber> very good point indeed
<frathgeber> i'll have a look at that and see if it tells me sth
<frathgeber> ah, there we go. i think i remember now what caused me to try those weird experiments
<frathgeber> bzr reported ../mybranch was out of date, so i tried bzr up, which failed
<frathgeber> saying 'branch has no revision ...'
<frathgeber> mgz: i can attach .bzr.log to the bug report?
<mgz> yup, you may want to trim it a little, but keeping a few commands before that update would likely be useful too
<frathgeber> yeah, i found the but from where it's potentially relevant
<frathgeber> odd, https://bugs.launchpad.net/bzr/+bug/1005532/+addcomment is broken for me, i get the generic 404 'Lost something?'
<ubot5> Ubuntu bug 1005532 in bzr-colo "bzr reconfigure --standalone has no effect on lightweight checkouts" [Undecided,New]
<frathgeber> refreshing helped
<mgz> odd, on post or get?
<frathgeber> get
<frathgeber> i think it was because jelmer had made a status change in the meantime
<mgz> ah, I know what it is
<mgz> project changed from bzr to bzr-colo and there's no redirect
<frathgeber> ah, right
<frathgeber> that's fair enough
<frathgeber> i'll try to rescue my shared repo and maybe someone can make some sense from my bzr.log
<mgz> creating a fresh branch from the bits you pushed upstream is probably easiest
<frathgeber> yep
<frathgeber> mid-term i'll probably switch to colo-core
<frathgeber> when is that going to make it into the release?
<mgz> it's in 2.5, with a few ui polish issues
<mgz> neil was talking about making bzr-colo use the new core colo support where available
<frathgeber> ok. where can i find documentation on core colo?
<frathgeber> canonical.com is really slow today...
<mgz> not sure what we have on the user-facing side
<frathgeber> nothing obious at least :)
<frathgeber> it seems i've lost the 2 most recent commits
<frathgeber> now the branch is in some weird limbo and appears unusable
<frathgeber> e.g. bzr: ERROR: Could not determine revno for ... because its ancestry shows a ghost at ...
<jelmer> frathgeber: did you perhaps remove any of the repository directories?
<jelmer> one repository probably has/had mroe revisions than the other
<frathgeber> i didn't conciously remove any of the repository directories
<frathgeber> but quite possibly one of the commands i ran did (see https://bugs.launchpad.net/bzr-colo/+bug/1005532/+attachment/3166962/+files/bzr.log)
<ubot5> Ubuntu bug 1005532 in bzr-colo "bzr reconfigure --standalone has no effect on lightweight checkouts" [Undecided,New]
<frathgeber> is there anything i can do to rescue that branch? i still have the working tree and also the dirstate, so i could branch from upstream and diff to see the changes and try to re-create those 2 missing commits
<frathgeber> is there an easier/safer way to do that?
<jelmer> frathgeber: it's probably easiest to talk to somebody familiar with bzr-colo, I'm not entirely sure what all the colo- commands do
<frathgeber> ok. but assuming the repository is lost (which is what i'm assuming now), do i have better options to ressurect those 2 lost commits than what i described above?
<vila> frathgeber: yup. On the other hand, 'find . -name pack-names -print' should tell you where some repository may be hidden and hopefully recoverable (I'm here for less than ~5 minutes)
<frathgeber> ok, will run that
<frathgeber> alas it's gone
<frathgeber> i'll go the manual route then
<frathgeber> thanks for your help jelmer, mgz, vila
<fullermd> Oh look, 2.5.1 takes lplibrarian into the hundred millions.  Yeesh.
<jelmer> fullermd: whu?
 * fullermd shrugs
<fullermd> Doesn't mean anything.  Just cute.
<dodgerblue> hello all
<dodgerblue> do you have any idea how can i commit so i can get a partial version like <version>.1.1 ?
<dodgerblue> or <version>.1.2?
<bob2> why?
<dodgerblue> bob2: i just wanna know how
<bob2> ok!
<wgz> dodgerblue: that happens when you commit a merge of another commit
<dodgerblue> wgz: thanks :)
<jave> do I need to install the "colo" plugin if I want to try colocated branches in bzr 2.5?
<wgz> jave: nope, that's a different thing
<jave> okay. were can I find proper docs on colocated branches?
<jelmer> jave: there aren't any at the moment, colocated branches are still experimental in 2.5
<jave> ah well.
<jelmer> I think the main documentation is some emails to the mailing list at this point.
<jave> is colo branches usable at all in 2.5?
<jave> or should I wait?
<jelmer> jave: I wouldn't recommend it for production use
<jave> okay thanks,
<jelmer> if you're working on plugins etc and want to make them ready for colocated branches then it might be worth to have a look at them
<jave> no I just wanted to try out colo branches on the emacs repo
<vadi2> bzr viz's UI is very broken for me in 2.5.0. I can't scroll all the way to the top of the revisions history. Does anyone else have this?
<jelmer> vadi2: it's fine here
<jelmer> vadi2: what version of bzr-gtk is that?
<vadi2> 0.103.0+bzr792-1ubuntu1
<vadi2> This is what I can scroll up to: http://i.imgur.com/i7mBv.png you can tell it's not the latest one because the arrow button is still pressable. The only way I can get to the top is via the keyboard up/down buttons - and when I switch that way, it fails to scroll, but does select the revision properly/
<jelmer> vadi2: I would recommend filing a bug, I haven't seen any bugs about this issue before
<vadi2> alright
#bzr 2012-05-29
<mgz> morning all
<jelmer> hey hey mgz
<jelmer> re
<achiang> hello, a branch has a tag that shouldn't be there. i grabbed the branch from LP, deleted the tag, and tried to push the branch back to LP, but i see: "No new revisions or tags to push."
<achiang> any clues?
<asomething> --overwrite ?
<achiang> asomething: that didn't work
<wgz> achiang: that doesn't do anything, indeed
<wgz> you can do `bzr tag -d lp:foo --delete badtag` however if someone who has the tag pushes to that branch again it'll reappear
<achiang> wgz: interesting, thanks
<codeninjaSD> Looking into Bazaar as a possible SCM candidate for my company. Is there any detailed feature list available online bu chance?
<vadi2> I'm guessing http://wiki.bazaar.canonical.com/BzrFeatures ? First search result.
<veebers> Hi guys, this bug effects me (bzr notify window popping up): https://bugs.launchpad.net/ubuntu/+source/bzr-gtk/+bug/983830
<ubot5> Ubuntu bug 983830 in bzr-gtk (Ubuntu) "bzr-notify does not use unity progress bars" [Undecided,Confirmed]
<veebers> does anyone know of a fix or a work around?
<veebers> oh, that ubot5 thing is cool :)
<jelmer> hi veebers
<codeninjaSD> Can you access Bazaar directories/commits via internet browser?
<veebers> jelmer:  hi :)
<jelmer> codeninjaSD: yes, loggerhead allows you to do so
<jelmer> veebers: IIRC there are some fixes in bzr-gtk trunk that haven't been packaged yet, not sure if anything is progress bar related though
<codeninjaSD> jelmer: is that a plugin?
<veebers> jelmer: cool, I'll look into that
<jelmer> codeninjaSD: either a plugin or a separate app (it can work as both)
<codeninjaSD> nice!
<veebers> it's annoying that every time I do a push/branch etc. there appears a 'window' that is nothing but a status bar scrolling back-n-forth :P
<codeninjaSD> Does Bazaar over this use case: If a committer wishes to commit n files at once, either the commits to all n files succeed, or they all fail.
<codeninjaSD> cover*
<jelmer> codeninjaSD: yes, commits are atomic
<codeninjaSD> is there a page that references this type of info? I have quite a few requirements
<codeninjaSD> Thanks for that btw :)
<jelmer> codeninjaSD: I think the wikipedia page on VCSes has some of this info
<codeninjaSD> ok
<veebers> just fyi: this bug seems/is related: https://bugs.launchpad.net/ubuntu/+source/bzr-gtk/+bug/998131
<ubot5> Ubuntu bug 998131 in bzr-gtk (Ubuntu) "bzr-notify leaves a ridiculously-tiny window hanging around" [Undecided,Confirmed]
<jelmer> veebers: that does indeed seem related
<codeninjaSD> jelmer: Does Bazaar have the ability to attach searchable tags, other than revision number, to code artifacts
<jelmer> codeninjaSD: bzr supports tags for revisions, yes
<jelmer> I'm not sure if that's exactly what you mean though
#bzr 2012-05-30
<KombuchaKip> Need help badly. Had a branch on lp. Unbound from it, commit to a different remote branch, unbound from it, rebound to the original one on lp, preparing to merge the branches by running a bzr update when I got an bzr: ERROR: An inconsistent delta was supplied involving 'Documentation/Users/AresEngine', 'documentationuserare-20101114225801-1g0nlj1eao16kgii-13' reason: Unable to find block for this record. Was the parent added?
<bob2> bound branches :|
<fullermd> Eh, it's only documentation.  Doesn't seem important.
<KombuchaKip> That path, /Documentation/Users/AresEngine I had deleted between the unbinding of the lp branch and the rebinding of the new one.
<KombuchaKip> bob2 and fullermd: Not sure what to do.
<bob2> me either
<bob2> bound branches scare me so i do not use them
<fullermd> Do you have any important or difficult changes that aren't on one of the LP branches or the other?
<KombuchaKip> fullermd: The original lp branch didn't have much in it and lots of stuff was moved around and refactored.
<fullermd> But that's stuff you committed into the other remote branch, right?
<KombuchaKip> fullermd: Yes, the non-lp one.
<fullermd> Then I vote for "fugit".  Whatever you have locally is squirrely, but it doesn't contain anything you need to preserve, so just set it aside (JIC) and start over from your two remotes.
<KombuchaKip> fullermd: But I need to apply the changes from the non-lp branch, which I am comfortable deleting, into the actual lp one now.
<KombuchaKip> fullermd: Once I've done that, I can delete the non-lp one.
<fullermd> Right, but just start your local setup from scratch.  Make a fresh branch of each, and work from them.
<KombuchaKip> fullermd: What do you mean?
<fullermd> mkdir /tmp/x ; cd /tmp/x ; bzr branch lp:whatever LP ; bzr branch bzr+ssh://wherever/else OTHER ; cd LP ; bzr merge ../OTHER
<fullermd> (or the [im]moral equivalent)
 * KombuchaKip thinks
<fullermd> Just forget about your current local workspace; it'd be good to know what happened and how to fix it, but it's not essential.
<fullermd> Don't delete it, just in case it turns out you need something there, but you probably don't.
<KombuchaKip> fullermd: I'd like to use a centralized model, so should I replace the bzr branch with bzr checkout?
<bob2> I'd really recommend not using bound branches
<fullermd> I think that falls into "overthinking" in this case.
<KombuchaKip> fullermd: Ok
<fullermd> You're not trying to get a semi-permanent workspace going at the moment, just solve this particular problem and get code where it needs to be.
<fullermd> Once that's done and you can know you haven't lost anything, you can sit back and figure moving forward.
<KombuchaKip> bob2: For technical reasons or for philosophical cathedral vs bazaar reasons?
<KombuchaKip> fullermd: Right
<bob2> technical
<bob2> it's 2012
<bob2> no need to pretend you're using svn anymore
<KombuchaKip> bob2: Ok, so philosophical then.
<bob2> not using them makes everything simpler
<bob2> no, technical
<bob2> you're not using a centralised vc system
<bob2> so using your dvcs as a centralised system leads to technical issues, like merges being more annoying
<KombuchaKip> bob2: That's a matter of preference. Bzr can be used in a centralized model if one chooses to.
<bob2> of course it's a matter of preference
<bob2> but it makes things harder
<fullermd> OTOH, I like checkouts, and use them constantly.  I do hate bound branches, though.
<bob2> e.g. it lets you replicate the joy of svn making conflicts in uncommited changes
<bob2> joy
<fullermd> But at any rate, my offhand impression is that your issues probably stem from using a bound branch, but swapping around which other branches its bound to.  That sounds like a recipe for trouble; too many opportunities for confusion.
<fullermd> (above and beyond whatever weird technical corners you might get painted into)
<bob2> def feels like a bzr bug though
<KombuchaKip> fullermd & bob2: https://bugs.launchpad.net/bzr/+bug/855155 Looks like Bob's right. It is a bug.
<ubot5> Ubuntu bug 855155 in Bazaar "InconsistentDelta error when using bzr update" [High,Confirmed]
<bob2> ouch
<fullermd> Very probably; shouldn't be possible to get it twisted, all else being equal.
<bob2> 'bzr up' :(
<jono> hey folks
<jono> I accidentally committed a a revision to a branch in LP
<jono> how can I remove it?
<bob2> like "accidentally commited a root password" or "the tests don't pass yet"?
<fullermd> It would really be useful to nail down just what alteration triggers it; I see a lot of broad discussion there, but nothing that seems like a reproducible testcase.
<jono> bob2, more like the latter
<jono> I ran bzr uncommit and bzr push
<jono> should that work?
<KombuchaKip> fullermd: Ok, so I have run bzr merge successfully on the local lp branch. To "upload" those changes to the remote lp branch, do I just run bzr push? The reason I ask is I've been using bound branches all this time.
<fullermd> You'll probably have to `bzr push :parent` or the like, since it won't have a saved pushloc.
<KombuchaKip> fullermd: The :parent is an alias for the location of the pull? That being lp?
<jono> thanks!
<fullermd> :foo is an alias for the various saved locations.  The parent loc is where you branch'd from, and is the default for pull.
<KombuchaKip> fullermd: Right. So the command should be bzr push lp:mybranch ?
<fullermd> That would work too.
<KombuchaKip> fullermd: ok
<fullermd> But :parent was quicker to type   ;p
<KombuchaKip> fullermd: "Working tree has uncommitted changes. Uncommitted changes will not be pushed". So I need to commit first?
<bob2> yes
<fullermd> Oh, yes.  Sorry, I assumed you had.
<bob2> you always use 'commit' to commit changes
<bob2> to push changes somewhere beyond your local repository, 'bzr push'
<KombuchaKip> bob2 & fullermd: Thanks.
<fullermd> jono: No, push would just have nothing to do.  You'd have to --overwrite.  But you shouldn't, unless you can know for sure nobody's grabbed it.
<jono> I did
<jono> that
<jono> thanks!~
<fullermd> The rev has already been exposed to the world; unless you can be sure you eradicated every copy of it, it's just going to come back and bite you hard.
<qubodup> hello
<youlysses> o/
<qubodup> how would I go about deleting all files in a repo that are not tracked?
<fullermd> There's a clean-tree command.  You could start there.
<qubodup> thanks
<jimis1> I want to commit interactively chunks from a file that I select
<jimis1> like shelve but in the opposite direction
<jimis1> I can't find a way, is it supported?
<Peng> jimis: There was a bzr-interactive plugin, but I don't know if it's still maintained.
<jimis> thanks Peng, I was hoping something had made it to mainline :-p
<jimis> I remember I needed the same feature a year ago and was told it wouldn't be too hard, since most functionality is already in shelve
<Peng> That plugin is more than a year old. >.>
<jimis> yes I was talking about whether such functionalith had made it to /mainline/
<KombuchaKip> fullermd: So before I merged, I was at revision one hundred and something. After the merge I am at only rev 29. I guess the revision numbers are not cumulative after a merge?
<bob2> revnos are confusing at best
<bob2> since yeah they do move around
<mgrandi> they are relative to the branch
<mgrandi> so you probably see they are something like 28.1 -> 28.100
<mgrandi> or something
<KombuchaKip> mgrandi: Yup. Pretty much, which is kind of demoralizing considering how many revisions I commit over the last year...
<mgrandi> =P
<mgrandi> you can still do uhh
<mgrandi> bzr info -v
<mgrandi> inside the branch to see the TOTAL number of revisions in the repo
<mgrandi> like bzr has like 6000 something revisions, but the 'total' number of revisions (with all the sub revisions) is ... a lot more
<KombuchaKip> mgrandi: Right.
<KombuchaKip> mgrandi: What is the equivalent to 'bzr revno' for getting the full actual revision number?
<mgrandi> do you mean the revision id?
<mgrandi> like mark@example.comblahblhablha-time ?
<KombuchaKip> mgrandi: I guess so.
<KombuchaKip> mgrandi: No, like 6.123
<KombuchaKip> e.g. the revno that includes those made before a merge.
<mgrandi> as in you want the revno before a revision was merged?
<mgrandi> like rev 100 before it got to like 2.100?
<KombuchaKip> Yes
<mgrandi> i don't think there is a way to get that information as its all relative to the branch
<KombuchaKip> mgrandi: Ok, fair enough. I want to bind my local branch to a remote lp one that I pulled from, but getting a "Permission denied (public key)". I'm guessing some auth stuff needs to be setup.
<mgrandi> im not an expert on the bzr internals but i think its computed based on the tree of revisions
<mgrandi> and since you merged branch a into branch b, then the same revision object is in a different place in the tree
<KombuchaKip> mgrandi: Any way to get the revision number like 2.100?
<KombuchaKip> mgrandi: ok
<mgrandi> you probably need to set your ssh key in launchpad
<mgrandi> if you are getting that
<mgrandi> and yeah there is a way to get the revision number
<mgrandi> bzr log will show the entire history, or you can do bzr log -r <number>
<KombuchaKip> mgrandi: I think I already did that, created a key pair, and put the public id on my launchpad page.
<mgrandi> did you do bzr lp-login or whatever?
<KombuchaKip> mgrandi: I did, but not for this branch. I thought it was system wide, but I realize now that wouldn't make sense.
<mgrandi> it should be system wide
<mgrandi> it writes it to your bzr.conf
<KombuchaKip> mgrandi: Yes, indeed it is and it is correct.
<KombuchaKip> mgrandi: I have my ssh key listed correctly too (https://launchpad.net/~kip)
<mgrandi> what os are you on?
<KombuchaKip> mgrandi: Xubuntu 12.04
<mgrandi> you have to have your OS set up to use your key
<mgrandi> like putting your private key in ~/.ssh/id.rsa or whatever
<KombuchaKip> mgrandi: Hmm, it was working before when I had a bound branch. Yeah, that should be good already.
<KombuchaKip> mgrandi: How does it know which public key to use when binding?
<mgrandi> if there is only one then it just uses that
<mgrandi> you can set up ssh apparently to use different keys for different hosts
<KombuchaKip> mgrandi: Right. How can I test my auth without bzr, but just vanilla ssh?
<mgrandi> try doing ssh <username>@bazaar.launchpad.net
<mgrandi> it should connect and say no shells on this server then disconnect
<KombuchaKip> mgrandi: Right
<mgrandi> also, bzr testament will show you the revision id of a revision
<KombuchaKip> mgrandi: Trying to figure out which file in .ssh contains the private key
<KombuchaKip> mgrandi: Think it's id_rsa.1
<mgrandi> you can open it in a text editor or cat it and see which one says PRIVATE KEY
<mgrandi> its usually id_rsa
<mgrandi> id_rsa.pub is usually the public one
<KombuchaKip> mgrandi: I'm following this https://help.launchpad.net/YourAccount/CreatingAnSSHKeyPair#Using_a_custom_SSH_key_for_Launchpad
<mgrandi> yeah
<KombuchaKip> mgrandi: So should be id_rsa.1 ?
<KombuchaKip> mgrandi: Not sure if IdentityFile should be the public or private key.
<KombuchaKip> mgrandi: Wait, says private. So that should be right.
<mgrandi> yeah
<KombuchaKip>  mgrandi: debug1: Trying private key: /home/me/.ssh/id_rsa.1 debug1: No more authentication methods to try. Permission denied (publickey).
<mgrandi> you are doing username@bazaar.blah right
<mgrandi> your launchpad username
<KombuchaKip> mgrandi: Yes.
<KombuchaKip> mgrandi: Launchpad username should just be kip
<KombuchaKip> mgrandi: And trying to login with just $ ssh -v kip@bazaar.launchpad.net
<mgrandi> your permissions might be weird on the key
<mgrandi> but i dunno, usually that works =(
<mgrandi> try googling, dunno why its not working
<KombuchaKip> mgrandi: Me neither.
<mgrandi> i think #launchpad exists, can try there
<vila> KombuchaKip: if 'ssh -vv' tells you the key is not valid, you don't have the right public key uploaded to lp
<KombuchaKip> vila: debug2: key: /home/me/.ssh/id_rsa.1 ((nil)), debug1: Authentications that can continue: publickey, debug1: Next authentication method: publickey, debug1: Trying private key: /home/me/.ssh/id_rsa.1, debug2: we did not send a packet, disable method
<KombuchaKip> vila: nil?
<KombuchaKip> vila: $ ls -hs ~/.ssh/id_rsa.1, 16K /home/kip/.ssh/id_rsa.1
<vila> KombuchaKip: 'nil'rgins no bell, the '.1' is a bit suspect but probably harmless
<KombuchaKip> vila: Nevermind. I'm an idiot. IdentityFile contained /home/me/... instead of /home/kip/...
<vila> here you are :)
<vila> KombuchaKip: being an idiot is good and indicates you're walking on the One True Path :-D
<vila> I try hard to be an idiot at least twice a day :)
<KombuchaKip> vila: ;) It also reminds us that copying and pasting can be dangerous.
<vila> yeah, that lesson needs to be re-learned every day
<vila> :)
<KombuchaKip> vila: I keep getting asked for my passphrase to unlock '/home/kip/.ssh/id_rsa.1'. There must be some way to cache that at login.
<vila> yup, use an ssh agent
<vila> 'ssh-add -l' will tell you which keys are known by your agent
<vila> 'man ssh-add' for details
<vila> There was a bug long ago where you needed the ',pub' key along the private one to make the GUI work on ubuntu (dunno if that has been fixed since then)
<vila> '.pub'
<vila> the public key
<mgrandi> i know in gnome, you can make seahorse import your ssh key
<mgrandi> and then it will automatically ask you when connecting via ssh for the pass
<KombuchaKip> vila: Hmm, I'm not using gnome which I think used seahorse-daemon. I wonder what the standard way under xfce is?
<vila> yup, that's what I use (and where the bug was)
<mgrandi> good luck importing stuff into seahorse haha, its such a bad program
<mgrandi> i think it SHOULD look in .ssh/ for your key and use that
<mgrandi> i dunno on xubuntu
<vila> KombuchaKip: if all else fails, 'ssh-add key'
<KombuchaKip> vila: Yeah, the thing is I don't understand how ssh-add knows which daemon to communicate with?
<KombuchaKip> ssh-add -l
<KombuchaKip> The agent has no identities.
<spiv> KombuchaKip: via environment variables
<spiv> SSH_AUTH_SOCK or similar
<KombuchaKip> spiv: I guess I probably need to setup seahorse-daemon manually under xfce.
<vila> 'ssh-agent -s' displays the relevant env vars here
<vila> SSH_AUTH_SOCK, SSH_AGENT_PID
<KombuchaKip> vila: I see it is set, but I don't know which process is providing its socket file.
<vila> spiv: heya !
<KombuchaKip> vila: Got it
<spiv> (The idea is to run the agent early enough in your login process that you can set those environment vars for all processes in your sessions)
<spiv> vila: bonjour
<vila> KombuchaKip: as spiv says. Part of my 'startup applications' in gnome
<KombuchaKip> vila: So I have to some how get ssh-add to add my key some how.
<KombuchaKip> vila: Well, it looks like ssh-agent is already running, but I don't know what it does that seahorse does or not does.
<vila> if the agent has already started, yes. If it hasn't, you'll have to `ssh-agent -s` here and there
<mgrandi> ssh-agent is what gets used
<mgrandi> even with seahorse
<KombuchaKip> mgrandi: Alright. So I need to tell ssh-add to use my key from now on.
<mgrandi> just do ssh-add
<mgrandi> or err
<mgrandi> ssh-add ~/.ssh/id_rsa.1
<mgrandi> and then it will work
<mgrandi> you might have to put that in your .profile or whatever
<KombuchaKip> mgrandi: Yeah, I tried $ ssh-add ~/.ssh/id_rsa.1. That seems to work.
<mgrandi> there you go
<vila> KombuchaKip: setting up an ssh agent is worth the trouble
<KombuchaKip> vila: I think so too. Thanks mgrandi as well.
<vila> KombuchaKip: next step is to define the right keys for the right places
<KombuchaKip> vila: Right
<vila> but that can wait until tomorrow ;)
<KombuchaKip> vila: lol, for sure. ;)
<vila> KombuchaKip: http://pastebin.ubuntu.com/1014282/ is how you set a specific key for some hosts
<KombuchaKip> vila: Thanks.
<KombuchaKip> I wish lp blueprints could host files.
<vila> corrupted file in ~/.launchpadlib/cache leads to "interesting" udd import failures...
<mgrandi> i just found the command bzr graph-ancestry, except it doesn't seem to graph all the revisions for some reason =(
<mgz> morning all!
<mgz> reconfigure --use-shared is pretty dangerous
<jelmer> mgz: in what way?
<mgz> ...and naturally my small attempt to reproduce failed
<mgz> ah, I know what it was
<mgz> simple mistake, painful result: <http://pastebin.ubuntu.com/1014520/>
<jelmer> mgz: huh, that's an odd error - why doesn't it find the parent repository anymore?
<mgz> presumably we don't look when the ancestor is a branch not just a repo, but reconfigure is happy with any repo it find
<codeninjaSD> Does Bazaar have the ability to attach searchable tags, other than revision number, to code artifacts?
<mgz> as in `bzr help tag` kind of tags?
<Lo-lan-do> Hi all :-)
<Lo-lan-do> Question about bzr-git: is there a way to keep "bzr dpush" from pushing if the branches have diverged (ie, if a rebase is needed beforehand)?
<Lo-lan-do> Unrelated question: where can I read some user-oriented doc about colocated branches and how to use them?
<CodeNinjaSDJ> sorry, got disconnected. Did you see that mgz?
<CodeNinjaSDJ> tags as a way to search for artifacts/commits
<mgz> Lo-lan-do: two questions you want to bug jelmer on :)
<mgz> CodeNinjaSDJ: I'm still not sure exactly what you mean, perhaps you can give an example?
<Lo-lan-do> mgz: Yeah, I guessed, but he told me he's not working on bzr-git anymore, so I hoped to get some support from #bzr at large :-)
<CodeNinjaSDJ> we want to be able to search for artifacts in other ways besides using revision numbers
<CodeNinjaSDJ> like a way of catagorizing
<mgz> Lo-lan-do: indeed, but he'ss still the best repository of the current status of things. on colocated branch docs, we don't really have anything user-facing currently.
<mgz> CodeNinjaSDJ: what do you mean by artefacts though? revisions? files?
<Lo-lan-do> Could be bugs
<mgz> okay.
<mgz> so, you mean arbitrary revision properties.
<Lo-lan-do> (We call tracker items "artefacts" in FusionForge)
<mgz> bugs you can set up your own end point for
<mgz> other stuff is also possible, but not directly supported.
<CodeNinjaSDJ> files
<CodeNinjaSDJ> Does Bazaar have the ability to trim down history to say, the last three months worth of changesets.
<mgz> but a particular file in a particular revision? there doesn't seem much point just tagging files, that's what filenames are for.
<mgz> you can edit history, but it's generally discouraged. not committing binaries tends to be the answer people actually need.
<CodeNinjaSDJ> Well, we also want to use this as a reference tool. Say a developer is starting a project, he can go here to search to see if similar code has already been done
<mgz> that beyond the scope of any version control tool.
<mgz> you can grep across history with say, bzr-grep, but detecting similar code to something you want to write is AI-completish
<sdjninja> Sorry, keep getting disconnected for some reason
<mgz> sdjninja: so, it's still not clear if this is something you're envisioning devs adding for particular revisions, or a search that magically produces answers
<jam> vila: it looks like someone actually checks gpg signatures :)
<vila> jam: and ?
<jam> vila: you accidentally uploaded the 2.5b1 signature with the 2.5.1 tarball
<vila> ha, I never did *this* mistake before, my creativity has no limits...
<vila> hmm, so, what I should do, delete and re-upload ?
<mgz> it's a bdot.
<vila> mgz: lol, took a while to get it ;)
<vila> jam: who told you ?
<vila> I've deleted the bogus one and I'm re-uploading with the right sig
<jam> vila: it was on bazaar@
<vila> AFAIK, only people referring to it via it's librarian lp id will be impacted, fullermd will probably want to kill me ;)
<jam> I just downloaded and confirmed it
<bsd> hello all.  I'm trying to do 'diff -r branch:colobranchname' but bzr isn't resolving colobranchname.  I vaguely recall that abentley or someone wrote a little directory-like plugin to simplify accessing native colocated branches?
<jelmer> bsd: hi
<bsd> hi jelmer
<abentley> bsd: bzr+ssh://bazaar.launchpad.net/~abentley/+junk/nc/
<bsd> ah, great â thanks jelmer
<jelmer> bsd: no, thanks abentley :)
<bsd> thx abentley too ;-)
<abentley> bsd: np
<fullermd> vila: I'm killing who for what now?
<fullermd> vila: The source tarball is fine though, neh?  It's just the signature that's reuploaded?
<mgz> fullermd: it was fine, just gets reuploaded as part of the lp process
<vila> fullermd: 100% correct, but I seem to recall that you an alternate url to get it from the launchpad librarian, so the *content* is the same, but the librarian url has changed
<vila> s/that you an/that you use/ (/me becomes anti-mgz and remove words instead of using them twice 8-)
<vila> you use as !
<vila> no, in retrospect, no as
 * fullermd blinks.
<fullermd> It changes the tarball URL, even though it's not changed?
 * fullermd sighs.
<fullermd> Grumph.  OK.  Let me oil up my good killing bat and check flight times...
<vila> fullermd: ha ! At least I told you soon enough ;) Sorry about that, but I went with the fastest path (lp does not provide a way to dissociate a tarball from its sig while uploading (which isn't such a bad thing)). Just fix your redirection handler once and for all :-P
<fullermd> The general opinion is that it _is_ fixed   ;p
<vila> ha, cool, now we just have to fix the users then ;) . o O (Am I really fixable about mixing up sigs ?)
<fullermd> Oh, I'm sure you're fixable.  I've got some scissors here somewhere...   >:-}
<vila> To my defense, please note that this sig is valuable one, it still serves us well for 2.5b1 and.. it wanted to do a bit more... couldn't refuse
<fullermd> There are only so many bits in the universe.  You were just saving some.
<sarcasticCat> What does the command [bzr launchpad login] do when used w/o the argument?
<sarcasticCat> Does it return the login name?
<wgz> sarcasticCat: yes, if you use a dash rather than a space
<sarcasticCat> yah, a dash is what I meant
<sarcasticCat> what happens if no one ever logged in on that machine?
<sarcasticCat> any error will be thrown?
<wgz> prints "No Launchpad user ID configured." on stdout apparently
<wgz> really that should be on stderr or something
<sarcasticCat> I see. Thnks
#bzr 2012-05-31
<bignose> $ bzr merge
<bignose> bzr: ERROR: No location specified or remembered
<bignose> How can I tell Bazaar to use the parent branch in those cases?
<fullermd> bzr merge :parent
<bignose> this is a branch created with âbzr cbranchâ, if that matters.
<bignose> fullermd: can I make it so it will know that the first time, so I don't have to distinguish &"^first time I mergeî from âsubsequent times I mergâ in a branch?
<fullermd> Not short of code hackery.
<fullermd> Maybe it could be frobbed via a plugin...
<bignose> I seem to remember Bazaar knowing a default branch to merge from in previous versions.
<bignose> did that get deliberately removed?
<bignose> 'cause Bazaar usually guesses right in the absence of specifics, for many other operations.
<bignose> and this one seems obvious, to me.
<fullermd> I have vague recollection of merge falling through to parent loc, but I'm not sure if that's a real memory or not.
<bignose> ah, here's the problem: bzr: ERROR: No parent location assigned.â
<bignose> so perhaps I remember correctly about merge guessing correctly
<bignose> but now the parent is unknonw.
<bignose> maybe it does matter that âcbranchâ was used. shouldn't that set the parent?
<fullermd> No idea.  I've never used it.  I'd sorta think it would.
<fullermd> See what info says.
<bignose> info shows no parent location.
<fullermd> Seems like an odd thing to wind up with.
<fullermd> Mmm.  Pastebin the whole?
<bignose> whole what?
<fullermd> info output.
<bignose> fullermd: <URL:http://dpaste.com/753595/>
<bignose> thanks for spending time on this.
<fullermd> Blargh.  Bound breckout fallout, I'll wager.
<fullermd> Bet you'll see a parent branch on `bzr info :bound`
<bignose> fullermd: yes.
<bignose> âbound brecketâ?
<bignose> âbound breckoutâ?
<fullermd> The whole "bound branch" / "checkout" mess that I periodically rant upon.
<bignose> heh
<bignose> well, I no longer do checkouts
<bignose> but I do use âbzr branch --bindâ and âcbranchâ
<fullermd> Well, you do here   ;p
<bignose> so I guess it still falls in the scope of your rant
<bignose> fullermd: what information should I put in a bug report?
<fullermd> In this case, you're hitting the 'bound branch' behavioral side.  You want the parent that you made this branch from, but the 'branch' that you made (and has that info) is the one on the far side, whereas the 'branch' you're working on is your local bound one.
<fullermd> So your location aliases are resolving (or not, to be precise) there.
<fullermd> Which, I would argue, _is_ the correct behavior for a bound branch.  Though not for a checkout.
<bignose> ugh
<fullermd> So, I'm not quite sure it's actually a "bug" that's resolvable, short of "sort out the whole mess"   :|
<bignose> so, tell me what the bound branch and checkout distinction is here.
<bignose> which one do I have? or is it both?
<fullermd> Still, it's definitely a confounding behavior.  Maybe that's worth a bug report just to stake it down...
<fullermd> Well, it's bzr.  You have both.  Or, more precisely, neither.
<bignose> I think I have been convinced in the past by your rants, and stopped doing âbzr checkoutâ and started âbzr branch --bindâ instead
<bignose> but I want the UI of âbzr cbranchâ, so I continue to use that. is this confounding the problem?
<bignose> and what can I use instead, if so?
<fullermd> Well, I think the only difference between 'checkout' and 'branch --bind' is that the latter sets the remote to the parent location?
<fullermd> http://wiki.bazaar.canonical.com/MatthewFuller/BoundBranches  is something I wrote up a while ago when I was in the middle of one of my rants on the topic.
<fullermd> I should add something explicit about the locations too...
<bignose> fullermd: thanks for your help. <URL:http://bugs.debian.org/675297>
<ubot5> Error: debian bug 675297 not found
<bignose> ubot5: maybe not yet, but soon
<ubot5> bignose: I am only a bot, please don't think I'm intelligent :)
<bignose> ubot5: I need a friend.
<ubot5> bignose: I am only a bot, please don't think I'm intelligent :)
<mgz> morning all!
<vila> \o
<jml> just knocked up a silly plugin to measure how many LoC a branch introduces: lp:bzr-damage
<mgz> vila: I'm confused, I thought you did do the merge-up when releasing 2.5.1
<vila> no, I didn't, too many stable branches with conflicts
<mgz> darn.
<vila> the merges up should be done by the ones who land on old stable branches, not by the RM
<vila> *iff* there are no conflicts, I took the risk in the past that I won't introduce regressions by merging up. Here, there was conflicts that weren't trivial to my eyes, not mentioning they were different for each branch
<vila> the fact that bialix's patch was lost in the noise is a painful fallout :-/
<mgz> right, jelmer or me could have resolved it without too much complication, but needed some knowledge of the change
<vila> mgz: I *did* mention I wasn't merging up when raising the issue with conflicts last week
<vila> yeah, indeed, landing on a stable branch implies merging up
<vila> especially when conflicts are *expected*
<mgz> needed to be an action item like backporting the rmbranch fix, got lost while struggling to get pqm to actually land things
<vila> yeah, that one was more focused and relied on the same assumption: stable branches were left in a clean state
<vila> mgz: so, to come back to your original question, I didn't merge up 2.5 into trunk after freezing because the older stable branches were not clean
<vila> so the only part that would have been merged up was your backports which are already there
<jml> if I want a bzr plugin to have optional color output, is there a particular library I should use?
<jml> otherwise I'm going to plagiarize / depend on the color support in twisted.trial. nobody wants that.
<mgz> there's some code for colour in bzrtools
<jml> is it sensible for a plugin to depend on that?
<mgz> jml: probably not, but worth looking at, and to see what bzr-grep does, which may depend on it or do its own thing
<mgz> it's all pretty ugly I seem to recall
<jml> mgz: thanks.
<caravel> hi folks o/
<mgz> hey there
<caravel> Form reading http://doc.bazaar.canonical.com/bzr.2.5/en/user-guide/stacked.html I understand the point of --stacked-on, but not quite --stacked
<caravel> In the first --stacked example, where would `bzr push --stacked`push to ?
<mgz> whatever you're trying to do, stacking is probably not the right thing :)
<caravel> Is that also to the source-url given at first line (bzr branch)
<caravel> ?
<caravel> mgz: :)
<bsd> caravel: I don't think push supports 'âstacked', just 'âstacked-on'
<caravel> mgz: I'll expose my use case after that clarification :)
<caravel> bsd: well, that's not what the manual says at the above URL
<bsd> caravel: push has âstacked-on; branch has âstacked
<bsd> caravel: so I think your question is: on 'bzr push --stacked-on X Y` where does the push go?  I think  it goes to Y; Y is stacked on X.  But I've never tried it
<caravel> bsd: this is not true, it seems push has both:
<caravel> $ bzr push --help | grep stacked
<caravel>   --stacked             Create a stacked branch that references the public
<caravel>   --stacked-on=ARG      Create a stacked branch that refers to another branch
<bsd> caravel: geesh â I even did quickly look at that before replying.  Clearly need to get these glasses checked :)
<caravel> bsd: no worries, I often have that knd of bug myself :)
<caravel> so, the user manual matches the cli options, that is not he option
<caravel> that is not the issue*
<caravel> but I fail to understand, in the user manual example , where would `bzr push --stacked` ... push to ?
<bsd> caravel: my guess is that 'push âstacked X' is equivalent to 'push âstacked-on :parent X'
<mgz> caravel: the configured public location of the parent branch, is what the help says
<mgz> specifically:
<mgz> if stacked:
<mgz>     parent_url = br_from.get_parent()
<mgz>     if parent_url:
<mgz>         parent = Branch.open(parent_url)
<mgz>         stacked_on = parent.get_public_branch()
<mgz> ...and then falling back to parent_url
<bsd> ah, that's different from :parent
<caravel> mgz: but is that not what `bzr push`would do anyway, in that example ?
 * caravel really feels he's lacking to understand something
<caravel> note, in that user man page there are two examples, I am talking about the first one starting with a simple `bzr branch source-url my-dir`
<mgz> no, these commands create a branch that omits history present in the parent
<caravel> mgz: by parent, you mean the parent of the local branch i.e. in that example, "source-url" is the parent of "my-dir" right ?
<mgz> have to go now, building shutting
<caravel> Since the bzr push [LOCATION] is not specified, `bzr push` alone would push new revisions to "source-url"
<mgz> but overall it's more trouble than it's worth
<caravel> ^^
<caravel> So I don't understand what difference would `bzr push --stacked` make if no [LOCATION] is given
 * caravel will patiently pray for anyone to clarify this :)
<hexsprite> hey.. how do i check what revision my working copy is at? i tried bzr info but didn't seem to show thatâ¦ even with -v
<caravel> hexsprite: `bzr update`should tell you that (and proceed with any update if available)
<caravel> hexsprite: `bzr info -v` will tel lyou that too (without any action)
<hexsprite> mmm if i don't want to proceed?
<caravel> hexsprite: and there might be other commands which I don't know/use (I'm just a user)
<hexsprite> thanks caravel
<caravel> hexsprite: `bzr heads` might be what you are looking for, actually (it's a plugin from bzrtools)
<caravel> hexsprite: oh, no !!! :) you just want `bzr version-info`
<hexsprite> oh great
<caravel> hexsprite: thanks hexsprite, hadn't even found this one before (neither really needed, actually ^^)
<vila> hexprite (too bad you're gone :-/), caravel : 'bzr revno --help', in some cases you will prefer 'bzr qlog' from the qbzr plugin
<vila> caravel: you'll get all the details starting at cmd_push in bzrlib/builtins.py
<vila> caravel: but I'm in full agreement with mgz: you probably don't want to use that. It's needed in an edge case where you want to have some access rights applied to the history of a branch. Most of time, there are better ways to organize history sharing.
<fullermd> There really should be something in the docs there that says "ignore this section unless you're Launchpad".
<lduros> I forgot again, how do I get bzr to generate a source directory, the kind that you want to tar
<lduros> like a source package, from a branch
<lifeless> bzr export
<lduros> lifeless: thanks much!
<lduros> :-0
<lifeless> will export a revision
<lifeless> or if you're using bzr builddeb, bzr bd does that all automatically as part of the build
<lduros> hmm neat
<lduros> it builds a deb package?
<lifeless> very much so :)
<lduros> that sounds very helpful
<lduros> I'll try that very soon :-D
<caravel> vila: thank you for your answers
<caravel> vila: revno and even version-info, were not "spontaneous" to locate. I had looked at info, status just like hexprite I guess, but I can guess why it's good as it is now :)
<caravel> vila: maybe they could be listed in basic commands help ?
<caravel> vila: cf. stacked, ok I'll take your and mgz advices (and take note of the details location, will investigate later, then)
<caravel> vila: essentially, my use case is not very specific and well described here  http://doc.bazaar.canonical.com/bzr.2.5/en/user-guide/organizing_branches.html i.e. per-team/user/task branches on a central server to ease sharing, but all "mirrored" locally so that "some of us" can merge things
<caravel> vila: from the stack description, --stacked-on was making a lot of sense to me : being one of the mergers (and having brought everyone to bazaar..) I have a local shared repo holding all the mirrors. So I thought I should use this if I wanted e.g. to setup a workspace on a distinct local volume
<caravel> I understand that in our case it would be pointless to use that on the central server (where all branches are within a shared repo, without working tree, pretty standard I guess)
<caravel> (althought  I wioder if I shouldn't actually use it to protect some of our branches -- anyway we can live without that so far)
<caravel> vila: so as a temp conclusion, I guess I'd agree with fullermd : manual should expand a little more about its pros and cons, maybe ? Is that also discouraged for local usage as I suggested above, i.e. with mirrors and workspaces located on a distinct local volumes ?
<caravel> located on* distinct, seperated
<fullermd> Dunno why you'd even consider it locally, unless your branches are gigantic and you have very limited and very slow storage.  For that matter, it may well make it worse with slow storage since it'll blow the cache.
<vila> caravel: I f you already have a shared repo, you're done. Nothing can beat it.
<vila> caravel: if you want to organize your working trees differently, that's another story, but stacking in only between branches and repositories.
<caravel> fullermd: vila by "distinct local volumes" I mean mount points, or eg. drive letters in Wind'Oz wonderland
<caravel> So that the mirrored  share repos would be located under a "third party" disk space, excluded from backup between other things, while the actual workspace stacked on it would be under the daily/personal data space. Does it not make any sense ?
<caravel> (I mean, a local disk space dedicated to "third party" stuff, versus another one dedicated to "own contribs" stuff)
<caravel> but yeah, I guess symlinks are my friends and provide the same result :)
<caravel> huh, no actually
 * caravel 's last comment about symlink was really silly, time to pull off for today I guess
<caravel> so , iis that not a good reason to use stacks ? or am I still missing the point ?
<fullermd> I don't really understand your usecase (and don't have time to really try to grok it, sorry), but I can't say it sounds overly desirous of them.
<fullermd> And that to one side, I've never heard of anybody but LP using stacking and having a good experience from it.  If indeed LP is having a good experience...
<thumper> lifeless: morning
<thumper> lifeless: here is a question for you, what do you see the benefits of signing commits as
<thumper> lifeless: and do you expect it?
<Larsibarsi> Hello, I am a little confused about the different setups available, and I would like to ask if someone can point me to the right workflow setup for our workflow. I red already some of the docs, but feel unsure which one of the described workflows fits best to the one my colleague and me have established.
<hbeck> what would be the appropriate method to update (pull or merge?) changes from a SVN repo into my bzr copy of that repo, to which I've made some changes?
<hbeck> I'm trying "bzr merge svn+https://poco.svn.sourceforge.net/svnroot/poco/poco/trunk" but it seems to think it needs to wholesale replace every file or something
<Larsibarsi> Me and Peter both work on the same web site. Since we use a content management system that uses a database it is not practical to copy all stuff to local, so we both would edit the files directly on the host server. And the server doesn't allow SSH-connections or something similar - it would be a dump bzr-server. For keeping track of the changes and having an easy way to revert changed files I want to use bazaar... Where shall the main repo
<Larsibarsi> sitory reside, and how can we use it then?
<jave> hello
<jave> i was trying out "bzr bisect" and now the branch is in a weird state. how can I restore it?
<lifeless> thumper: hi
<lifeless> thumper: projects that want to detect attempts to alter their history need commit signing.
<anes> hi guys, I want to learn about bazaar, what does it actually mean?
<lifeless> jave: bzr revert probably
#bzr 2012-06-01
<thomi> Hi, I'm trying to get bzr to sign my commits, and it seems to work *sometimes*. Other times it prints:
<thomi> You need a passphrase to unlock the secret key for <key details>
<thomi> but doesn't launch gpg-agent or ask me for the passphrase
<thomi> and then completes the commit without signing it.
<thomi> any ideas? I've had it work once, right after logging in...
<lifeless> how do you know it does not sign it?
<thomi> lifeless: uhhhhh... that's a good point. That message seems like a warning
<thomi> how do I tell?
<thomi> I thought it would show something in the log.
<lifeless> if bzr gets a error back from gpg it will cancel the commit
<lifeless> I'm not sure of the current state for showing what is or isn't signed
<caravel> hmm, annotate is fine with utf-16le, but qannotate entirely fails :/ (and kate or others, have no issues). Even if forcing the encoding, qannotate seems to try using utf32 or something, that results in two lines for a 300k file .)
<caravel> Interestingly, forcing utf16-be looks "almost great" (except it's kinda in the wrong order) :D
<caravel> in qlog, view or show differnce say the file is binary :/
<mgrandi> is the file binary?
<caravel> mgrandi: no :D it's utf16-le (little endians)
<mgrandi> does bzr (command line) say the diff is binary?
<mgrandi> or the file is
<caravel> (and kate or others, have no issues)
<caravel> mgrandi: no, bzr annotate is fine
<mgrandi> interesting
<mgrandi> i thought explorer would use the bzr api so it should be the same
<mgrandi> report a bug!
<caravel> yep, hence my surprise :) I was hoping someone would know that bug, it's very late and I'm  falling :)
 * caravel is on gmt+2 at the moment
<mgrandi> i feel like
<mgrandi> its just trying to decode the file using utf-8 + other encodings
<mgrandi> and when it fails its saying "oops its binary"
<caravel> mgrandi: yep
<mgrandi> wait
<mgrandi> in qlog
<mgrandi> there is an 'encoding' dropdown
<mgrandi> did you try seeing if there is utf16le?
<mgrandi> err qdiff
<caravel> mgrandi: yes, there is :) first guess was utf-8 actually
<mgrandi> does that make it show the diff properly?
<caravel> mgrandi: I knew the format so I tried drop-down, fan cooler did spin :)
<caravel> mgrandi: nope, diff says its binary
<caravel> well, qdiff
<caravel> let me try diff :)
<caravel> standard `file`cli gets it right too : Little-endian UTF-16 Unicode C++ program text, with CRLF line terminators
<mgrandi> well i meant
<mgrandi> did qdiff show it properly when you selected utf16le?
<mgrandi> or did it still say it was binary
<caravel> bzr log seems ok
<caravel> mgrandi: sorry I'm tired, wasn't clear in my communication
<caravel> log and annotate are fine
<caravel> qlog and qannotate are not, it's only the qt toolset
<caravel> so, qannotate first did autoselect utf-8 (but I'm not sure if it guesses anything, it days it's default)
<mgrandi> its probably not QT itself, just the qannotate and qlog programs
<caravel> forcing encoding in qannotate drop-down, or via cli parameter, fives the same result
<caravel> mgrandi: oh yes, I'd doubt the whole qt libs wold have such a bug :) I run under KDE and use quite a few apps based on qt :)
<caravel> so, and other bzr q* tools don't seem to permit changing the format, they just say it's binary
<mgrandi> wierd
<caravel> mgrandi: according to Kate, file has no BOM (Byte Order Mark), not sure what q* tools rely on ? I've known the early days of Unicode, that was a big thing at the time :)
<mgrandi> utf-16 require a byte order mark.
<mgrandi> requires*
<caravel> mgrandi: hmm are you sure ? last time I felt asleep on unicode.org was a long time ago :) Kate says there is none, but is happy with it
<caravel> mgrandi: well, optional or not, actually it *is* there ! Just open the file in okteta, I can recognize the thing as if I had invented it myself
<mgrandi> it should have one because it can be either big or little endian and without it , it has no way to tell
<caravel> (so, for some reason Kate says there is none, but there is one, it's only a checkbx anyway in Kate/Tools menu)
<caravel> mgrandi: yes right
<mgrandi> weird
 * caravel is a strong advocate of putting a BOM everywhere even if not needed, but hey, RECs are full of must, should and might ^^
<caravel> anyway, FFFE it is so it's 100% correct :)
<mgrandi> *nods*
<caravel> mgrandi: fyi : Â« Clause D98 of conformance (section 3.10) of the Unicode standard states, "The UTF-16 encoding scheme may or may not begin with a BOM. However, when there is no BOM, and in the absence of a higher-level protocol, the byte order of the UTF-16 encoding scheme is big-endian." Â» https://en.wikipedia.org/wiki/Byte_Order_Mark#UTF-16
<caravel> mgrandi: but anyway, that's off-topic now, sory :)
<caravel> sorry*
<mgrandi> so, file a bug against bazaar explorer =P
<caravel> mgrandi: yes :) will do tomorrow.
<caravel> mgrandi: unfortunately, I can't easily test later versions (running 2.x as latest on Fedora repos)
 * caravel meant 2.4.x, as opposed to 2.5 if there were any q* updates since
<mgrandi> ah
<caravel> ok that's qbzr 0.21.1 (sorry, I'm "landing" really, never looked at these details before, only used all this)
<mgrandi> go to bed =)
<caravel> .bug 668850
<ubot5> Launchpad bug 668850 in QBzr "`bzr qdi --encoding xxx` is broken" [Medium,Confirmed] https://launchpad.net/bugs/668850
<caravel> well no, it doesn't look related :/
<caravel> ..bug 416645
<ubot5> Launchpad bug 416645 in QBzr "better support for UTF-16 in qdiff, qannotate, qcat" [Medium,Confirmed] https://launchpad.net/bugs/416645
<caravel> yeah !
<caravel> that0s the limits of the "guessing by contents"  strategy I guess (didn't know, and wouldn't have guessed that it was dong so !):D
<caravel> good night mgrandi and all, thanks for answering anyway
<mgrandi> night =)
 * caravel Long Life to the BOM !!!!
<awpti> Hi folks. I've just started using Bazaar <like, half an hour ago>. Been searching since then on how to setup bazaar explorer to work with LaunchPad, but I can't find any tutorials or info on how to tell it what to connect to (let alone a config option that implies such). Only one I've found that's remotely similar abruptly switching to some ubuntu client half way through the tutorial. What am I
<awpti> missing?
<bob2> likely you just want to clone an lp url
<bob2> and that's about it
<awpti> I'm trying to push code to a new repo
<awpti> There is no documentation on how to do any of this.. at least, that's useful. I figured out through trial and error that it's lp:~user/proj/trunk, but now it wants me to do some launchpad-login stuff, can't find anything on it for windows.
<fullermd> I dunno if there's a lp-login interface in explorer.  But you can always just run it from the CLI I imagine.
<vila> hi all
<vila> awpti: dunno about explorer (I don't use myself), but from the command line it's 'bzr launchpad-login <launchpad-username>'
<vila> awpti: more on that: https://help.launchpad.net/Code/UploadingABranch and https://help.launchpad.net/YourAccount/CreatingAnSSHKeyPair
<mgz> morning
<fullermd> Oh.  Must be bedtime.
<mgrandi> haha
<mgrandi> exactly.
<mgz> :D
<mgrandi> mgz: the #bzr alarm clock
<vila> morning mgz
<Larsibarsi> Hi, I need a hint for a correct workflow setting: me and Peter work together from two different offices. We work on a CMS driven website, both on the files and the mysql db that is hosted on the host server - this is why a local version of the project is not working. I can access the host server via FTP, and I want to put these files under version control. How can I do this with bazaar?
<Larsibarsi> I have red the tutorial, but I could not fit this setting to any setting that was described in the doc.
<LeoNerd> Aaaand once again  bzr up  breaks my branch. Is there a way to ask for  bzr up  to keep the old behaviour, wherein it would just abort on divergent history? Now, it rearranges for a pending merge. I dislike this immensely
<LeoNerd> I want to rebase it in that case
<mgz> use pull?
<mgz> Larsibarsi: nothing in your story sounds like a problem, you and peter probably just want a branch you collaborate on that's seperate from the actual deployment over ftp
<mgz> if you're interacting only on the live code, that's asking for breakage if you need to resolve conflicts
<Larsibarsi> mgz: I'm not sure if I understand you right: you propose that we collaborate on a branch that is not the live code branch? Then we wouldn't see the results of our coding, unless it is committed and pushed to the live code branch, did I get that right?
<mgz> right, I'd suggest you have deployment as a seperate step
<mgz> so, you've got one branch you can both merge to, and then on agreement (or just whenever the merge is clean), you then use bzr-upload or similar to make it live
<Larsibarsi> for a real live system this would be very 'healthy'. In our case we are working on the same development system so we don't need this extra step yet (later for sure).
<Larsibarsi> Having a branch to collaborate sounds like "we both have our own development system with database and files" to make our little changes in the HTML and CSS, and if we have a change, we do it locally, commit it and then it is exchanged, right?
<mgz> not nessersarily
<mgz> I mean, you're doing text editing locally right?
<Larsibarsi> But we have only one central development system where the files can be changed...
<mgz> so having a copy of all the code is something you've got, just not any test setup?
<Larsibarsi> We copy the file locally, change it locally, and upload it after saving.
<mgz> well, you can do that, with the risk that you can break it each other (which I guess happens anyway)
<Larsibarsi> :) We are good in avoiding these break dangers.
<mgz> the only complication is you can't just push over ftp
<mgz> you need to push, and update the working tree, or do those two things as seperate operations
<Larsibarsi> How would I make a change in a file, e.g. adjusting a CSS-margin from 15pt to 18pt? I change it locally, commit it locally, push it to the server (somehow) and now I can see the result? This is how I understand it right now...
<mgz> right, so that's correct, but the push needs to be in two bits
<mgz> one to update the branch so when peter pulls he sees your change
<mgz> and one to update the css file itself
<mgz> you can combine with some automation
<mgz> also, the case where you and peter have both made changes, the second guy to push will get an error (good thing, you don't lose work) and will need to merge in the other changes before pushing
<mgz> with two people that's not overly painful, there are better ways of structuring work when there are more simultanious edits
<Larsibarsi> yup... But actually this is to much steps for a little change (and try and error)... Is it possible to work on the server, change the css file on the server, and when the change is done I commit the file on the server to the branch on the server somehow via ftp?
<mgz> heh.
<mgz> yes, but only having ftp makes that hard.
<mgz> also having two people maybe doing that at once is also complicated.
<mgz> so, reversing it,
<Larsibarsi> Well, I guess Peter won't do that so often since I am the IT guy and he is the designer... :)
<mgz> (the normal way would be) your branch -> production branch -> deployment
<Larsibarsi> preparing some lock mechanism will be not too hard, I guess...
<mgz> you could do instead: deploy -> your branch -> production branch
<mgz> so, you cowboy things via ftp on the server, copy down any changes you make to your local branch, commit, and push to a shared location
<Larsibarsi> the shared location to push to would be the production system when it works, right?
<mgz> nope. it's what you'd export to deploy to production.
<mgz> you need a shared location so peter can pull your changes into his local branch, rather than getting out of sync as the scratch deployment is altered with your changes.
<Larsibarsi> Ah, okay... And I commit my changes and Peter commits his changes, and the local branches are in sync over the shared location push... And if Peter doesn't like this approach I can still do it on my own...
<Larsibarsi> I thank you very much for your time and your thoughts, mgz, it was enlightning! :)
<mgz> right, so you (as you'll find it easier) just need to merge from the shared location when peter commits something
<vivekimsit> I have an error doing the bzr commit --local
<vivekimsit> bzr: ERROR: Selected-file commit of merges is not supported yet: files sale_order.py
<vivekimsit> how can I recover from it?
<vila> vivekimsit: the error message seem to imply you did 'bzr commit --local file' that's not supported if there are pending merges
<vivekimsit>  vila: Ya! how to undo my merge proposal?
<vila> vivekimsit: 'recover' can have several meanings there, what is your working tree status ('bzr st'), how did you get there
<vila> and where do you want to go
<vila> you mean 'merge attempt' ?
<vivekimsit> vila : actually I did the bzr commit which led me to this, and I have checkout a branch I have done changes on it. And now its showing my latest rev as a merge!
<vila> pending merge, right, that is indeed probably what you want,
<vivekimsit> doing bzr status shows: unknown:
<vivekimsit>   bzr_log.Py3GXe
<vivekimsit>   bzr_log.Py3GXe.save
<vila> !paste
<ubot5> For posting multi-line texts into the channel, please use http://paste.ubuntu.com | To post !screenshots use http://imagebin.org/?page=add | !pastebinit to paste directly from command line | Make sure you give us the URL for your paste - see also the channel topic.
<vila> can you paste 'bzr info -v' ?
<vivekimsit> vila: I don't want any merge, I just want to do push, I have did it several times but only this time I commit this mistake
<vila> if you want to push, you'd better not use a checkout but  a regular branch no ?
<vila> if you can't push, it means someone else did, so you can't just push your changes, you need to merge the other changes first
<vivekimsit> vila: ok! so now I just have to run the command bzr push location
<vila> no, you need tp get your working tree/branch clean first
<vila> to get
<vila> can you paste 'bzr info -v' ?
<vivekimsit> vila: http://bpaste.net/show/7H7ARDebXu3XkgtjDmwH/
<vila> right, so since you created your working tree from lp:~synerpgy/synerpgy-projects/destock_dev/, someone else pushed something there
<vila> now, you're trying to commit
<vivekimsit> yes!
<vila> bzr checks that your checkout is up-to-date, it's not
<vivekimsit> vila: help me what to do?
<vila> so it made your local commit a pending merge and pulled the other change
<vila> just 'commit' no --local
<vila> meh
<vila> you can't commit because you made a checkout with http://bazaar.launchpad.net/~synerpgy/synerpgy-projects/destock_dev/ instead ofbzr+ssh://bazaar.launchpad.net/~synerpgy/synerpgy-projects/destock_dev/
<vila> http doesn't provide write access which is needed to commit
<vila> paste 'bzr config' ?
<mgz> probably just need to do `bzr launchpad-login`
<vivekimsit2> vila: till now u told everything correct! It says unknown command "config"
<vila> well, the push_location is set, so probably launchpad-login was done in the past
<vila> urgh, 'bzr version' ?
<vivekimsit2> vila: what command I should type now?
<vila> bzr version
<vila> 'version' is a bzr command
<vivekimsit2> vila: its 2.2.4
<vila> hmpf
<vila> what os are you using and can you upgrade to a more recent version (2.2 is.... old, 2.5 is the current stable)
<vivekimsit2> vila: hm, see I can't upgrade just now! is there any alternative?
<vivekimsit2> one more thing there is more serious problem
<vivekimsit2> when I push I get : http://bpaste.net/show/OPRCzXjGFsm7MFxySYaY/
<vila> vivekimsit2: it's harder for me to debug such an old version, I'm can't remember which bugs where not fixed there ;)
<vila> s/I'm/I/
<vila> wow, can you 'ssh -vv bazaar.launchpad.net' ?
<vivekimsit2> vila: http://bpaste.net/show/rdTWWVZngtEOl3q6VKy2/
<vila> vivekimsit2: there you go, ssh should succeed first, here you seem to not be able to even reach b.l.net
<vivekimsit2> vila: hmm
<vivekimsit2> vila: what should I do now?
<vila> is your lp id vivekimsit2 ? If not, use ssh -vv <your-lp-id-here>@bazaar.launchpad.net
<vivekimsit2> vila: I am getting the same error
<vivekimsit2> vila: don't know but till yesterday everything was working fine
<vila> vivekimsit2: it's related to your network connection
<vivekimsit2> vila: hmm..
<vila> given you 'bzr info' output, bzr use ssh to connect to lp, you can reproduce (and debug) that with 'ssh -vv', hence, bzr is not the culprit there
<vila> it's (like you) the victim :-/
<hbeck> I'm trying to merge into my bzr copy of a svn repo (I 'forked' their repo) using "bzr merge svn+https://poco.svn.sourceforge.net/svnroot/poco/poco/trunk" but the merge preview is looking like it is doing an entire delete/add replacement of every file...what's up there?
<mgz> hbeck: you didn't keep a clean copy of the upstream locally?
<mgz> might be useful to just branch it and look at the history to see if the issue is present there or just related to the merge.
<hbeck> mgz: you mean a copy of the initial point at which I created the bzr repo from my checkout of the svn repo?
<mgz> right.
<mgz> I suspect that was a one-time import, rather than a normal branch? how did you do it?
<hbeck> unfortunately I wasn't the one who did the initial import...is there a way to see what command was used in the log somehow?
<mgz> if so, that generated a bunch of file-ids, which are not the same as what bzr-svn uses when just doing a branch
<mgz> hbeck: in the log on the machine that did it. otherwise, it can probably be inferred from the details of the revisions
<mgz> but you're probably best off posting to the mailing list about it
<hbeck> anything enlightening in this? http://dpaste.com/754228/
<hbeck> revision vs svn revno seems important somehow
<mgz> hbeck: compare the output of `bzr version-info --include-file-revisions LOCATION` on both your local branch, and the remote one
<mgz> hbeck: will be big, pipe it to a file
<hbeck> mgz: saw that after I ran it, heh
<hbeck> mgz: I still get mixed up with bzr terminology, when you say local and remote branch, you mean...? I have a checkout of our bzr repo I am using to try to do this merge with the svn trunk
<mgz> right, once on your bzr repo, and once on the svn trunk
<hbeck> ok
<mgz> if it doesn't work on svn trunk directly, `bzr branch` it locally, then run it on that
<hbeck> ok
<frathgeber> afternoon, all
<hbeck> morning :)
<frathgeber> is there a known way to make bzr fast-im/export properly recognize ancestry relationships?
<mgz> frathgeber: eyes glazing over, try asking on the mailing list for a useful answer
<frathgeber> scenario is: a bzr shared repo i.e. collection of related branches and i want to make that interoperable to a git repository
<frathgeber> problem is: any changes made in git lose their ancestry relationships when pushed back to the bzr shared repo
<frathgeber> mgz: ok, i'll try that. i appreciate that's not an easy problem
<frathgeber> but i think it's crucial to make the fast-import format meaningful
<frathgeber> if it only works at a per-branch level it's rather useless
<mgz> sounds basically the same as hbeck's issue, an import to bzr generates file-ids
<mgz> but bzr-git doesn't know about what those were, right?
<hbeck> mgz: really? didn't think mine would be that complex. What's weird with what I'm seeing right now is that we've done a merge with the same command I put above before, and it behaved ok
<mgz> so you can't then use it to move revisions between the bzr and git repos
<mgz> hbeck: you might be lucky then, and was just bzr-svn specific
<mgz> anyway, really needs some jelmer expertise and he's not around today.
<frathgeber> just /joined, so will have to read up in the logs
<frathgeber> but they seem to lag behind quite a bit
<mgz> yeah, only updated every hour
<hbeck> mgz: no I mean literally the same - we did the initial bzr repo 'creation' and then used that command to merge from the svn repo. Not sure why it's behaving differently now...but again I didn't do that merge either so lacking the previous experience
<mgz> well, a problem solved is a solved problem :)
<vila> frathgeber: as far as I understand it, if you use bzr (and bzr-git) you can interoperate with git repositories, you seem to be doing the opposite (push to bzr repos from git)
<frathgeber> exactly, i'm using git-bzr-ng (which is unfortunately horrendously unstable)
<frathgeber> it works by keeping a shared bzr repo and mirrors the git repo back and forth using fast-im/export
<frathgeber> and that's when i'm hitting the issue i.e. when i push to bzr and sync back it doesn't recognize commits are shared between branches
<frathgeber> it always rewrites revision id's on export it seems
<mgz> right, I think the ids aren't deterministic, so I'd be suprised if that worked
<frathgeber> incidentally it also doesn't preserve timestamps
<frathgeber> mgz: yep, that's what i suspected
<mgz> they just get generated on the import/export, unlike bzr-git which has a scheme
<frathgeber> which imho essentially means fast-im/export is broken for anything but single branch use cases
<mgz> they're not designed for repeated use as I understand it, no
<mgz> there was some other git-to-bzr thing as well, I forget what it was called
<frathgeber> hmm, that gets me thinking: can i use bzr-git "backwards"?
<frathgeber> that should work, shouldn't it?
<mgz> yup.
<mgz> as in, operate on git branches locally and push to bzr.
<mgz> hbeck: did you get the version-info output for both branches, and they had the same fileid then?
<frathgeber> i do an intial import using fast-import and then instead of pushing from git to bzr via fast-export (which is what git-bzr-ng does), i pull to a bzr repo using bzr-git
<frathgeber> oh, but how do i pull changes into the git repo then? that won't work
<hbeck> mgz: working on it, having to bzr branch from the svn repo and it is being extremely slow
<frathgeber> tricky...
<vila> frathgeber: you push to git with bzr-git (or dpush)
<frathgeber> ah, ok, that may work then
<frathgeber> so for the initial setup
<frathgeber> can i also create the git repo via push from a bzr branch?
<frathgeber> so assuming i have a shared repo with loads of related branches
<frathgeber> can i create the git repo by pushing from trunk? and then push all the other branches into that git repo as well?
<frathgeber> so essentially the git repo wouldn't actually be aware it's "fed" from bzr?
<vila> frathgeber: that's my understanding (but for full disclosure, I have no first hand experience there)
<frathgeber> vila: cool, i'll just try it out
<vila> no, AIUI, the git server thinks it's talking to a git client
<vila> the bzr-git client takes care of the needed housekeeping (which, again AIUI, is achieved by dpush which does: push to git, get the revisions back, replace the pushed revisions by the pulled ones)
<vila> I don't remember precisely if dpush should still be used or if it has been integrated with the core push
<vila> frathgeber: jelmer is authoritative and will correct me if/where I'm wrong (but he's in vacations these days)
<frathgeber> ok. does is work in reverse? i.e. can a git-enabled bzr repo receive pushes from git?
<frathgeber> vila: how do you mean? jelmer is allowed vacation? ;)
<vila> frathgeber: yeah, I don't get it either ;)
<frathgeber> you should bzr branch him before he leaves next time ;)
<vila> frathgeber: I don't know the git eco-system enough to tell you what is the equivalent of the bzr-git plugin, I'm not sure it even exist
<vila> hehe, branching him will only give us his history, what we really want is his working tree ;)
<frathgeber> LOL
<vila> (the one populated with all his clones ;)
<frathgeber> vila: the closest thing to bzr-git i could find is https://github.com/termie/git-bzr-ng, but it's fundamentally broken in that it uses fast-import
<vila> yup
<frathgeber> and as you pointed out that is that not the right tool for the job (TM)
<vila> well, for some value of 'fundamentally broken' in 'limited features'
<LeoNerd> bzr on sshfs to a remote FreeBSD machine == slooooow :(
<LeoNerd> Not quite sure why.. does it do lots of temporary stuff via the local filesystem?
<mgz> don't do that then? :)
<LeoNerd> Well it's either this or try to install bzr on the FreeBSD box without being root
<mgz> you just want to put the branch on the bsd box?
<LeoNerd> No, I'm developing code there.
<mgz> I'd install bzr for my user if trying to version things on a remote machine
<mgz> get the 2.5.1 tarball, unpack, python setup.py install --user
<mgz> then not mess around with dodgy network filesystem things
<mgz> then again, bsd is weird, maybe life is more painful, fullermd would know.
<fullermd> I don't know anything particular that would make it unexpectedly slow.  I wouldn't think sshfs would need much help to be slow in that sort of usage.
<fullermd> As a user, I wouldn't install bzr, I'd just run it out of the tarball.  Simpler.
<fullermd> But better for the admin to just install it.  I don't maintain the port just for my health, y'know   :p
<mgz> fullermd: right, the health benefits are are bonus
<mgz> right, four day weekend time
<vila> LeoNerd: With my RM hat on (but not involved downstream), using the FreeBSD port of bzr is a good as it can be, you'll get the stable series and dot releases in due time.
<vila> LeoNerd: And quite frankly, using sshfs, no matter how good it can be, is just asking too much. bzr use different strategies for local and remote fs to take latency into account so there is no way you can beat bzr+ssh with bzr+sshfs
<vila> LeoNerd: You'll have to update your remote wt though, but bzr-push-and-update should take care of that for you
<vila> LeoNerd: if you need to uncommit, don't forget push --overwrite
<fullermd> push-and-update won't help if there's no bzr on the remote end, which is kinda the premise of the whole discussion   :p
<LeoNerd> There is indeed no bzr on the other end, which is why I was doing this. bzr co / update / etc... over sshfs
#bzr 2012-06-02
<Dov_Rine> i'm following the wiki tutorial on migrating an existing project to a shared repository, but having a problem specifying an alternate port to sftp.  According to the man page for sftp, it should be: sftp -oPort=<new port>, which works for the sftp command, but bzr chokes on it
<Dov_Rine> can anyone tell me the correct way to do: bzr init sftp://centralhost/repo/project on a port other than 22?
<Dov_Rine> is it the same thing if I ssh into the remote server, create the project directory and then run bzr init inside it?
<mgrandi> hmm
<Dov_Rine> mgrandi: what's up?
<mgrandi> well you had a problem right
<Dov_Rine> mgrandi: yes, but it didn't seem like anyone here was going to help, so I'm googling some more and testing ssh workarounds
<mgrandi> well patience hehe
<mgrandi> not everyone is here right now , let me see
<Dov_Rine> at some point, though, i'll have to find a real solution b/c i expect that checkout and commit will probably fail, too
<mgrandi> so you want to ssh with a different port, yes?
<Dov_Rine> mgrandi: patience is not a weak point of mine, but there wasn't any activity in here at all after 10 minutes
<Dov_Rine> yes
<Dov_Rine> but not ssh
<mgrandi> yeah, sftp
<Dov_Rine> sftp as in: bzr init sftp://etc/etc
<mgrandi> bzr uses paramiko
<mgrandi> so its not the same as the sftp command you are using
<Dov_Rine> ok, let me look that up
<mgrandi> i'm looking into it too
<mgrandi> one sec
<Dov_Rine> it looks like paramiko is a python object
<mgrandi> yeah its a library
<mgrandi> trying to find the -O options
<mgrandi> https://bugs.launchpad.net/bzr/+bug/146715
<ubot5> Ubuntu bug 146715 in Bazaar "bzr+ssh broken for non standard ports." [High,Fix released]
<mgrandi> says that just having the port in the URI should work fine
<mgrandi> so...sftp://bob@example.com:23 should work?
<Dov_Rine> mgrandi: thanks, i'll try it.  one sec
<Dov_Rine> mgrandi: it works
<Dov_Rine> mgrandi: thanks
<mgrandi> yay =)
<mgrandi> enjoy bzr
<Dov_Rine> mgrandi: that will be true for all of those options, right?
<Dov_Rine> mgrandi: checkout, commit, etc
<mgrandi> yeah
<mgrandi> if you bind a branch to a url then all of those stuff should work
<Dov_Rine> mgrandi: thanks.  have a great weekend
<mgrandi> ^v^
<Dov_Rine> by the way, running bzr init isn't exactly the same when run locally as remotely
<Dov_Rine> when run locally, it created an additional dir called checkout in project/.bzr
<mgrandi> its probably because when you are doing it remotely, it defaults to --no-trees
<Dov_Rine> mgrandi: that makes sense
<Dov_Rine> when i commit files to a shared repository, are the files themselves transferred to the repo or just the history?
<mgrandi> well the history is used to create the files
<mgrandi> so, i dont think it really matters
<mgrandi> either way you get your files back if you need to
<Dov_Rine> mgrandi: should I be able to see the files on the remote server if i run: ls /project_folder ?
<Dov_Rine> mgrandi: bzr log and update are both telling me that everything is ok, but I don't see any files on the server
<mgrandi> like i said before, its probably defaulting to no-trees
<mgrandi> so the data is there, but inside the .pack files
<mgrandi> inside the .bzr folder
<Dov_Rine> mgrandi: ok, i just want to make sure that this is the normal state of things
<mgrandi> yeah, if your branch is bound to the remote server
<mgrandi> or if you commit locally then push, they should be there
<Dov_Rine> the branch is bound to the remote server and all of the messages indicated that the remote site was updated.
<mgrandi> so there you go =)
<Dov_Rine> the .pack file seems to be large enough to correct
<mgrandi> binding means it won't succeed if it can't commit to both the server and locally so you are fine
<Dov_Rine> is it safer to have the repo store the tree, too?  it seems like it would be easier to recover the files that way
<Dov_Rine> like that in the worst case scenario, you lose the history, but still have the most recently committed files
<Dov_Rine> am i just looking at this incorrectly?
<Dov_Rine> can i have multiple identities in bzr?
<Dov_Rine> sorry, never mind, I found it in the docs
<mgrandi> it doesn't matter if it has the tree, you just branch it again
<Dov_Rine> mgrandi: ok, thanks
<evillyEvil> Does anyone know what the differences between "bzr unknown" and "bzr st"
<evillyEvil> ?
<evillyEvil> The two commands always list what's knew, right?
<evillyEvil> *new
<beuno> evillyEvil, unknown, as I understand it, are files that haven't been versioned by bzr
<beuno> status tells you what files have changes
<beuno> and what unknowns there ar
<beuno> *are
<evillyEvil> beuno: So [bzr st] actually covers [bzr unknowns], right?
<beuno> evillyEvil, yes
<jimis> jave: you can use colocated branches with no plugin installed, that's how I work some time now (bzr 2.3 I think)
<jimis> 1) you create a local repo storing only metadata, not data:
<jimis> bzr init-repo --no-trees .
<jimis> bzr branch $BRANCH_URL
<jimis> 2) you create a local lightweight checkout in another dir:
<jimis> cd $CHECKOUT_DIR
<jimis> bzr checkout --lightweight $LOCAL_REPO_PATH
<jimis> 3) you do all your work in the $CHECKOUT_DIR, using "bzr branch -b" to create new branches and "bzr branch" to switch to existing ones.
<jimis> This is a nice workflow, the whole /colocated/ terminology is unnecessary and the need to install a plug-in is false.
<jimis> IMHO it should be documented in the primary documentation, the rumor a plug-in is needed is driving users away.
#bzr 2012-06-03
<jimis> which algorithm does bzr use to compress .pack files?
<jimis> is it gzip/bzip2 or something?
<jimis> does it spawn an external process to decompress or it uses a C module from within the same process?
<jimis> it bogs down my CPU and I must find out why...
<wgz> it's zlib, in process
<wgz> compression just takes work, there aren't magic fixes
<jimis> hmmm so I guess it could be related
<jimis> wgz: there are fixes, not magic ofcourse
<jimis> wgz: the .pack files I assume the contain many small compressed chunks. About how large is each?
<jimis> I'm asking because I notice too much seeking too
<jimis> I've already filed a bug report, I'm just looking a bit more into it
<wgz> right, most of the obvious issues are much higher level than the comprssion step
<jimis> probably true, but if it reads through the *whole* pack files then it would take some time to decompress .5GB
<bob2> ?
<bob2> there's an index file next to it
<jimis> bob2: saw it, but still when stracing it I see too many reads, I think it's seeking through most of the file...
<jimis> I should measure exactly how much it reads from disk
<wgz> decompressing an entire pack when only part of it needed may be a bug, that decompressing a big chunk of data takes cpu isn't :)
<jimis> wgz: that's why I was asking about the comression
<jimis> first, if it was spawning separate gzip processes then it would use a second core
<bob2> except that if the decompression is the bottleneck like oyu say, that's of no use
<jimis> second, there are faster algorithms from gzip, with other tradeoffs of cource
<bob2> have you read the pack format docs?
<jimis> true have to find out how much it reads :-p
<wgz> I'd suggest that's the wrong end to tackle things from
<bob2> +1
<jimis> bob2: only a generic doc is what I found
<bob2> no idea what that means
<jimis> pointer to the pack docs?
<wgz> for something like bug 1006194 I'd start by seeing if it's opening the repo twice
<ubot5> Launchpad bug 1006194 in Bazaar "bzr diff too slow (cpu intensive) on large projects" [Undecided,New] https://launchpad.net/bugs/1006194
<wgz> rather than assuming zlib can be improved on or trying to launch multiple workers
<jimis> wgz: how can I see it?
<jimis> and why would it be opening it twice?
<jimis> bob2: http://doc.bazaar.canonical.com/latest/developers/packrepo.html is the doc I found
<wgz> because the bug states that it's an issue when there are two different branches are involved
<jimis> but didn't mention anything about compression algorithm
<jimis> wgz: even with same branch but -r-2 overhead is the same
<wgz> also see the mailing list archives about log performance
<jimis> latest quarter?
<wgz> jimis: eg. <https://lists.ubuntu.com/archives/bazaar/2011q4/073729.html>
<jimis> thanks wgz, seems relevant
<jimis> Even though these points may apply, bzr log -r-2 is instantaneous in my case.
#bzr 2013-05-27
<Stavros> hello
<Stavros> how active is bzr development, in general?
<jelmer> hi Stavros
<Stavros> hey jelmer
<jelmer> Stavros: see the mailing lists and http://code.launchpad.net/bzr
<Stavros> oh i don't want anything too official, it's just my favorite scm and i'm just trying to gauge if it's active generally
<Stavros> jelmer, what would you say, more or less?
<Stavros> the repo looks active
<jelmer> the short answer I guess is that it's a lot less active than what it used to be, but there are still people working on it
<jelmer> there were a couple of patches that landed in the last week
<Stavros> hmm, why do you think it's less active than before? lack of popularity?
<Stavros> i hate how git is so much more popular, even though nobody can actually use the damn thing
<jelmer> Stavros: I wrote a long blog post about that a while ago: http://www.stationary-traveller.eu/pages/bzr-a-retrospective.html
<Stavros> ah, that's what i'm looking for, thank you
#bzr 2013-05-28
<JoshTriplett> I'm trying to understand how to submit my local changes as a mergeable set of commits rather than as a patch.  I tried "bzr commit --local" of my changes, supplying a commit message, and then I tried to use "bzr send -o temp" (with and without specifying the local and remote branches explicitly).
<JoshTriplett> I keep getting "Bundling 0 revisions."
<JoshTriplett> What have I missed, and how do I tell bzr to include my local commit?
<JoshTriplett> Oh, hmmm.  Nevermind, it seems like I misunderstood what it meant by "submit branch" and "public branch".  I interpreted the former as "the repo I want to submit" and the latter as "the public repo I want to submit to", which was completely backwards.
<JoshTriplett> Apparently it actually means "the branch to submit to" and "the 'public' repo I'm sending from", even though the latter is actually only on my local system.
<JoshTriplett> Is there a conventional name for "bzr send" output?  *.bzr?
<bob2> bundle
<JoshTriplett> bob2: Ah.  Thanks.
<mathrick> hiya
<mathrick> whatever happened to 2.6 being released in august 2012?
#bzr 2013-05-29
<jam> lifeless: thanks for the reviews. I'm happy having you look directly at dirstate changes.
<jam> you certainly have the most experience with it, I'm probably #2
<lifeless> jam: I wouldn't want to assign ranks :) - but yeah, happy to.
<lifeless> jam: feel free to ping me with such things if I miss the review
<jam> lifeless: not ranking as much as while I feel strong with dirstate I think you still have more specific experience with it
<lifeless> jam: heh; I rather suspect you've got more experience with it now; its been what 3 years? since I was active in that area.
<jam> lifeless: to be fair, it is close to 2 for me. I went onto U1DB for 6 months, came back onto MaaS for 6, and now on juju-core for 6+
<jam> it has been fun to dig into it a bit again
<jam> a bit of deep-thinking on bugs people run into
<jam> we've already fixed most of the shallow stuff :)
<lifeless> yeah
<lifeless> I regret the complexity
<lifeless> I think it could be written much more simply with equivalent performance, in C.
<lifeless> I sometimes get tempted to put a proof of concept together.
<lifeless> Then I come to my senses :)
<bob2> ahahaha
#bzr 2013-05-30
<moremadness> Win a campervan http://goo.gl/5tZ7T
#bzr 2013-05-31
<doctormon> I'm writing a bash script, I wish to say if [ bzr-can-see-new-remote-revision ]; then; bzr pull; fi
<doctormon> But I don't know how.
#bzr 2013-06-01
<Stavros> hello
<Stavros> if you do revert -r -3, how does bzr know you're on an old revision to avoid backing up the file when reverting to the latest rev?
<bob2> won't
<bob2> what are you trying to do?
<Azendale> So, I think I might be doing something wrong because stuff seems harder than it should be
<Azendale> I have a project that I'm working on, and try to make a branch for each new feature. This sometimes means that I end up having a branch of a branch, etc. (Which could probably be shown as a tree)
<Azendale> The problem I have is that every (sub) branch has it's own folder in one main folder regardless of what it is a branch of, and I'm having a hard time knowing what came from what. This has caused problems when I finish a feature, and merge it into what I think is it's parent, and then merge that fix into the parent of that. Somewhere along the line I mess up because I don't know how the branches are related
<Azendale> This causes problems where I later then try to merge two branches and they have conflicts because I've applied the same finished feature to then since the were branched from each other
<Azendale> I've tried reading the documentation on the various repository formats, but I'm getting confused, and I'm not totally sure what questions to ask
<Azendale> I guess I'm wondering if there is some way to organize the branch hierarchically, but still be able to switch between working on various branches?
<Azendale> If it helps, I'm the only one working on this at the time, so major reorganizations are not out of the question
<Azendale> Or maybe there's a way to have the branches be a tree of folders, and then have a totally separate folder that is a workspace that you can copy the current version of any of the branches to to work on? I'm mostly guessing here
<Azendale> Ok, think I may have found part of it http://doc.bazaar.canonical.com/beta/en/user-guide/shared_repository_layouts.html#nested-style-project-branch-sub-branch
<Azendale> Is doing a checkout and then an unbind the same as branching?
<jelmer> Azendale: yes
<Azendale> jelmer: Ok, thanks
<Azendale> So, from reading the docs, I think I realize that I've just been using branches and not a repository. If I create a new repository, is there a way to import a branch to it?
<jelmer> Azendale: just clone it into a local inside of the repository
<Azendale> jelmer: As I understand it, that would be the branch command (docs say clone is an alias?) I'll try it, thanks :)
<jelmer> Azendale: yes
<Azendale> jelmer: Thanks for the help, I think I see how to fit the pieces together now. (Set up a no trees repository, make branches in hierarchies inside that, then make a separate working tree location to work with that is a checkout of the branch I want to work on)
<jelmer> Azendale: that should work
<jelmer> it's a lot more complicated than how most people use bzr though, including myself
<Azendale> how do most people who do feature branches keep track of what is a parent of what?
<jelmer> each branch has a pull_location that is generally set to its parent
<Azendale> I see. I think I was messing that up by rsyncing between two computers so the locations were becoming invalid. I think I'll avoid doing that in the future though
#bzr 2014-05-26
<spiv> Agreed.
<SamB> hmm, without --dry-run it gives me some crap about a nonnumeric port, when that's actually not port at all
<SamB> hmm, "bzr log -p -rsubmit:.." includes a revision I didn't really want in its output ...
#bzr 2014-05-28
<hazmat> is there a way to do bzr status if on a non HEAD revision
<lifeless> hazmat: what do you mean 'on a non HEAD revision' ? status is a tree operation...
<hazmat> lifeless, i do bzr up -r 42  && echo foo > README  && bzr status
<hazmat> lifeless, i get back.. update to run status
<hazmat> lifeless, its a simple operation via the api.. but i wanted to run it with the cli
<hazmat> lifeless, basically i want workingtree/copy status .. but the cli refuses to work when on a non head revision
<lifeless> how very odd; status should be well defined for any tree state like that
<fullermd_> Sounds like you've got something squirrely, since it works fine here...
<fullermd_> % bzr stat
<fullermd_> working tree is out of date, run 'bzr update'
<fullermd_> modified:
<fullermd_>   README
<lifeless> possibly a change since my time :( possibly oversight ? or squirrels :>
<fullermd_> Though that reminds me that I need to double check that I filed that bug about status an !workingtree cases $YEARS ago...
<hazmat> lifeless, http://pastebin.ubuntu.com/7539216/
<hazmat> which i try to workaround via the api doing..         tree = WorkingTree.open(self.path)
<hazmat>         return tree.has_changes()
<hazmat> fullermd_, oh..
<fullermd_> That all looks fine.  "working tree out of date" isn't an error that's stopping things, it's just a warning displayed along the way.
<hazmat> fullermd_, cool
<mgrandi> thats how you tell if a tree has changes? i couldn't find that it seemed lol
<fullermd_> (and there're no changes at that point, so it doesn't have anything else to display)
<hazmat> fullermd_, the message through me that it wasn't
<hazmat> working, but your right it is
<mgrandi> thought you had to get a TreeDelta
<fullermd_> If it's a small change, you'll need a TreeEpsilon instead.
 * fullermd_ goes back into hiding.
<mgrandi> lol
<lifeless> hazmat: so that tree has (correctly) no delta in it
<mgrandi> but where is tree.has_changes() defined? i dont see that in tree or working tree
<lifeless> hazmat: at the end echo bar > readme again and then do st again
<lifeless> mgrandi: its on the delta object I think
<mgrandi> doh
<mgrandi> there it is
<mgrandi> working trees were confusing to get a delta from, but i managed to figure it out
<mgrandi> except has_changes() doesn't report if it has unversioned files, hmm
#bzr 2014-05-29
<vila> hazmat: 'bzr stat -r<x>' 'bzr stat -c <x>' ?
#bzr 2014-05-30
<hazmat> can we get bzr uploaded to pypi
<hazmat> currently installing bzr from pypi requires rather inane arcana of
<hazmat> pip install bzr --allow-external bzr --allow-unverified bzr
<hazmat> which means it can be declared a dep for anything else in pypi, cause pip will barf without it
<lifeless> hazmat: I suggest filing a bug and/or mailing list comment, since its likely that noone involved in the release process saw your request.
 * hazmat files a bug
<hazmat> oh.. someone beat me to it
<hazmat> the last 3 bugs in bzr are the same..
<lifeless> hah
<hazmat> lifeless, you have upload rights to bzr in pypi :-)
<lifeless> huh
<lifeless> thats stale :)
<jelmer> hazmat: you probably want jml or vila
#bzr 2015-05-26
<brendand> hey, anyone here can help me undo the mess i made of my projects trunk?
<brendand> i accidentally pushed an unmerged branch to it, then in my panic i uncommited and did a push --overwrite
<brendand> the branch in question is lp:ubuntu-system-tests
<fullermd> In general?  Probably not easily.  In specific?  Maybe fairly easily, if you know where trunk was, rev-wise.
<brendand> lets assume i don't know right now, any way i can find out?
<fullermd> Locally, via heads.  It _probably_ works remotely, but I'll bet it's unbelievable slow and beats the snot out of the network and server.
<fullermd> If you had an up to date trunk locally, I'd start there.
<brendand> i don't think i did - at least heads is not being very helpful. it just shows one revision
<brendand> tried:
<brendand> bzr heads lp:~canonical-platform-qa/ubuntu-system-tests/trunk
<brendand> bzr: ERROR: Server sent an unexpected error: ('error', 'TypeError', "_makeBranchTransport() got an unexpected keyword argument 'private'")
<brendand> it was indeed private at one point
<brendand> but long before the mistake
<fullermd> You probably want heads --dead.
<fullermd> It may be that stacking or something else LP does internally makes heads not work over a transport to it.
<brendand> is there a way i can copy what's on launchpad locally? this doesn't seem to work
<brendand> even with --dead-only
<fullermd> You'd need to copy the whole repository.  There's probably a way to do it API-wise, but I'm pretty sure there isn't UI-wise.
#bzr 2015-05-27
<jskulski> Can someone try to branch pyroom for me? I'm getting an error but want to double check its not just me (2.7.0, linuxmint) bzr branch lp:pyroom'
<jskulski> I'm getting a Revision not in tree error
<fullermd> Branched 213 revisions.
<fullermd> 0.985u 0.224s 0:08.16 14.7%     5+170k 62+1534io 14pf+0w
<jskulski> Thank you fullermd, what version are you running
<fullermd> Head of bzr.dev.
<fullermd> Same result with 2.6.0.
<jskulski> ok, let me try to grab a newer version then, thanks!
#bzr 2016-05-30
<capum> hello?
<capum> what happen to rabbitvcs? is it dormant?
#bzr 2016-06-01
<gingitsune> How can you change the remote?
<gingitsune> remote user
<gingitsune> currently its diff user@url
<gingitsune> and i need to make a checkout with my user
<gingitsune> Also is there a way to check the current remote?
<gingitsune> bzr+ssh://centralhost/srv/bzr/PROJECT/trunk
<fullermd> You could set the user in the URL.  Or in ssh config, if you prefer.
<kdub> if i'm pushing a diverged branch to a remote, why wouldn't --overwrite work?
#bzr 2017-06-01
<dorian_> Hey there. I hit 'bzr revert' by mistake. Some file were backed up under the file.d.~#~ convention. Some were not. Do you know if I can find the missing backup files ?
<LeoNerd> 'revert' tries to check if the outstanding edit is due to a 'merge' or similar operation
<LeoNerd> I.e. something that didn't involve human effort to create and can be rebuilt by applying the same operation if necessary
<dorian_> LeoNerd, like unshelve ?
<LeoNerd> Ah.. mmmm
<LeoNerd> Yes that tricky little cornercase ;)
<dorian_> are the unshelved patch stored somewhere ?
<LeoNerd> I don't know what happens to unshelve'd changes, whether that is preserved somewhere
<LeoNerd> Last time I looked I couldn't find one
<dorian_> where can I find help about this ? I might have lost a day worth of work
<dorian_> I want to make sure before starting over
<LeoNerd> Take a look under the  .bzr/checkout/shelf directory and see if there's leftover files in there
<dorian_> nope
<fullermd> An unshelved change should be the same as a manual one; bzr doesn't know where it came from...
<mgz> dorian_: pastebin the log section of the failed unshelve operation?
<mgz> everything should generate conflicts/orig files, except when shelve breaks badly
<dorian_> mgz, the unshelve operation didn't fail. It's the revert operation which didn't make backups
<mgz> pastebin that then? revert always makes backups of files that actually have changes in them
<mgz> also, it's a good habit to just make checkpoint commits in a work branch, even when experimenting
<mgz> it's pretty easy to pull them out into neater branches later
<dorian_> there is nothing is the log of the revert operation which is out of the ordinary
<dorian_> the return code is fine also
<dorian_> I hope bzr doesn't actually do the revert operation if it doesn't make backup successfully :/
<mgz> hm, did were you discarding a pending merge at the same time?
<mgz> I mean, I'm not sure how you have a days worth of uncommitted changes and decide to type revert, but trying to understand what actually went wrong
<dorian_> It's ok. I resigned and accepted that my work is lost. I won't stop using bzr since it's my boss choice either -__-
<mgz> I'd like to know what you did and help it not happen again
 * LeoNerd (also suggests commit-early commit-often, but knows that doesn't immediately help the current problem :/ )
<mgz> but I need an actual log to have any idea
<dorian_> I wasn't at the latest revision. I had local changes. I hit revert
<dorian_> no backup to be found
<dorian_> maybe it comes from that
<LeoNerd> Ah, for that situation I always shelve / pull / unshelve
<LeoNerd> Treat revert as "Throw away my changes". Those "backup" files are just for accident recovery
<dorian_> thanks for you help anyway
<mgz> hm, I still get a backup file in that case.
<jvelasquez> how could I see a list of everything managed by bzr?
<jvelasquez> got it.  bzr ls -V
<fullermd> You may want -R too, depending on the meaning of "everything".
<jvelasquez> ohh. yea! thanks.
