[00:26] <cr3> how can I create a branch from a previous revision? I tried bzr revert -r### and then bzr push'ing that code, but the pushed code contain the same as the trunk
[00:28] <poolie> cr3: bzr branch -r1234 . ../other
[00:28] <poolie> igc, do you think we still want the non-sphinx doc builds?
[00:28] <poolie> i'm working on this atm
[00:31] <cr3> poolie: excellent, thanks!
[00:32] <lifeless> cr3: if you want to push something somewhere, push -r xyz URL
[00:44] <poolie> igc: sphinx build seems to be passing in the chroot now
[00:44] <poolie> output not copied yet
[00:44] <poolie> thwack- well up to the point of wanting pdflatex
[00:55] <igc> poolie: I don't see a need for non-sphinx builds
[00:56] <poolie> k
[00:58] <meoblast001> would it be hard for me to modify bazaar to only let me uncommit twice daily?
[00:59] <lifeless> not at all
[00:59] <lifeless> write a plugin, decorate the command
[01:00] <meoblast001> lifeless: ok, i need to make it hard for me to find a way around it
[01:00] <meoblast001> i'm struggling with a mental condition
[01:01] <meoblast001> and after reading an article, i figured out that i need to limit how many times i can repeat operations in order to fix the condition
[01:06] <maredzek> hi i have a very basic question, i would like to use bzr for managing my symofny project, it is now on local, i want to push it to my sftp server, do i have to do anything on my server? like installing bazaar?
[01:07] <jelmer> maredzek: to push using sftp you just need a sftp-capable ssh server
[01:07] <jelmer> maredzek: no bzr server is necessary on the server side
[01:08] <maredzek> ok i have one, i used:
[01:08] <maredzek> arek@marek-laptop:/var/www/fakt$ bzr push --create-prefix sftp://admin@91.121.177.88/var/www/ble --use-existing-dir
[01:08] <maredzek> but apart from .bzr dir i cannot see anthing in /var/www/ble....
[01:09] <jelmer> maredzek: it will just create a branch, not a working tree
[01:09]  * maxb wonders if anyone else has used bzr qlog on branches with 10000 revisions before
[01:09] <jelmer> maredzek: yes
[01:09] <maxb> It appears to trim revnos to 4 digits :-)
[01:09] <jelmer> s/maredzek/maxb/
[01:09] <jelmer> maxb: IIRC there is an open bug about that
[01:10] <maredzek> how can i upload "working tree"?
[01:10] <jelmer> maredzek: you can either run 'bzr co' on the remote side (will create a working tree, but required bzr to be installed)
[01:10] <jelmer> maredzek: or you can avoid push and use the 'bzr-upload' plugin
[01:10] <jelmer> maredzek: that will just upload the contents, not any of the history
[01:10] <spiv> maredzek: if you want just the tree and not the history, e.g. to publish a website, then the bzr-upload plugin jelmer mentions is probably a better fit
[01:11] <maredzek> ok, so if i will have 3 people working on this project, it is better to use bazaar on remote side?
[01:13] <maredzek> what will happen if:
[01:13] <maredzek> there is a file action.class.php already on sftp server, commited with bzr-upload
[01:14] <maredzek> then devA adds two funstions in this file and uploads
[01:14]  * maxb can't find a qbzr bug for that
[01:14] <maredzek> hwo devB coulc know that somebody modified that file?
[01:14] <maredzek> ok, dont answer that
[01:15] <maredzek> i would like to have smth like my launchapd
[01:15] <maredzek> i have to isntall bzr on server
[01:15] <maredzek> and init projects
[01:15] <maredzek> and also i need to install bzr on clients
[01:15] <maredzek> and checkout and commit from them right?
[01:19] <maredzek> how can i install bazar upload?
[01:21] <spiv> maredzek: if you are using ubuntu, you can just apt-get install bzr-upload
[01:22] <spiv> maredzek: http://doc.bazaar-vcs.org/test/en/user-guide/plugins.html
[01:26] <maredzek> ok so my quewstion, how should i use bazaar if i have a couple of developers, working now remotely on clients server
[01:40] <poolie> igc: ok i think it's all running aside from pdf generation which is waiting on a gsa
[01:41] <poolie> maredzek: http://doc.bazaar-vcs.org/latest/en/user-guide/index.html
[01:41] <poolie> igc, i'm going out to run an errand and then will look for breakage (which likely exists) when i get back
[01:42] <poolie> pdfs are rt 36401 btw
[02:20] <meoblast001> lifeless: is it possible to completely remove the uncommit feature from bazaar?
[02:20] <meoblast001> as long as repeating things is possible, i'll be stuck in an infinite loop
[02:21] <lifeless> meoblast001: sure, a plugin could do that
[02:21] <meoblast001> lifeless: i need something that is very hard to disable
[02:21] <meoblast001> i'm fighting myself here, so i need to outsmart myself
[02:21] <lifeless> meoblast001: sorry, can't really help you there - seriously.
[02:22] <meoblast001> i'll try to find something out
[02:22] <lifeless> bzr --no-plugins will disable plugins
[02:22] <lifeless> apt-get install will restore a base bzr with the feature present
[02:24] <meoblast001> lifeless: maybe i just need to see a psychologist or suck it up and figure things out myself
[02:28] <spiv> meoblast001: maybe something less drastic than total removal would help, e.g. make uncommit trigger an annoying buzz sound?
[02:29] <spiv> meoblast001: anyhow, writing a plugin is probably going to be the best way to do any of these options.
[02:29] <meoblast001> spiv: that won't work
[02:29] <meoblast001> i'm trying to fight OCD (repetitive things) and it can get very bad
[02:29] <meoblast001> luckily i don't have a severe case, some people do things for hours on end
[02:30] <meoblast001> i can just sit uncommitting and recommitting multiple times until i have to hit myself
[02:30] <meoblast001> but a buzzing sound won't stop me
[02:30] <lifeless> meoblast001: so, if I thought I had something wrong with me, I'd go see a doctor ;)
[02:30] <meoblast001> i need to make it impossible
[02:30] <meoblast001> lifeless: but you're not a dependent
[02:47] <maredzek> i dont completely understand Distributed development
[02:48] <maredzek> can you confirm is it corrct?
[02:48] <maredzek> 1. on main server
[02:48] <spiv> maredzek: in the user guide?
[02:48] <maredzek> spiv - yup:
[02:48] <maredzek> 1. on main server - i create bzr with init
[02:48] <maredzek> add and commit
[02:48] <maredzek> right?
[02:49] <spiv> maredzek: it doesn't really matter how you create the branch on the server
[02:49] <maredzek> ok, so next
[02:49] <spiv> maredzek: it's probably simplest to create it locally and then 'bzr push' it to the server
[02:49] <maredzek> ok
[02:50] <maredzek> but when i push to server - server needs to have bzr right?
[02:50] <spiv> maredzek: nope
[02:50] <spiv> maredzek: you can use plain SFTP, for instance.
[02:51] <maredzek> ok but when i tried to push files from my machine to my server, only .bzr folder was created
[02:51] <maredzek> no files were pushed
[02:51] <spiv> Right.
[02:51] <maredzek> and i need to use uplaod plugin
[02:52] <maredzek> so if i create file slocally and push to server, i will have no files in it - right?
[02:52] <spiv> Because 'bzr push' pushes a branch, which is a line of development.  But it sounds like you want/need the tree of files on the server.
[02:52] <maredzek> hmmm
[02:53] <maredzek> i'm starting to understand
[02:53] <spiv> Operations to do with branches and operations to do with trees of files are mostly separate things.
[02:53] <maredzek> so i will have 3 developers
[02:53] <maredzek> they will work on php framework - symfony
[02:53] <maredzek> they will have thoose installed locally
[02:53] <spiv> Some operations involve both, e.g. "bzr commit" takes the current tree and records that as a new version on a branch.  But mostly they are separate concepts.
[02:54] <maredzek> so tell me, how files will travel between developers?
[02:54] <maredzek> via central server?
[02:54] <maredzek> or directly between devs?
[02:54] <spiv> For you, I think you perhaps want to think about "commit and share changes" as being not necessarily the same as "deploy changes to live web site"
[02:55] <maredzek> i was thinking about this kind of architecture
[02:55] <maredzek> 3 devs (bzr) -> central repo (bzr) -> live web serwer (no bzr)
[02:55] <spiv> Sounds reasonable.
[02:56] <maredzek> last arrow - only from time to time
[02:56] <maredzek> like after completeing milestone
[02:56] <spiv> Right.
[02:56] <spiv> You could use the bzr-upload plugin for that (it can work over SFTP I believe).
[02:56] <maredzek> upload plugin for last arrow right?
[02:57] <spiv> Or you could have a developer do a "bzr export" to get a tree and then rsync it.
[02:57] <spiv> Right.
[02:57] <maredzek> ok, so dev1 wil lcreate new module
[02:57] <maredzek> test it, change files
[02:57] <maredzek> locally
[02:57] <lifeless> spiv: upload works over sftp
[02:58] <maredzek> and he would commit changes locally
[02:58] <maredzek> and see if his work works :)
[02:58] <spiv> maredzek: that's an important step :)
[02:59] <maredzek> can this be automated?
[02:59] <spiv> which part(s)?
[02:59] <maredzek> dev1 adds 3 lines to class.php
[03:00] <maredzek> saves file in his editor
[03:00] <maredzek> we have to commit it manually on his local repo?
[03:01] <maredzek> ok so he will, he does 5 or more tasks from this module
[03:01] <maredzek> and wants to upload that data to central repo
[03:01] <maredzek> how it is done
[03:01] <maredzek> upload dont saves revision history right?
[03:02] <maredzek> push will do spiv?
[03:03] <spiv> Right, push updates (or creates) a copy of the branch.
[03:04] <maredzek> so command will ok like:
[03:06] <maredzek> bzr push --create-prefix sftp://your.name@example.com/~/public_html/my
[03:07] <spiv> Sure.
[03:09] <maredzek> ok so why after this push i can see no files in central server?
[03:09] <maredzek> thats is the part i dont understand :)
[03:09] <bob2> it updates the branch data
[03:09] <bob2> not the working copy
[03:09] <bob2> there's an update-after-push plugin that does that
[03:10] <maredzek> if i install this plugin, will it upload all files or only modified ones?
[03:11] <bob2> I think it just does 'bzr up' on the remote side
[03:11] <bob2> so neither - it'll get updates from the remote branch
[03:11] <maredzek> remote branch = central server?
[03:15] <cody-somerville> If I have a binded branch that I've made local commits to, my understanding is that I should be able to do a normal commit to have everything uploaded. Is this correct?
[03:15] <cody-somerville> Because I'm trying this with bzr 2.0.2 and it isn't working. It says I have to run bzr update first which last time caused all sorts of incorrect conflicts.
[03:15] <bob2> maredzek: = whatever you push to
[03:16] <bob2> cody-somerville: if it is bound and you made commits, they're already "uploaded"
[03:16] <cody-somerville> bob2, I made local commits
[03:16] <spiv> maredzek: People can "bzr branch", "bzr pull" etc from the place you "bzr push" to.
[03:16] <cody-somerville> bob2, ie. bzr commit --local
[03:16] <spiv> cody-somerville: to minimise issues with local commits, make sure you have no uncommitted changes before updating.
[03:17] <bob2> cody-somerville: then you need to catch up to the remote branch before you can 'push' to it
[03:17] <bob2> up on a bound branch with missing commits should probably bail if you have uncommited changes
[03:18] <cody-somerville> I am up to date.
[03:18] <cody-somerville> I'm ahead
[03:18] <maredzek> spiv, so devs are push-ing to central server, and also pull-ing  from central server, right?
[03:18] <bob2> or bound branches could go away
[03:18] <lifeless> cody-somerville: if you're ahead just push to the master
[03:18] <spiv> maredzek: right.
[03:19] <cody-somerville> lifeless, shouldn't bzr commit do that automagically?
[03:19] <cody-somerville> thats what bzr help commit advertises it will do
[03:19] <maredzek> spiv, so i pushed to central server not files, but information about what i changed, right?
[03:20] <spiv> maredzek: the complete record of what you have changed, from which the files can be reconstructed by bzr, e.g when someone does "bzr branch" of that location
[03:20] <lifeless> cody-somerville: it will unless you committed offline
[03:20] <cody-somerville> spiv, okay, thanks for that. made another local commit and ran bzr update. However, now all my commits are "rebased" (they show up as a pending merge).
[03:20] <lifeless> cody-somerville: which is the only possible way to get ahead of the master
[03:20] <cody-somerville>   --local               Perform a local commit in a bound branch.  Local
[03:20] <cody-somerville>                         commits are not pushed to the master branch until a
[03:20] <cody-somerville>                         normal commit is performed.
[03:20] <spiv> cody-somerville: that is almost exactly not what rebasing is! :)
[03:20] <lifeless> cody-somerville: ok, if you've done a local commit and an up, now do a commit.
[03:21] <cody-somerville> lifeless, I tried to and it said I needed to run update
[03:21] <lifeless> cody-somerville: no, you tried before you updated
[03:21] <maredzek> spiv, so dev1 puts that info to central server, where dev2 will obtain files? it will ask central server about changes, finds that dev1 have changed 4 files and then? download them from dev1 repo?
[03:21] <cody-somerville> lifeless, oh, right. it'll commit just fine I'm sure.
[03:21] <spiv> maredzek: all the data is on the server
[03:21] <lifeless> cody-somerville: after a commit --local you must either push, or update + commit, to make the local commit be centralised
[03:22] <cody-somerville> lifeless, the help should be updated then
[03:22] <spiv> maredzek: the .bzr directory contains a database with all the files and their changes etc compacted into it.
[03:22] <maredzek> ahhhh ok!
[03:22] <lifeless> cody-somerville: yes
[03:22] <maredzek> i got it 100%
[03:22] <cody-somerville> lifeless, it suggests to me that it'll automatically push all commits (and I think it should) if an update isn't needed.
[03:22] <lifeless> cody-somerville: huh?
[03:22] <maredzek> i will instal lupdate_after_push plugin
[03:22] <lifeless> oh, the subsequent commit?
[03:23] <cody-somerville> lifeless, No one else committed to the master branch while I was working offline
[03:23] <lifeless> its an area forimprovement
[03:23] <cody-somerville> lifeless, so now that I'm online and do a normal commit, everything should just be pushed
[03:23]  * cody-somerville nods.
[03:23] <maredzek> and when dev1 will push something, also all files wil be uploaded to central serfver right?
[03:23] <cody-somerville> the way it works now, I have to merge in all my commits into a single commit
[03:23] <lifeless> cody-somerville: or do a push, as I mentioned before
[03:23] <lifeless> cody-somerville: rather than an update
[03:23] <lifeless> cody-somerville: note that your commits are still itemised
[03:24] <lifeless> cody-somerville: just folded up
[03:31] <cody-somerville> lifeless, how do I view the full commit message for pending merge tips?
[03:34] <lifeless> what do you mean
[03:36] <Peng> "bzr st" I imagine; it only shows the first line.
[03:36]  * Peng is guessing, and goes /away
[04:33] <jam> igc: do you know what the status is for the doc building? I don't see http://doc.bazaar-vcs.org/bzr.2.0.2/downloads yete.
[07:11] <maredzek> hi, im using bazaar for one day, how can i "save" sftp passwords?
[07:11] <maredzek> it is quite annnoying to type them each time i want to push
[07:11] <bob2> don't
[07:11] <bob2> use ssh keys instead
[07:15] <maredzek> it is something like this bob2? http://pkeck.myweb.uga.edu/ssh/
[07:16] <bob2> that's the basic deal
[07:17] <bob2> if you're on debian or ubuntu: ssh-keygen ; ssh-add ; ssh-copy-id remotehost
[07:17] <maredzek> im on uubntu
[07:18] <bob2> just do the above then
[07:18] <bob2> that page makes you do far too much work :)
[07:26] <vila> hi all
[07:27]  * vila never saw a network switch fall apart. Now he has.
[07:53] <maredzek> hi, what does it mean? http://pastebin.com/m27d6ee04
[07:53] <maredzek> i wanted to push
[07:53] <maredzek> from locahost to remote
[08:39] <mkirby> I just installed bzr and am trying to follow the online docs but am getting an error when I try to 'bzr svn-import' in folder where I checked out from an svn repo
[08:41] <mkirby> bzr: ERROR: unknown command "svn-import"
[08:41] <mkirby> C:\pelco\source\vmas>bzr --version
[08:41] <mkirby> Bazaar (bzr) 2.0.1
[08:41] <mkirby>   Python interpreter: C:\Python26\python.exe 2.6.2
[08:41] <mkirby>   Python standard library: C:\Python26\lib
[08:41] <mkirby>   Platform: Windows-post2008Server-6.1.7100
[08:41] <mkirby>   bzrlib: C:\Python26\lib\site-packages\bzrlib
[08:41] <mkirby>   Bazaar configuration: c:\python26\Scripts\bazaar\2.0
[08:41] <mkirby>   Bazaar log file: c:\python26\Scripts\.bzr.log
[08:43] <mkirby> I thought the bzr installer came packaged with svn client support
[08:43] <mkirby> Here is the doc where I started from: http://doc.bazaar-vcs.org/latest/en/user-guide/svn_plugin.html
[08:47] <awilkins> mkirby, You've installed the python distribution... which alas, does not come with so many batteries
[08:47] <awilkins> mkirby, It's good for the server (you seem to have installed it on a server) because you can configure a smart server to run with IIS off it
[08:48] <awilkins> mkirby, But doesn't have any bundled plugins like the py2exe distribution does
[08:48] <mkirby> awilkins, thanks. this is my win7 dev box
[08:49] <mkirby> awilkins, I think I saw a bzr installer with python included, will that work?
[08:49] <awilkins> mkirby, You want the one that ends -setup.exe
[08:49] <awilkins> mkirby, The python included ones have a useful selection of plugins
[08:50] <mkirby> i see it: Standalone http://launchpad.net/bzr/2.0/2.0.1/+download/bzr-2.0.1-1-setup.exe
[08:50] <awilkins> That's the one
[08:50] <mkirby> k, thx
[08:51] <awilkins> mkirby, For svn interop I just prefer to branch straight from the SVN server
[08:51] <mkirby> awilkins, is that not using svn-import
[08:52] <mkirby> bzr checkout svn+ssh://svn.gnome.org/svn/beagle/trunk beagle-trunk
[08:52] <awilkins> mkirby, With the bzr-svn plugin you can just ` bzr branch http://my.svn.server.org/my/branch `
[08:53] <awilkins> You end up with a local native bzr branch ; I then tend to branch that for feature branches, keep the direct branch up to date with the SVN repo and merge those revisions outward before merging my feature back to it and pushing it up to the SVN repo
[08:53] <awilkins> Depends on whether you have the ability to move development away from the SVN repository or not
[08:54] <mkirby> it is a different team that controls the repo/build artifacts... but we are on good terms ;)
[08:54] <awilkins> mkirby, I wouldn't use a checkout because that will bind the branch to the remote repo ; it will try to push any local commits to the remote repository
[08:55] <mkirby> I like all the workflow bzr supports and ease of branching, but I'll have to try first before I can sell the company on it
[08:56] <awilkins> mkirby, bzr-svn is excellent ; it provides the benefits to you even if you can't sell the company on it because you have full read/write interop with your SVN server
[08:56] <awilkins> Could be a selling point ; you can migrate developers incrementally
[08:57] <mkirby> awilkins, agreed
[08:57] <awilkins> If any of them have to work outside the office they would be great targets for evangleism
[08:57] <mkirby> awilkins, ppl are already complaining about branching an merging in SVN, so I need an alterative
[08:58] <mkirby> awilkins, yeah we have remote offices that suffer the co,ci cycle
[08:58] <jszakmeister> mkirby: what version on svn are you using?
[08:58] <mkirby> jszakmeister, 1.5.4 (r33841)
[08:59] <jszakmeister> Merge tracking isn't working for you?
[08:59] <awilkins> mkirby, The 1.6 series has better branch/merge management but still (AFAIK) suffers from weaknesses
[08:59] <mkirby> I saw bzr support the merge tracking info in svn
[08:59] <mkirby> jszakmeister, ppl are still making mistakes... not using --reintegrate etc.
[09:00] <jszakmeister> Ah.
[09:00] <mkirby> I like the pqm (think that is right) idea too
[09:00]  * jszakmeister agrees
[09:00]  * awilkins also agrees
[09:01] <awilkins> Alas, our current contractor has produced code with 0.3% test coverage
[09:01] <jszakmeister> I've been using bzr-svn in a production environment for a while now... it's definitely worth playing with
[09:01] <jszakmeister> :-(
[09:01] <jszakmeister> That hurts.
[09:01] <mkirby> jszakmeister, thanks, don't want to risk my job if things started failing/corruption
[09:02] <awilkins> I've been using it over a year since around the 0.5 versions
[09:02] <jszakmeister> It's using the svn libraries to interact with the repo
[09:02] <awilkins> I think the worst thing I've ever seen it do is duplicate data
[09:02] <jszakmeister> ...so it behaves much like the real svn client
[09:03] <awilkins> (as in - not use previous bases and deltas, not make extra trees)
[09:03] <mkirby> excellent
[09:03] <mkirby> ru guys linux or windows users for bzr?
[09:03] <awilkins> mkirby, Both
[09:03] <mkirby> excellent
[09:04] <jszakmeister> The stuff that would really confuse folks, like reordering your mainline commits in SVN, are disabled by default
[09:04] <jszakmeister> Same here
[09:04] <awilkins> The windows performance has really improved since the earlier versions
[09:04] <bialix> since?
[09:04] <awilkins> It started out, it kicked SVNs ass. (like, SVN was a 12 minute checkout on this tree, Bazaar was 4)
[09:04] <awilkins> Now it _really_ kicks its ass
[09:05] <mkirby> we are using crucible for changeset reviews, anything like that I can work into a bzr workflow prior to hitting trunk?
[09:05] <bialix> it's for 2a?
[09:05] <jszakmeister> mkirby: remind me how crucible works... you submit a diff?
[09:05] <awilkins> bialix, The performance increments on Windows came mostly around ... oooh, 1.6? 1.9?
[09:06] <awilkins> bialix, The readdir() implementations... I've not noticed 2a being that much faster (and it packs a lot slower)
[09:06] <bialix> well, I've noticed this even earlier, but 1.9 is safe choice
[09:06] <mkirby> jszakmeister, they mostly trigger off changesets that are already commited, but you can push a dif, but it is a pita to get the full context from svn diff command
[09:07] <jszakmeister> That's what I though... it was kind of designed for post-review of changesets
[09:07] <mkirby> jszakmeister, exactly
[09:07] <bialix> awilkins: readdir for win32 was added around 1.6, maybe 1.7
[09:07] <jszakmeister> ReviewBoard can do pre-commit reviews (that's what it was designed for)
[09:08] <jszakmeister> We've been using it at our place.  It's better than nothing, but could stand to get a few improvements
[09:08] <mkirby> k, i'll check it out
[09:08] <mkirby> jszakmeister, awilkins, you guys in here much?
[09:08] <jszakmeister> Occasionally.
[09:08] <awilkins> Often
[09:08] <jszakmeister> Depends on whether I remember to fire up the IRC client.
[09:08] <mkirby> you've been a great help to ease my mind.
[09:08] <jszakmeister> Most of my day, I'm away though. :-(
[09:09] <jszakmeister> mkirby: check out an article I wrote: http://www.szakmeister.net/blog/2009/oct/12/bazaar-subversion-super-client/
[09:09] <mkirby> k
[09:10] <jszakmeister> And the migration docs: http://doc.bazaar-vcs.org/migration/en/
[09:10] <mkirby> jszakmeister, "$ bzr branch http://svn.example.com/svn/project-name/trunk/ trunk" in your First steps
[09:10] <mkirby> thanks
[09:10] <jszakmeister> In particular, http://doc.bazaar-vcs.org/migration/en/foreign/bzr-on-svn-projects.html
[09:10] <mkirby> ahh, I read the migration doc already
[09:10] <jszakmeister> Cool.
[09:11] <jszakmeister> My article has very similar information (both were written by me), but I tried to call out a few more of the individual steps in the article.
[09:11] <Peng> ("bzr branch http://svn.example.com/svn/project-name/trunk/" would work too, since the default destination is the last directory in the URL, in this case "trunk".)
[09:11] <mkirby> jszakmeister, excellent. have you checked out buildbot that google is using for chrome?
[09:12] <jszakmeister> I dunno if Google is using something different, but I've looked at buildbot before.
[09:12] <jszakmeister> It's not my first choice for a build tool. :-)
[09:13] <jszakmeister> Quickbuild is: http://www.pmease.com/
[09:13] <mkirby> I like all the stats it collects per build/test run
[09:14] <mkirby> jszakmeister, http://build.chromium.org/buildbot/perf/xp-release-dual-core/new-tab-ui-cold/report.html?history=150
[09:14] <jszakmeister> It does have some useful stats... I just think that are some others that are easier to set up... at least in a corporate environment.
[09:15] <mkirby> jszakmeister, you gave me a good start with bzr, and a lot to look into. thanks for your time
[09:15] <mkirby> awilkins, thanks alot too!
[09:15] <jszakmeister> Your welcome!
[09:15] <awilkins> mkirby, You're welcome... I think it's the best choice for Windows unless you have some seriously large projects.
[09:15] <fullermd> maredzek: Re your earlier error, that's coming from trying to push from a rich root repo (2a format) to a poor-root (0.92 or 1.9, I'd guess)
[09:20] <bialix> poor-root, lol
[09:21] <fullermd> Well, unless you're in New Orleans; then it's a poroot.
[09:33] <mkirby> jszakmeister, you wrote: http://doc.bazaar-vcs.org/migration/en/foreign/bzr-on-svn-projects.html
[09:34] <jszakmeister> Yep
[09:34] <mkirby> what did you use for the diagrams?
[09:34] <mkirby> http://doc.bazaar-vcs.org/migration/en/_images/rebase-before.png
[09:34] <jszakmeister> I used Omnigraffle.
[09:34] <jszakmeister> Best diagramming tool evar!
[09:35] <mkirby> ah, I love their tools
[09:35] <jszakmeister> Only available on a mac though
[09:35] <mkirby> I know...
[09:35] <jszakmeister> Yeah, they're great
[09:35] <mkirby> I'm running OSx86 just so I can have those on my laptop
[09:35] <jszakmeister> :-)
[09:36] <jszakmeister> I have to admit, they weighed in my decision to move to a Mac
[09:36] <mkirby> closest thing I've found is gliffy... web based, but still not as smooth and featured
[09:37] <jszakmeister> Heh.  Neat!
[09:37] <mkirby> collaboration works well too
[09:37] <mkirby> in gliffy that is.
[09:37] <jszakmeister> Cool!
[09:38] <bialix> cool
[09:39] <mkirby> be careful, it acts up when you start copy/paste a lot of objects/lines
[09:40] <mkirby> but it works well when everyone has their laptops and we sketch a design. I'm waiting for google docs to get something like this.
[09:43] <mkirby> jszakmeister, bzr branch http://svn.myserver.org/svn/project/trunk tells me "Error: Not a branch"
[09:44] <jszakmeister> What's the top-level layout look like?
[09:44] <jszakmeister> trunk/, tags/, branches/?
[09:44] <mkirby> yes
[09:45] <jszakmeister> That's odd.
[09:45] <mkirby> svn ls yeilds branches/
[09:45] <mkirby> tags/
[09:45] <mkirby> trunk/
[09:46] <mkirby> i'll throw the last slash on...
[09:47] <mkirby> jszakmeister, maybe it is my authentication
[09:47] <mkirby> it is asking for creds to on the bzr command, is that normal?
[09:48] <jszakmeister> It usually uses the cached credentials provided by svn
[09:48] <jszakmeister> ...so no
[09:48] <jszakmeister> try using svn+http://...
[09:48] <mkirby> do I need to be in my svn wc?
[09:48] <jszakmeister> No
[09:48] <mkirby> k, good, and do I need to do a bzr init?
[09:48] <jszakmeister> No.  Just branch and go
[09:49] <jszakmeister> It might be the OPTIONS probe that's causing trouble...
[09:49] <jszakmeister> bzr-svn does that to see if the remote end is a SVN server
[09:50] <jszakmeister> Some server setups seem to dislike it though
[09:50] <jszakmeister> svn+ disables the options probe
[09:50] <mkirby> unsupported protocol
[09:51] <jszakmeister> Does 'bzr plugins' show svn?
[09:51] <mkirby> svn+http://svn.myserver.org/svn/project/trunk
[09:51] <jszakmeister> I think you might be suffering fallout from your previous install of bzr
[09:52] <mkirby> No module named qbzr.lib.commands
[09:52] <jszakmeister> Ouch.
[09:52] <mkirby> jszakmeister, I think you are correct
[09:53] <mkirby> I'll give it a shot on my linux box and windows box @ work
[09:54] <mkirby> this time I'll pull the standalone for the windows box
[09:54] <mkirby> @ work
[09:54] <jszakmeister> How did you install bzr before?
[09:54] <mkirby> bzr-2.0.1-1.win32-py2.6.exe
[09:55] <mkirby> then I pushed bzr-2.0.1-1-setup.exe over the top of it I guess.
[09:55] <jszakmeister> Oh, I see.
[09:55] <jszakmeister> You might want to uninstall that
[09:55] <mkirby> ohhh!
[09:55] <mkirby> I think I still have the old one in PATH
[09:55] <jszakmeister> the -setup has everything... exactly.
[09:56] <mkirby> yeah, i remember setting up the path... let me kill it
[09:56] <mkirby> haha, %BZR_HOME%;C:\Program Files\Bazaar
[09:57] <mkirby> the %BZR_HOME% is me, the other is from the new install
[09:57] <jszakmeister> Nice. :-)
[09:58] <mkirby> jszakmeister, sweeeeeet
[09:58] <jszakmeister> That sounds like success. :-)
[09:58] <mkirby> I like the progress bar
[09:58]  * jszakmeister too
[09:59] <jszakmeister> It's a nice bit of user feedback
[09:59] <davidstrauss> If I run Branch.open(), what exceptions can I expect from that?
[09:59] <mkirby> ok, so I'll still read up on your article, but when I do commits, it will be local, then a push will land it on trunk
[09:59] <jszakmeister> Yes, if you used 'bzr branch'
[09:59] <davidstrauss> NotBranchError?
[09:59] <jszakmeister> The best workflow is probably to a branch and merge paradigm
[10:00] <mkirby> jszakmeister, k, great
[10:00] <jszakmeister> Otherwise, you're going to have to get familiar with rebase
[10:00] <mkirby> i've rebased in SVN on my branches, prior to reintegrating...
[10:02] <mkirby> but I understood how you kept your trunk, branched, cd to branch, committed, then moved back to ur trunk and merged the branch directory in.
[10:02] <jszakmeister> SVN kind of enforces that workflow... especially since it'll silently rebase your changes during commit, if another one is already taking place.
[10:02] <jszakmeister> Great, then you're ready to rock! :-)
[10:03] <jszakmeister> Plus, that paradigm is better for long term feature branch development too
[10:03] <mkirby> jszakmeister, thats why I am here ;)
[10:03] <jszakmeister> Rebasing makes it hard to share changes, and the more changes you bring in and add, the more chance you have a conflict.
[10:03] <jszakmeister> :-)
[10:03] <jszakmeister> Same here. :-)
[10:04] <jszakmeister> Well... that, and I wanted to contribute to some open source projects that are using SVN
[10:05] <mkirby> yeah, I am still looking for my opensource project to contribute my hobby time to...
[10:05] <jszakmeister> Be careful... once you start, you can't stop. :-)
[10:06] <jszakmeister> I wish I had more time for it... I truly love it.
[10:06] <mkirby> jszakmeister, good to hear... so far I am at rev 1100 or 3373
[10:06] <mkirby> of
[10:15] <mkirby_returns> jszakmeister, I'll have to give it a shot @ work from the LAN, my VPN is failing, and there are some other things about the contents in that trunk I don't like.
[10:16] <mkirby_returns> again thanks, hope to see you around, do you have twitter acc?
[10:16] <jszakmeister> Your welcome!  And yes, I do: twitter.com/jszakmeister
[10:16] <jszakmeister> Although, I've been rather quiet there lately. :-0
[10:16] <jszakmeister> I mean :-)
[10:19] <mkirby_returns> k, tomorrow will be exciting, night
[10:55] <piem> hi! i'm looking for two post commits: one that would force me update the changelog, and one that would run indent on the modified files
[13:04] <free> hi all!
[13:04] <free> is something changed in LP? I can't run bzr checkout http://bazaar.launchpad.net/~landscape/landscape-client/trunk/ anymore.. but maybe I'm not supposed to use that scheme?
[13:05] <free> (it's used by a buildbot)
[13:06] <vila> lp is down for at least 2 hours now
[13:07] <vila> argh, I hate it when I hit refresh on an error page :-/
[13:08] <vila> hmm, by bot still fails to checkout too...
[13:08] <vila> s/by/my/
[13:08] <free> strangely if I check out using the lp: schema everything works
[13:14] <vila> free: yeah, it seems the smart server is doing fine while the http one isn't
[13:14] <vila> It's known and being working on AIUI
[13:35] <fullermd> Fie on http anyway.  Who wants to be dumb when you can be smart?
[13:37] <vila> Sometimes the smart redirects to the dumb and.... :-)
[13:38] <fullermd> That's pretty dumb.
[13:38] <free> can you use the smart one without login?
[13:39] <free> oh, you can
[13:39] <free> buildbot doesn't work very well with the lp: schema, it would need a patch
[13:40] <vila> free: relly ? What problems do you encounter ?
[13:42] <free> vila: it simply tries to replace branch urls starting with "lp:" with "bzr+ssh://bazaar.launchpad.net/"
[13:42] <vila> that's intended behavior, bzr is doing that not buildbot
[13:43] <free> vila: buildbot too, in the bzr_buildbot.py backend
[13:43] <vila> 8-(
[13:45] <vila> free: where is that file in the buildbot namespace ?
[13:45] <free> vila: it's a contrib file
[13:45] <free> vila: it's in the main distribution (or at least the Ubuntu/Debian package), but not in the namespace, you can place it where you want
[13:46] <free> and import from it in your config
[13:46] <free> /usr/share/buildbot/contrib/bzr_buildbot.py
[13:47] <vila> ENOTFOUND, what buildbot version are you using ?
[13:47] <free> 0.7.11p3-1
[13:47] <free> http://packages.ubuntu.com/karmic/buildbot
[13:48] <vila> shudder, not upgraded yet for the host that uses buildbot :-/
[13:48] <vila> so I'm still at 0.7.9-1
[13:48] <free> oh, okay
[14:04] <arkanes> so I have a branch from which I've deleted lots of subdirectories, and merging from the trunk is generating a ton of conflicts in all those paths
[14:04] <arkanes> is there some way I can indicate that I removed these specifically and that merging shouldnt update them?
[14:06] <bialix> nope
[14:08] <bialix> free: http://twitter.com/launchpadstatus/status/5449277080
[14:10] <free> bialix: the problem is that you need an ssh key to use bzr+ssh? the buildbot user doesn't have one
[14:11] <bialix> I'm not LP dev but I believe you have to use your own ssh key
[14:12] <bialix> if you don't have key -- you don't have ssh access, right vila?
[14:12] <free> bialix: yeah, the point is that you should be able to checkout without authentication, for things like bot etc.
[14:12] <bialix> this is http for
[14:12] <bialix> today is LP upgrade day if I've tracked announce correctly
[14:13] <free> bialix: it is
[14:13] <bialix> it's not the every day such problems occurs
[14:14] <vila> bialix: I don't the lp implementation enough to answer here but I think you're right
[14:15] <free> indeed, that's why using bzr+ssh it's not an option in this case (buildbot), unless you set up a key and an LP account for that only
[14:17] <bialix> vila: IIUC ssh access is rarely passwordless/keyless, that's what I mean
[14:17] <bialix> free: it's sounds like one time hassle
[14:17] <vila> yup
[14:17] <bialix> and LP ssh is only key auth
[14:20] <free> bialix: well, and you should make sure that the ssh key is installed in all your buildbot slaves, and if you add a new copy it over.. I agree it's a one time hassle, but I really think unauthenticated checkouts is a feature LP must have anyway, and indeed it has
[14:23] <bialix> it is
[14:41] <gioele> hello
[14:42] <gioele> does anyone actively use trac-bzr?
[14:45] <mkanat> Hey hey. If I have a persistently-running bzr server, is there a way to get loggerhead to use it, or does loggerhead just use bzrlib?
[14:47] <mkanat> Come to think of it, it probably does use bzrlib and there would be no advantage to its using a persistent server.
[14:50] <MTecknology> How do I pull a branch over http? I'm trying to do this with LP
[14:51] <jelmer> gioele: we're using it on bugs.biutlbee.org, but with an older version of bzr\
[14:52] <gioele> MTecknology: doesn't bzr pull http://..../ work? Does it give you an error?
[14:52] <jelmer> *bugs.bitlbee.org
[14:52] <MTecknology> gioele: I guess there's a server issue atm - thanks
[14:53] <gioele> jelmer: I'd like to suggest my project admin to switch to bzr from svn, but that requires trac support. I doubt trac-bzr is just a drop-in plugin at the moment (given the advent of bzr 2 and so on)
[14:56] <jelmer> gioele: trac-bzr is pretty much unmaintained at the moment, and it has memory leak issues
[14:59] <bialix> gioele: I'm using trac-bzr with bzrlib 1.5
[14:59] <bialix> MTecknology: http://twitter.com/launchpadstatus/status/5449277080
[15:00] <gioele> jelmer: that was the impression I had. My only hope is to use bzr-svn. But I guess that, in the future, bzr-git will be developed more than bzr-svn (as samba moved to git).
[15:04] <jelmer> gioele: not really; bzr-svn is a goal in itself for me these days
[15:05] <gioele> jelmer: good to hear that. I thought that after the switch the attention to bzr-svn would become zero
[15:06] <jelmer> gioele: no - Samba switched to git over 2 years ago, and bzr-svn is still alive and kicking :-)
[15:07] <jelmer> It's also nice to see that there are other people making contributions
[15:30] <lamont> what command did I give bzr to cause it to have bound=file://$PARENT in branch.conf?
[15:31] <jam> lamont: 'bzr checkout' versus 'bzr branch' ?
[15:31] <jam> or 'bzr bind'
[15:31] <lamont> thanks
[15:31] <jam> note that the previously bound location is remembered even if you 'bzr unbind' later
[15:31] <lamont> yeah
[15:33] <jam> rockstar, abentley: Anything I can do to help out with the codehosting issues? It seems very strange to have files randomly disappearing from the http site. (for example .../~bzr-pqm/bzr/bzr.dev is missing .bzr/repository/format, but lp:~bzr-pqm/bzr/2.1.0b2 is missing .bzr/branch/format)
[15:35] <abentley> jam: Okay, that's interesting.  I was under the impression that all files were 404ing.
[15:36] <jam> abentley: .bzr/branch-format for both of those worked just fine
[15:36] <jam> but then fails later on
[15:36] <jam> (well, *other* files fail later)
[15:36] <jam> yeah, I hit a "not a branch" so opened it up in my browser, and things worked
[15:36] <jam> so I kept probing until I found what it didn't like
[15:47] <abentley> jam: http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/.bzr/repository/format works for me.
[15:47] <jam> abentley: same here, though http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/.bzr/branch-format is timing out
[15:48] <jam> now it worked
[15:48] <jam> but it did give a timeout first
[15:48] <jam> similarly: http://bazaar.launchpad.net/~bzr-pqm/bzr/2.1.0b2/.bzr/branch/format is timing out
[15:48] <jam> but I imagine after a refresh it will 'just work'
[15:49] <jam> abentley: still getting timeouts/404 on 2.1.0b2
[15:49] <abentley> jam: yeah, that works for me now.
[15:49] <mthaddon> I'm seeing the same for http://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel/.bzr/branch-format - times out, refresh and it's fine
[15:49] <jam> abentley: so I'm guessing it is some sort of caching/filesystem mapping issue?
[15:49] <jam> so it makes a request which takes a while
[15:49] <jam> hangs and times out
[15:50] <jam> but eventually the os does get the file it wanted
[15:52] <abentley> jam: We have a script that rewrites urls for apache, translating them from ~me/proj/branch paths to /00/00/7F/3E paths.  That scripts does have a cache, but I'd be really surprised if it has bad data.
[15:53] <abentley> jam: But it's not the sort of tricky virtual filesystem stuff we do with sftp.  It's pretty simple.
[15:54] <jam> abentley: so to *do* the translation, I assume you have to do a db query to get the mapping?
[15:54] <jam> though if that was timing out, I would think that you would miss *all* files for a branch until later
[15:54] <abentley> jam: Indeed.
[15:54] <jam> and not random files
[15:56] <abentley> jam: That's right-- the cache is a cache of the part of the path that we rewrite, so once it's been mapped, it should be fast and repeatable.
[15:56] <jam> abentley: and I assume it is done at the ~user/project/branch level, and not down in the .bzr/* level
[15:56] <abentley> jam: Right, the cache is done at the ~user/project/branch level.
[15:58] <jam> abentley: side question. I'd like to create a "bzr-builder" user for the windows buildbots. Is just logging out and "Register"ing a new user the best way to do that?
[15:58] <abentley> jam: I think so.
[16:08] <marek__> hi, i have a problem with understandign bazaar, so far i used svn and after modyfing files on my local system i just made a checkout, and that was all, on server there were new files. Currently i have two coputers - one is server and the other - is my client that i work on, i made following setup: on server i init a project, extracted there some core files and than from my client machine i did branch, now i edited file and commited locally that
[16:08] <marek__> change, what do i have to do, to affect server files and repo?
[16:09] <beuno> marek__, when you push, the repo will be updated
[16:09] <beuno> if you want the working tree files to be updated, you will need to run "bzr update" on the other end
[16:10] <marek__> ok i pushed it
[16:10] <marek__> i also wanted to upload:
[16:10] <marek__> bzr: ERROR: sftp://marek@192.168.7.109/var/www/trac/.bzr/ is not a local path.
[16:10] <marek__> (i have plugin installed)
[16:10] <beuno-lunch> marek__, what command are you running?
[16:11] <marek__> marek@marek-laptop:/var/www/trac$ bzr update sftp://marek@192.168.7.109/var/www/trac
[16:11] <beuno-lunch> marek__, right, you can't update remotely
[16:11] <beuno-lunch> you need to run it on the other end
[16:11] <marek__> ok
[16:11] <beuno-lunch> marek__, there is a plugin called "push-and-update" that will do the update for you
[16:12] <beuno-lunch> you will need ssh access
[16:12] <marek__> i have i also tried to install that plugin but i dont know how it works
[16:12] <marek__> but tell me one thing
[16:12] <marek__> do i have to provide user name and host for my client machine?
[16:14] <beuno-lunch> marek__, provide where?
[16:14] <marek__> you told me that i need "to run it on the other end"
[16:14] <beuno-lunch> when you do it locally
[16:14] <marek__> in server?
[16:14] <beuno-lunch> it's just "bzr update"
[16:14] <beuno-lunch> when yourin the branch's directory
[16:14] <marek__> ok
[16:15] <marek__> i did, but it wont change file on remote server?
[16:15] <marek__> heh it did
[16:15] <beuno-lunch> :)
[16:15] <marek__> magic
[16:15] <beuno-lunch> if you just need to have the files, no the repo, you can use bzr-upload instead
[16:21] <marek__> i need both :)
[16:25] <marek__> i have another problem , at first i commited change in one file, after succesfully updateing it with server, i changed 2 more files and wanted to commit i got this:
[16:25] <marek__> aborting commit write group: PathsNotVersionedError(Path(s) are not versioned: "male zmiany w schema.yml")
[16:30] <luks> sounds like you typed `bzr ci "male zmiany w schema.yml"` instead of `bzr ci -m         check_references(searcher, )`
[16:30] <luks> er
[16:30] <marek__> i typed:
[16:30] <luks> instead of `bzr ci -m "male zmiany w schema.yml"`
[16:31] <marek__>  bzr commit "male zmiany w schema.yml"
[16:31] <luks> yep
[16:31] <luks> you forgot the -m/--message option
[16:31] <marek__> ouch
[16:31] <luks> so you told to commit a file named  "male zmiany w schema.yml"
[16:31] <luks> and there is no such file
[16:32] <marek__> ok so now i have:
[16:32] <marek__> aborting commit write group: PointlessCommit(No changes to commit)
[16:32] <marek__> i changed file
[16:32] <luks> bzr st
[16:33] <marek__> bzr st returns nothing
[16:33] <luks> then there is nothing to commit :)
[16:34] <marek__> :/
[16:34] <luks> which file have you changed?
[16:34] <marek__> ok, it is right
[16:34] <marek__> i just did it on server
[16:34] <marek__> not on client
[16:36] <marek__> ok but once again i have this problem wth working tree
[16:36] <marek__> files are not updated after update
[16:36] <luks> you mean after push?
[16:37] <marek__> agrr ok,
[16:37] <marek__> so prcedure is:
[16:37] <marek__> 1, modify files locally, 2. push, 3. update \
[16:37] <marek__> right?
[16:38] <luks> if you have a standalone branch, you need this: 1. modify files, 2. bzr commit, 3. bzr push, 4. (on the server) bzr update
[16:39] <luks> if you have a checkout: 1. modify files, 2. bzr commit, 3. (on the server) bzr update
[16:40] <luks> (or you can avoid the update step by installing the push-and-update plugin)
[16:40] <marek__> ok, what if there are more clients that are doing pushing? how can i be sure, to have latest version first... with branch?
[16:40] <luks> only one client can push as a time
[16:40] <marek__> ok, but if he does it 30 min before?
[16:40] <luks> if somebody pushes to the server, and you would try to override it, bzr will complain
[16:40] <marek__> ok, thats like in svn
[16:41] <luks> then you can use bzr merge, bzr commit and then bzr push again
[16:41] <marek__> so i do something like this:
[16:41] <marek__> 1. branch latest version from server
[16:41] <marek__> 2. modify files
[16:41] <marek__> 3. bzr comit
[16:41] <marek__> 4. bzr push
[16:41] <marek__> 5. pzr update (on server)
[16:41] <marek__> does it make sense?
[16:41] <luks> yes
[16:42] <marek__> great
[16:42] <luks> but if you want to work this "centralized" way, I'd suggest you to use bzr checkout
[16:42] <marek__> about that plugin
[16:42] <luks> then you don't have to explicitly push
[16:42] <luks> and if you try to commit to an out-of-date branch, it will tell you
[16:42] <marek__> so i would change 1 stage? 1. checkout latest version from server?
[16:42] <luks> yes
[16:43] <luks> and remove point 4
[16:43] <marek__> oh, ok
[16:43] <marek__> about that plugin - so i have to install it on server or client?
[16:43] <luks> on the client
[16:43] <marek__> will i need this while using checkout?
[16:44] <luks> yes, I believe so
[16:44] <fullermd> I don't know if the plugin runs off and does the update on commit...
[16:45] <luks> hm
[16:45] <marek__> but if i use branching - it will work perfectly?
[17:05] <mems> hey.  Can anyone tell me how to list the branches in a remote repository?
[17:11] <alefteris> hi all. I got this error after doing pull:
[17:12] <alefteris> bzr: ERROR: Not a branch: "http://bazaar.launchpad.net/~ubuntu-gr-webteam/ubuntu-gr-website/drupal6-site/.bzr/branch/".
[17:12] <alefteris> then I tryed again, and got:
[17:12] <alefteris> bzr: ERROR: Not a branch: "/var/www/html/ubuntu-gr/drupal/lp:ubuntu-gr-website/".
[17:13] <alefteris> log: http://paste.ubuntu.com/310739/
[17:15] <alefteris> I did a branch localy from the lp branch, and branch was created and can pull
[17:15] <alefteris> I also notised this diference between the format files in server and local branch: http://paste.ubuntu.com/310738/
[17:17] <alefteris> I'm using bzr 2.0.0 localy and bzr 1.3.1 in the server. I help would be realy helpful, thanks :)
[17:26] <alefteris> Anyone knows if there are newer versions of bzr for centos?
[17:27] <mkanat> alefteris: I just rebuild the Fedora RPMs, myself.
[17:27] <alefteris> the one I got is from Extra Packages for Enterprise Linux (EPEL)
[17:27] <jam> alefteris: http://bazaar.launchpad.net is currently 'down for maintenance'
[17:27] <jam> if you are using bzr 1.3.1 I don't think it understand "lp:" urls
[17:27] <jam> 1.3 is... ~2 years old
[17:28] <jam> well, 1yr 7mo
[17:28] <fullermd> Urr?  I'm pretty sure bzr understood lp: URL's in 0.6...
[17:28] <alefteris> jam, I can see the lp plugin commands though, I thing it does support lp urls
[17:29] <fullermd> (of course, 0.6 would fare poorly with bzr+ssh...)
[17:29] <jam> alefteris: (11:12:39 AM) alefteris: bzr: ERROR: Not a branch: "/var/www/html/ubuntu-gr/drupal/lp:ubuntu-gr-website/". would indicate it in't
[17:29] <jam> isn't
[17:29] <jam> were you running "--no-plugins" ?
[17:30] <alefteris> nop
[17:32] <alefteris> I can't branch even with the full url though
[17:32] <alefteris> oh, code hosting is down right now?
[17:34] <jam> alefteris: http is
[17:34] <jam> you could use bzr+ssh or sftp
[17:34] <jam> if you have a key shared
[17:36] <alefteris> I haven't, so I gess I'll have to wait, I'm so unlucky to try to update the site, while lp is down :/ thanks all for the help :)
[18:04] <vila> jam: ping
[18:04] <jam> hey vila
[18:05] <jam> I think I figured out what was wrong with the build stuff. 'hexagonit.download' released a new version
[18:05] <jam> and the build script wasn't version-locked for that
[18:05] <jam> specifically looking here:
[18:05] <jam> http://pypi.python.org/pypi/hexagonit.recipe.download
[18:05] <jam> 1.3.0 says: We now require zc.buildout >= 1.4.0
[18:05] <jam> and we were version locked to zc.buildout 1.2.1
[18:05] <jam> anyway, what's up for you vila?
[18:05] <vila> I had a lot of internal network problems today and I still need to pack (I'm leaving tomorrow)
[18:05] <vila> jam: oh great you found that !
[18:06] <vila> I just committed a fix for bug #475585
[18:06] <vila> but I can make the MP because lp tells me: updating branch.... I suspect it will stay like that for a while :-/
[18:07] <vila> s/I can/I can't/
[18:07] <jam> I can create an MP while the branch is still updating
[18:07] <jam> but I expect you'll run into whatever the current codehosting issues are
[18:07] <jam> before it shows a dif
[18:07] <vila> really ? I never dared...
[18:07] <jam> vila: it works just fine
[18:07] <jam> I do it all the time
[18:07] <jam> *I'm* not going to wait for it everytime I want to submit something :)
[18:08] <vila> ok, I'll do that then, but I can only target lp:bzr...
[18:08] <jam> versus?
[18:09] <jam> bzr 2.1.0b2 has been cut
[18:09] <jam> so we'll have to do b3 early to get your fix in
[18:09] <jam> (no rc policy and all)
[18:10] <jam> but your changes aren't in 2.0.* series so it shouldn't affect thta
[18:10] <jam> that
[18:10] <vila> right, I wasn't sure, so lp:bzr is enough
[18:10] <jam> vila: well, probably I would create a 2.1.0b3 derived directly from 2.1.0b2 and not including new bzr.dev stuff
[18:10] <jam> but that is negotiable
[18:10] <jam> you *could* target lp:~bzr-pqm/bzr/2.1.0b2
[18:10] <jam> and just have us manually track the "Merged" status
[18:11] <vila> time is running short :-/ I'll see what I can do tomorrow, if you don't beat me to it, I did test against 2.4/2.5/2.6 with -s bp.launchpad and had ~50 failures without my patch
[18:12] <jam> vila: so no failures on 2.5/2.6 but failures on 2.4, right?
[18:13] <vila> also, I put babune in reduced mode starting now (only hardy. jaunty, karmic left active, I won't be able to tweak manually as I do for a couple of weeks for the others :-/)
[18:13] <vila> jam: yes
[18:14] <jam> vila: so at least give me the url for your patch, but it would be nice to have it as an mp so I can easily comment on it
[18:14] <jam> certainly, we should land it in bzr.dev today
[18:14] <vila> mp is done
[18:14] <jam> and see where we get to for 2.1.0b3
[18:14] <jam> vila: url?
[18:14] <jam> (in case it takes forever to generate the preview)
[18:14] <vila> argh, can't copy/paste here :-(
[18:14] <jam> type out the short name
[18:14] <vila> you should find it back from the bug report
[18:15] <vila> the branch is linked to the bug and starts with 475585
[18:15] <jam> vila: only once lp updates...
[18:15] <jam> but https://code.edge.launchpad.net/~vila/bzr/475585-lp-proxy-py24-compat/+merge/14489
[18:15] <jam> looks good
[18:16] <jam> well, looks like what you worked on
[18:16] <jam> *argh*...
[18:16] <jam> because you uploaded to ~vila I only get access to the mirrored side
[18:16] <jam> which won't give me access until the mirroring script finishes running.
[18:16] <vila> yeah, I daggy-fixed to ensure the patch was minimal
[18:17] <vila> aaaaaargh
[18:17] <jam> you could push it to ~bzr
[18:17] <jam> and I could get the writeable side
[18:17] <vila> done
[18:17]  * vila EODing
[18:18] <jam> vila: can I get 1 min to make sure I can get the code
[18:18] <jam> done
[18:18] <jam> thx
[18:19] <jam> vila: you stopped passing "use_datetime"...
[18:19] <jam> I'll clean that up I guess
[18:19] <vila> jam: sure, I'll certainly be around ;ater, but only for short moements
[18:19] <vila> we don't use it
[18:19] <vila> so we mat as well don't pass it
[18:25] <jam> vila: mmm if we are going to do that, then we shouldn't expose it as part of the __init__ interface
[18:25] <jam> since if anyone *does* use it, it will just mysteriously not work
[18:31] <jam> ah, I missed the fact that you did exactly that
[18:39] <jam> abentley: any eta on the codehosting fix? it seems that it has broken the mirroring script, which means that if I push new code to lp, then it doesn't get mirrored to the public side, so I can't access it with different access rights
[18:39] <jam> not to mention disabling merge proposals, etc.
[18:39] <abentley> jam: We have just cowboyed a fix a minute ago.
[18:40] <abentley> jam: It has not broken the mirroring script-- that was separate breakage which has also just been fixed.
[18:41] <jam> abentley: ah, well good to know they are both fixed at least :)
[18:41] <jam> is that "cowboyed" into production then?
[18:42] <abentley> jam: That's right.  I'm working on a cherrypick for the branch-rewrite script, whose faulty cache was at the root of the issue you saw.
[18:43] <jam> abentley: so it *was* the cache being faulty
[18:43] <jam> surprising
[18:44] <abentley> jam: Yes.  The issue looked like some files were working and others weren't, but it was actually that requests which hit the cache failed, and those that didn't worked.
[18:45] <jam> abentley: I don't want to take you away from doing the fix, but I'm curious how the cache knows when to invalidate itself (like when a branch gets renamed, etc.)
[18:48] <abentley> jam: It is time-based.  Entries older than 10 seconds are discarded.
[18:49] <jam> abentley: ah, so you just avoid hammering the db when a person is requesting 10k files underneath a branch, but you don't keep it around too long
[18:49] <abentley> Right.
[18:49] <jam> also explains why it sometimes worked, if that 10s had just expired
[18:49] <jam> and why "bzr branch" fails, because it would work for the first request, but the second would come in within 10s
[18:51] <abentley> jam: When a branch gets renamed, the cache doesn't prevent lookups on the new name from working, but it allows lookups on the old name to work 10s longer than they technically should.
[18:52] <jam> right
[18:52] <jam> well, you could have a double-rename do things you may not want
[18:52] <jam> but it is a race condition anyway
[18:52] <jam> as renaming something underneath you is going to do bad things
[18:53] <jam> argh... this mirroring thing is killing me
[18:53] <jam> I can't get the latest bzr.dev but I can't submit to pqm because NEWS conflicts
[18:53] <jam> because *pqm* has the latest version
[18:54] <abentley> jam: Yes, the double-rename is problematic.
[20:50] <bialix> jam: hi
[20:50] <bialix> jam: do you merged win32 glob patch so fast to ensure it will get more real world testing?
[22:55] <igc> morning
[22:56] <jam> hey igc
[22:56] <jam> I hope your feeling good today
[22:56] <igc> hey jam
[22:56] <jam> btw, I'm still stuck without docs for bzr 2.0.2 and 2.1.0b2
[22:57] <jam> though I'll need to release 2.1.0b3 soon
[22:57] <jam> so don't focus on those
[22:57] <igc> jam: better but still not great. I'm doing the docs right now
[22:57] <igc> jam: I slept nearly all of yesterday
[22:57] <jam> igc: thanks. and i'm glad to hear that you're feeling better
[22:57] <jam> looking forward to seeing you in about 72 hours
[22:58] <jam> well, maybe 96...
[22:58] <jelmer> moin igc, jam
[22:58] <jam> hi jelmer
[22:58] <igc> hi jelmer
[22:58] <jam> igc: for myself, I'm still trying to sort out all the issues for getting the buildout stuff working on ec2
[22:59] <igc> jam: :-(
[22:59] <jam> The recent round of changes showed that we hacked some stuff together on kerguelen
[22:59] <jam> like putting packages in PATH rather than having buildout do the work
[22:59] <igc> jam: I'm still catching up - 2.1.0b2 is no good?
[22:59] <jam> and sometimes hard-to-diagnose failures like having to manually hack python2.4's disutils
[22:59] <jam> I forgot about that in the pats
[22:59] <jam> past
[22:59] <jam> igc: it is not compatible with python2.4
[23:00] <jam> the proxy code stuff
[23:00] <igc> ah
[23:00] <jam> turns out in 2.4 it is a 'old-style' class without __init__
[23:00] <jam> and PQM no longer runs python2.4
[23:00] <jam> because we couldn't convince mthaddon about how it should be configured
[23:00] <jam> and then sort of dropped the ball on it
[23:01] <jam> Anyway, writing up the steps I take to get things working now
[23:01] <jam> as a real document :)
[23:01] <jam> and then we should be able to snapshot the EC2 instance
[23:01] <igc> jam: that will be good
[23:01] <jam> the major issue we'll run into is how to do VS 2008, whether we need Standard
[23:01] <jam> or whether we can work out what SDK you need in order to build tbzr w/ Express
[23:02] <jam> igc: yeah, so far the build process is a lot nicer on EC2
[23:02] <jam> I think the disk access is better
[23:02] <jam> and if necessary, we can easily spin up an instance in 'medium' rather than small (I believe)
[23:03] <igc> jam: my bzr on vista is failing for some weird reason
[23:04] <igc> jam: so I'll get the chm's built as soon as I can but it may be an hour or so, depending on what's going on
[23:05] <jam> igc: well, I'm done for today anyway. but it would be nice to either build in about 3hrs when my family goes to bed, or at least tomorrow before I fly away
[23:05] <igc> jam: ok.
[23:06] <jam> I'll note that at least on Kerguelen everything builds fine as long as I tell it to use the old docs
[23:06] <igc> jam: I'm really sorry I couldn't do this earlier
[23:06] <jam> igc: well, not exactly your fault either
[23:06] <jam> igc: I hope you have a good day today, maybe I'll see you around later
[23:06] <igc> jam: but I was simply too sick (despite trying a few times to do it)
[23:07] <igc> ok. If not, in a few days
[23:07] <igc> jam: have a safe flight btw
[23:14] <maxb> Is there a good doc which summarizes what looms and pipelines actually *are*? I have seen the documentation for the plugins' commands, but I'm still a bit hazy on what a loom and a pipeline are and when I would want to use them.
[23:24] <maxb> Likewise, I could really use a pipes vs. looms comparison
[23:31] <poolie> hi all
[23:43] <poolie> spiv, hi
[23:45] <spiv> poolie: hey
[23:46] <poolie> how's stuff?
[23:47] <poolie> i'm planning to get offline in a bit and think about next week
[23:47] <igc> hi poolie, spiv
[23:47] <igc> poolie: before you go, where did the doc stuff get to?
[23:47] <poolie> just got a few queries from the hotel
[23:47] <spiv> I saw the udd mailing list is alive, I just did the mailman dance.
[23:47] <poolie> igc, i think it's buliding ok
[23:47] <poolie> modulo gremlins, which have probably broken some links
[23:48] <poolie> oh and we're waiting on the rt for pdf builds
[23:48] <poolie> the next action would be to poke around more thoroughly looking for broken links i guess
[23:48] <poolie> or to run a bot to do the same
[23:48] <igc> poolie: where are the doc builds going to?
[23:48] <igc> poolie: see http://doc.bazaar-vcs.org/
[23:49] <igc> there's no bzr.2.0.2 yet?
[23:49] <igc> or bzr.2.1.0b2 yet?
[23:49] <poolie> !
[23:50] <poolie> ok
[23:50] <poolie> you need to go down into eg http://doc.bazaar-vcs.org/current/en/
[23:50] <spiv> I'm shortly going to put up a wiki page with the bzr/ubuntu stories and some analysis of them.  I've been trying to wrap my head around as much of the existing bzr-builddeb/bzr-builder/DistributedDevelopement stuff as possible, there's no shortage of text to sift through...
[23:50] <poolie> so apparently we need to remove the existing docs that are hiding them at a higher level
[23:50] <poolie> igc i don't think it's worth having a directory for every single release
[23:50] <poolie> i think one per 6m branch is enough
[23:51] <igc> poolie: let's sort it out next week then
[23:52] <igc> poolie: it's certainly a little weird now, e.g. http://doc.bazaar-vcs.org/latest/en/
[23:52] <igc> says "2.0.3dev" when it needs to say "2.0.2" IMO
[23:52] <poolie> hm
[23:53] <poolie> i guess that is a more interesting case
[23:53] <poolie> not so much that people might want the specific docs for old releases
[23:53] <poolie> but that even the current release may be confusing if you see later docs
[23:54] <poolie> (this should anyhow perhaps be partly addressed by describing some features with the release that introduced them but you can't do that everywhere)
[23:54] <poolie> igc, to me the biggest thing would be to work out what should be at these urls:
[23:54] <poolie> doc.b.o/  doc.b.o/latest/
[23:54] <poolie> should they just redirect by default to the english versions?
[23:55] <poolie> i guess the page currently on http://doc.bazaar-vcs.org/en/ should appear at the top level?
[23:55] <igc> right. Or the top level can redirect there