[01:32] <Stavros> hello
[01:33] <Stavros> is there a way to have bzr store branches in the same directory and switch uncommitted changes too?
[01:33] <Stavros> basically, colocated branches but with shelving
[01:34] <lifeless> bzr switch should just do that
[01:35] <Stavros> lifeless: last i tried, switch didn't switch uncommitted changes, was that added?
[01:38] <Stavros> lifeless: nope, it doesn't
[01:39] <lifeless> what do you mean by switch uncommitted changes then ?
[01:39] <lifeless> for me, it keeps uncommitted changes in the tree, so I can commit them to another branch.
[01:39] <Stavros> oh
[01:39] <Stavros> i mean shelve them in the branch
[01:39] <Stavros> so i can have uncommitted changes per branch
[01:40] <Stavros> for example, i'm working on feature 1 but it's half done
[01:40] <lifeless> so, standard shelve is in the working tree
[01:40] <Stavros> yes, but per-branch
[01:40] <lifeless> the pipeline plugin adds a shelf per branch as well
[01:40] <Stavros> hmm
[01:40] <Stavros> nothing that will automatically shelve everything on swich, though?
[01:41] <lifeless> pipeline does when working with a pipeline
[01:41] <Stavros> is pipeline good? i found it a bit confusing
[01:41] <lifeless> some folk love it
[01:41] <Stavros> what i want to do is work on feature1, switch to feature 2 even if 1 is half finished, work on 2, switch back to 1 and finish and commit 1
[01:41] <lifeless> its quite polished at the use case it aims to solve (a series of feature branches tackling one large problem)
[01:41] <Stavros> right now i have to do some complicated shelving
[01:41] <Stavros> ah
[01:41] <Stavros> hmm yes
[01:41] <Stavros> maybe this is what i need, then
[01:41] <lifeless> Stavros: what about just committing?:
[01:42] <Stavros> i don't like committing half-working things :/
[01:42] <lifeless> work on feature 1, commit, switch to feature 2, work, commit, switch to feature 1, *uncommit*, keep working.
[01:42] <Stavros> i don't trust me to remember to uncommit :/
[01:42] <Stavros> good solution if you're not ocd, though
[01:43] <lifeless> a shelf per branch would be a good facility for core I think, perhaps file a bug ?
[01:43] <Stavros> i will, thanks
[01:43] <Stavros> i'll try pipeline in the mean time
[01:44] <Stavros> shouldn't i post a feature request rather than a bug?
[01:45] <lifeless> Stavros: there is no difference
[01:46] <Stavros> ah, thanks, i'm filing one now
[01:46] <lifeless> Stavros: bugs.launchpad.net/bzr
[07:47] <vila> hi all !
[07:49]  * fullermd waves at vila through the lightning.
[07:49] <vila> :)
[08:20] <jam> morning all
[08:21] <jam> Moggûh, jelmer (though you're probably not up yet :)
[08:21] <jam> morning vila
[08:21] <vila> hey jam !
[08:22] <jam> so vila, what are you working on these days? Still poking at the package importer mostly?
[08:23] <vila> I've been catching up with mails and reviews so far, I will focus on the p-i again now
[08:27] <vila> jam: oh, and 2.3.1 should have been released last week so I need to catch up with that too
[08:27] <jam> well, give it a sec, since I have a patch progressing through the stack :)
[08:27] <vila> jam: did you merge your fix up to trunk for the missing inventories ?
[08:27] <vila> hehe
[08:27] <jam> I'm up to 2.3
[08:27] <jam> which is where you get NEWS conflicts because of the split-out
[08:28] <vila> jam: I intend to work on 2.3.1 tomorrow only, I'd like to summarize all the mails about which plugins are carried by which distros first
[08:41] <mr-russ> Hi, I'm reading the smart http server documentation and setting up mod_python method of using http smart server.  Where do I find bzr-smart.py?
[08:43] <mr-russ> running ubuntu 10.04
[08:48] <vila> mr-russ: which doc are you reading ? bzr-smart.py doesn't appear to be part of the bzr sources
[08:49] <Peng> It's more or less part of the docs.
[08:49] <Peng> Last I checked.
[08:49] <mr-russ> yeah, that was my complaint really.  http://doc.bazaar.canonical.com/bzr.dev/en/user-guide/http_smart_server.html
[08:49] <mr-russ> but there is no way to easily find the source from that page.
[08:49] <mr-russ> after 10-15 minutes googling, I think https://lists.ubuntu.com/archives/bazaar/2006q4/020376.html  has the details I need.
[08:50] <Peng> mr-russ: But the source is in that page.
[08:50] <Peng> mr-russ: Copy and paste it.
[08:50] <mr-russ> thanks, excuse the dumb moment.
[08:51] <Peng> It's not ideal, of course. Maybe someone should stuff them all in contrib/ or somethuing.
[08:52] <mr-russ> yeah, it would be nice to have an example as part of the bzr doc when you apt-get.
[08:53] <mr-russ> I'm about to find out what I need to do to get modpywsgi installed.
[09:17] <jam> vila: on the plus side, it seems this was the only patch that needs merging-up
[09:17] <jam> so you've kept the branches fairly in-sync
[09:18] <vila> :)
[09:20] <mr-russ> modpywsgi seems difficult to find, links don't work.
[09:21] <jam> mr-russ: http://code.google.com/p/modwsgi/ ?
[09:21] <vila> mr-russ: :-/ patch welcome !
[09:21] <jam> if you can give updates to the docs, that would be great
[09:21] <mr-russ> what branch would I checkout?
[09:22] <vila> for http://doc.bazaar.canonical.com/bzr.dev/ it should be the bzr trunk itself
[09:23] <mr-russ> so there is no python file, I need an apache module now?
[09:23] <vila> and then follow the path from the url doc/en/user-guide, once there, there should be a .txt corresponding to the .html
[09:23] <vila> mr-russ: could very well be the case, that's why we generally encourage the use of bzr+ssh
[09:24] <mr-russ> okay.  I was trying to keep away from having server accounts for each user.
[09:25] <vila> shudder
[09:25] <vila> yeah, that's the other missing bit...
[09:25] <mr-russ> what does lp use under the hood?
[09:25] <vila> ssh :)
[09:25] <mr-russ> I understand the authentication issues I think
[09:26] <vila> mr-russ: for lp you authenticate with one of your registered ssh keys
[09:26] <mr-russ> maybe I'll switch back to ssh.  But is there a tute on restricting the ssh commands users can run?
[09:26] <Peng> LP doesn't use an ordinary sshd server, though.
[09:26] <vila> mr-russ: as in restricting the ssh command to bzr ?
[09:26] <mr-russ> yes.
[09:27] <mr-russ> you can only use bzr over ssh, no account login at all.
[09:27] <vila> oh, it's in ~/.ssh/authorized_keys IIRC
[09:27] <vila> let me check
[09:27] <mr-russ> yes, with the funny commands out the front.
[09:27] <mr-russ> It's getting those commands right that is always painful.
[09:27] <vila> indeed (searching for an example)
[09:28] <mr-russ> I think I may have gone that route first if I found a clear example.
[09:28] <mr-russ> I'm branching bzr now, so I'll see how I go with doc patches.
[09:28] <mr-russ> I've not used bzr with launchpad before, how does patch contribution work?
[09:29] <vila> mr-russ: so, in the general case: branch; hack hack; commit; push lp:~<lpname>/<project>/<meaningful-branch-name>
[09:30] <vila> mr-russ: 'bzr lp-open' will open the pushed branch page from where you can select: 'propose for merging'
[09:30] <mr-russ> cool.
[09:30] <mr-russ> I'm sure it's easy when I get the hang of it.
[09:31] <vila> mr-russ: for bzr you will need to go thru http://www.canonical.com/contributors
[09:33] <mr-russ> Oh the joy of the legal world :)
[09:33] <vila> mr-russ: yeah, the whole process is pretty easy, there is also 'bzr lp-propose' which further simplify some steps but I don't use it myself (for... various uninteresting reasons) so I can't comment precisely there
[09:34] <vila> mr-russ: yeah :-/ There is a work in progress to satisfy more people but as often with legal it takes time
[09:35] <mr-russ> http://thias.marmotte.net/2009/05/creating-a-restricted-bzrssh-smart-server/
[09:35] <mr-russ> does that look right for the bzrssh server setup?
[09:37] <spiv> mr-russ: looks highly plausible
[09:37] <vila> roughly yes, I'm not sure about the options restrictions (but they shouldn't harm) and I can't find back my example locally (I could swear I used one at some point :-/)
[09:37] <spiv> mr-russ: see also contrib/bzr_ssh_path_limiter in the bzr source tree
[09:37] <vila> spiv: hey !
[09:37] <spiv> Hey :)
[09:38] <mr-russ> I"m still waiting for my branch to finish downloading, not the greatest performance
[09:38] <mr-russ> I'll see if the lucid package installed contrib.
[09:38] <vila> mr-russ: I don't think contrib is ever installed (apart from the bash completion stuff though...)
[09:39] <mr-russ> that's what I'm seeing on my server.  waiting for branch to complete.
[09:39] <vila> mr-russ: so you server is lucid, you know you can use the stable ppa to get newer releases right ?
[09:40] <mr-russ> no.  As a standard kind of user, I use what's packaged by default.  That way it's 'supposed' to be support for 3-5 years.
[09:40] <vila> mr-russ: lucid provides bzr-2.1.1 while the ppa will gives you bzr-2.3.0 (and the associated plugins)
[09:40] <mr-russ> I usually upgrade with all LTS releases though.
[09:41] <vila> the stable PPA will support LTS as well
[09:41] <mr-russ> but LTS does not support the PPA :)
[09:42] <vila> the PPA content ?  no :)
[09:42] <vila> but *we* do :)
[09:42] <mr-russ> That is not what the average user will expect.
[09:43] <mr-russ> I will consider upgrading once I actually have this working neatly.
[09:43] <vila> via SRUs we may be able to provides 2.1.4 for lucid, but we are not there yet
[09:43] <mr-russ> too many things that I and others are used to with SVN.
[09:43] <vila> mr-russ: and what clients are you using ?
[09:44] <mr-russ> lucid.
[09:44] <mr-russ> all lucid at the moment.
[09:44] <mr-russ> command line bzr mostly.
[09:45] <mr-russ> I'm hoping to convince my work to switch from svn to bzr in the next year.  But that will require evaluation of windows tools, particularly with regard eclipse and a setup for ssh for users, possibly against AD.
[09:45] <vila> right, so, indeed, if you start using the PPA you'd better deploy it everywhere too, no urgency
[09:45] <vila> AD ?
[09:45] <vila> active dir
[09:45] <mr-russ> So I have a lot of learning todo before I can encourage them towards that stance.
[09:45] <vila> sry
[09:45] <mr-russ> Active Directory. ldap windows.
[09:46] <vila> right, so we don't support 2.1 on windows, only the most recent stable release (2.3)
[09:46] <vila> this shouldn't be a problem
[09:46] <vila> but if you'll get better performance with 2.3
[09:46] <vila> s/if//
[09:47] <vila> mr-russ: no pressure, just presenting the options
[09:47] <mr-russ> okay, that will go with we use RedHat as a server and I'm sure it has and older version of bzr.
[09:48] <mr-russ> ah the joy of learning new stuff.
[09:48] <vila> hehe
[09:48] <vila> right, I've heard rumors about some bzr packaging on rh but I've never been able to get a contact there, pointers welcome !
[09:49] <mr-russ> Well, I've backed back to using bzr+ssh, much easier.  No tricks with folder permissions when new branches are created?
[09:49] <vila> mr-russ: no, as  long as you use a single user on the server
[09:49] <mr-russ> We only have a regular education support contract and an account manager, so I'm not sure I can help you a lot with RH contacts.
[09:49] <vila> err
[09:50] <vila> as long as the same user owns the branch and is used to ssh connect, no permissions tricks are needed
[09:50] <mr-russ> I've created a bzr group.  added relevant users to it, and set all permissions to group rw(x).
[09:51] <vila> mr-russ: no worries, but if you find some bzr packages for rh or centos or fedora, whatever, I'd be happy to hear about it
[09:51] <mr-russ> now when anybody pushes a new branch, will group stuff get set correctly, or do I need to set some sticky bits or something like that?
[09:51] <mr-russ> vila: If I find anything or progress down that path, I'll report back.
[09:51] <vila> mr-russ: right, but the ssh server filters the group permissions bits IIRC which is the source of all the problems
[09:51] <vila> mr-russ: thx
[09:52] <vila> mr-russ: so the ssh setup is generally easier when a single user is created on the server and collect all authorized user keys
[09:52] <fullermd> Or use a real OS with simpler FS semantics   8-}
[09:52] <mr-russ> oh.
[09:53] <vila> fullermd: you mean... Windows ?
[09:53] <fullermd> You'll still need to correct on pushing new branches.  The perms in the repo for new data are preserved, but new branches just run off umask.
[09:53] <mr-russ> so user a single user account on server with shared ssh key, lock down to relevant command only and all the commit names are managed by bzr itself?
[09:54] <mr-russ> and bzr won't mess with permissions/ you can't set a different umask for that folder?
[09:54]  * mr-russ feels so out of his depth
[09:54] <vila> mr-russ: the commits always occur on local hosts and as long as you can push to a server, you can push your own commits or anybody else's
[09:55] <vila> mr-russ: think of it as a user with different roles, each role is associated to a key
[09:55] <vila> mr-russ: you give keys to users that can push to the server
[09:55] <vila> mr-russ: and you define a single user on the server for this role
[09:56] <mr-russ> ssh account developer has (x) ssh keys that can run bzr.
[09:56] <vila> on the server, yes
[09:57] <mr-russ> All developers on remote boxes  use;  bzr push bzr+ssh://user@my-bzr-server/path/to/bzr/branch/
[09:57] <mr-russ> where user is the common user.  Their ssh key is of course already setup properly.
[09:57] <vila> with an appropriate ~/.ssh/config you can even use bzr push bzr+ssh://my-bzr-server/path/to/bzr/branch/
[09:58] <mr-russ> I just wish I could short circuit the /path/to/bzr/branch to /branch.
[09:58] <mr-russ> I think I need to write a tutorial for this kind of setup.
[09:58] <vila> bzr+ssh://my-bzr-server/~/project/branch/
[09:59] <vila> '~' will expand to the ssh user home directory on the server
[09:59] <mr-russ> the URL I sent before fixes taht.
[09:59] <mr-russ> as the command forces the folder for you.
[09:59] <mr-russ> http://thias.marmotte.net/2009/05/creating-a-restricted-bzrssh-smart-server/
[09:59] <vila> mr-russ: http://paste.ubuntu.com/577750/ is an excerpt of my ~/.ssh/config
[10:00] <mr-russ> I think I have found a winning configuration.  Thanks all for your help.
[10:00] <vila> mr-russ: good !
[10:01] <mr-russ> and after 3 years of trying to really understand dvcs and how to set it up, I think I'm finally over the line.  I'm sure I'll find some merging issues and fun ahead.  But we are much further down the load.
[10:01] <mr-russ> s/load/road/
[10:02] <mr-russ> So if I created a tutorial on a central bzr setup as we have discussed, should it go in bzr/doc/en/tutorial?
[10:03] <vila> mr-russ: sounds like it, that would be awesome !
[10:04] <catphish> is it possible to create a shared / default branch.conf?
[10:04] <vila> mr-russ: may be check in admin-guide too
[10:04] <vila> catphish: what's your use case ?
[10:04] <catphish> eg. repo.conf or just plain bzr.conf
[10:05] <vila> catphish: there is a work in progress to allow that
[10:05] <catphish> well i am setting up some hooks, and i want them to run on all branches in a particular  repository
[10:05] <mr-russ> vila: can I send the contributor form to you, or to Mr Pool?
[10:05] <vila> catphish: see configurations.txt in lp:~bzr-core/bzr/devnotes for an almost up-to-date description
[10:06] <vila> mr-russ: poolie
[10:06] <vila> mr-russ: err, yeah, Martin Pool
[10:06] <mr-russ> yes, I know poolie is Martin Pool :)
[10:06] <catphish> thanks vila, bazaar.conf will probably do, i was really hoping to do it per-repo
[10:07] <vila> catphish: me too :)
[10:07] <vila> catphish: but out of curiosity (and to help ensure your use case is addressed in the future), can you tell me what kind of feature you're implementing with these hooks ?
[10:09] <catphish> vila: i run a repository hosting service, and i am using the post_change_branch_tip hook to update a log when people push
[10:10] <catphish> now, i could use a single hook globally, however in every other SCM, hooks are defined per-repository
[10:10] <catphish> i can't define it per-branch easily because users can dynamically create branches within their repository
[10:11] <catphish> my hook currently reads the name of a shell script from the [hooks] configuration parameter and executes it
[10:12] <mr-russ> vila: I've sent the agreement, so that mean magic happens and my contributions will be considered for merging?
[10:12] <catphish> so ideally, for compatibility with the way other SCM's work, I would like to be able to define the [hooks] configuration per repository
[10:13] <vila> mr-russ: yup, poolie should process it and from there we will land your contributions after reviewing them
[10:13] <mr-russ> thanks.
[10:16] <mr-russ> vila: what's the ppa address?
[10:22] <vila> https://launchpad.net/~bzr/+archive/ppa
[10:23] <vila> the various ppas are described at https://launchpad.net/bzr
[10:23] <mr-russ> and it's stable, even though it's labelled for developers?
[10:25] <mr-russ> okay, reading that page says it's stable releases.
[10:26] <vila> mr-russ: oh, it's labeled for 'Bazaar Developers' because they are the maintainers not the targeted users
[12:35] <catphish> i am having problems with locking
[12:35] <catphish> bzr: ERROR: No such file: '/data/repos2/b5/70ff4d-c20f-d082-210b-d51b37b6bb92/default/.bzr/branch/lock/held'
[12:36] <catphish> a directory that quite clearly does exist
[12:40] <jelmer> hi catphish
[12:40] <catphish> hi
[12:40] <jelmer> catphish: when do you get that error, what are you trying to do?
[12:43] <catphish> jelmer: http://paste.codebasehq.com/pastes/xpt7u0ga7152
[12:43] <jelmer> catphish: is it perhaps a path that exists remotely?
[12:44] <catphish> it DOES exist remotely, see the ls
[12:48] <jelmer> catphish: sorry, I missed that that was on the remote host
[12:49] <jelmer> catphish: This is probably a bug in the smart server, can you file a bug report?
[12:49] <catphish> ideally i'd like to be able to confirm whether it's a bug in my http server first
[12:50] <jelmer> catphish: It could be, but I think a bug in the bzr smart server is a lot more likely
[12:51] <catphish> jelmer: the error certainly implies an error in the smart server
[12:51] <catphish> the file it is complaining about clearly exists
[12:51] <jelmer> jam: Goeiesmorgens!
[12:51] <catphish> where do i report it?
[12:51] <jam> jelmer: when you sleep in, boy do you sleep in :)
[12:52] <jelmer> jam: :)
[12:52] <jelmer> catphish: it might be that the path is being sent across the wire and the bzr client tries to access it locally
[12:53] <catphish> good point
[12:53] <catphish> i'm using a sucky old client
[12:53] <catphish> will try upgrading first
[12:53] <jelmer> jam: I'm having fun with the CommitBuilder.. do you know what fast deltas are, and why they are a reason for avoiding record_iter_changes() ?
[12:54] <jam> jelmer: dirstate can compute deltas quickly, and 2a can store deltas quickly
[12:54] <jam> so rather than build the whole inventory
[12:54] <jam> and save it
[12:54] <jam> we build a delta and apply it
[12:54] <jam> it was slower in pre-2a
[12:54] <jam> and didn't handle merge commits for a while
[12:54] <jam> I think that has been fixed
[12:55] <jam> but I'm not positive
[12:55] <jelmer> ah, thanks
[12:56] <jam> I'm pretty sure record_iter_changes is the recommended path right now
[12:57] <jelmer> jam: at the moment we seem to use record_entry_contents() if the repository format supports nested trees, the commit has excludes or if the format doesn't support fast deltas /and/ there is more than one parent
[12:58] <jelmer> The last condition is the one you mentioned, I assume?
[12:58] <catphish> jelmer: i think i found my problem by looking closer at the protocol log
[12:58] <jam> I'm not sure what is ANDed and what is ORed in that statement
[12:58] <jam> but sure
[12:59] <jam> I trust that you're looking at it more closely than I
[12:59] <jam> we don't support it with nested trees, because it isn't well defined
[12:59] <jam> so no work was actually done on it
[12:59] <jelmer> filter_iter_changes() does actually handle kind == 'tree-reference' though, strangely enough
[13:00] <jam> jelmer: that doesn't mean that all the other bits of the stack do
[13:00] <catphish> jelmer: the smart protocol was being sent this by my http server: ["rename", "default/.bzr/branch/lock/held", ".bzr/branch/lock/broken.8y5qi3f3qq5hft5r28km.tmp"]
[13:00] <jelmer> jam: right
[13:01] <catphish> the branch name wasn't appended to the second parameter, the error it returns is misleading
[13:01] <jelmer> jam: anyway, it seems like the only thing that really matters for me is the exclude parameter, the others can't be triggered for foreign formats.
[13:02] <jam> jelmer: well, if you want to implement --exclude handling for record_iter_changes, I'd be ok with that
[13:02] <jelmer> catphish: Ah, I see
[13:02] <jam> I think there was some discussion about how it should be done
[13:02] <jam> that it should be passed into iter_changse
[13:02] <jam> rather than filtered on top, etc.
[13:03] <catphish> i guess my code that injects branch names needs to be a little more intelligent
[13:03] <jelmer> catphish: you're running a custom http server?
[13:03] <catphish> jelmer: yes
[13:05] <catphish> it just accepts http requests and passes them on to bzr serve --inet
[13:06] <catphish> unfortunately because my url structure contains a repo and a branch, it is necessary to inject the branch name into commands
[13:06] <catphish> right now i just have (ruby code): command[1] = branch + '/' + command[1] if branch
[13:06] <catphish> assuming the second parameter is always a path
[13:09] <catphish> unfortunately the smart protocol isn't all that well documented, so i'm not sure which commands have more than one path as parameters
[13:09] <catphish> though i'd appreciate it if anyone who knows could tell me :)
[13:10]  * jelmer isn't all that familiar with the smart protocol either, unfortunately
[13:10] <catphish> i can just address them as i find them
[13:42] <catphish> looks like my original problem is fixed anyway :)
[13:50] <ChrisCauser> Hi guys, have I come to the right place for bzr-svn help?
[13:50] <catphish> probably
[13:51] <ChrisCauser> catphish Thanks
[13:51] <catphish> by the way, is this room affiliated with canonical and launchpad directly?
[13:51] <ChrisCauser> Basically, I'm getting weird things with bzr 2.4 dev and was wondering if anyone had seen it before?
[13:51] <ChrisCauser> $ bzr commit
[13:51] <ChrisCauser> Committing to: svn+https://SVN_REPO
[13:51] <ChrisCauser> modified FILES
[13:51] <ChrisCauser> bzr: ERROR: Layout CustomLayout([PATH_FROM_SVN_ROOT],[]) does not support custom branch paths.
[13:52] <ChrisCauser> Argh, stupid formatting
[13:52] <vila> catphish: not per se, but many people haunt the same channels
[13:52] <ChrisCauser> Basically, If I checkout a svn repo, I get the error above
[13:52] <ChrisCauser> If I unbind it and push to it, there is no error
[13:52] <ChrisCauser> Does anyone know what I'm doing wrong? The svn layout is indeed a little strange
[13:53] <catphish> i wasn't really sure how closely bazaar was tied to canonical and to launchpad
[13:54] <catphish> but it's not really important
[13:57] <jelmer> ChrisCauser: PATH_FROM_SVN_ROOT is not the path you have checked out?
[13:58] <ChrisCauser> jelmer: Apologies that wasn't clear.  the svn root is at SVN_ROOT. I checkout SVN_ROOT/masterfiles/production and PATH_FROM_SVN_ROOT comes up as ['masterfiles/production']
[13:59] <jelmer> ChrisCauser: but "bzr commit" says "Committing to SVN_ROOT" ?
[14:00] <ChrisCauser> jelmer: No. It says "Committing to SVN_ROOT/PATH_FROM_SVN_ROOT"
[14:02] <jelmer> ChrisCauser: hmm, that's odd. Do you perhaps have push_merged_revisions enabled? Does the branch have tags?
[14:04] <ChrisCauser> jelmer: It's a pretty bog standard bazaar install. The checkout is fresh so has no tags. Interestingly, I have a second svn repo that I'm committing to just fine which has a standard trunk/branches/tags layout
[14:05] <jelmer> ChrisCauser: Can you try that commit again with BZR_PDB=1 set and pastebin a backtrace?
[14:08] <vila> catphish: bzr is a GNU project for which Canonical is the copyright holder
[14:08] <ChrisCauser> jelmer: Thanks for that. It has entered the debugger but the lines prior to that are at http://pastebin.com/3fX6dTQP
[14:09] <catphish> that's fine then, it was primarily the integration with launchpad that concerned me, seemed that a bit of a commercial injection
[14:10] <vila> catphish: look harder :) 1) launchpad is free software, 2) the integration is done via a single plugin (bundled with bzr core though)
[14:10] <catphish> vila: that's cool, it hadn't occurred to me that LP was free / multihomed :)
[14:11] <catphish> i won't concern myself then
[14:12] <vila> catphish: see https://launchpad.net/launchpad, licence: GNU Affero GPL v3
[14:12] <catphish> i did :)
[14:12] <catphish> thanks
[14:12] <vila> hehe
[14:14] <catphish> how do i read global config? right now i am using TreeConfig to read branch config but it doesn't fall back to the user or system config
[14:16] <catphish> Just Config?
[14:20] <jelmer> catphish: bzrlib.config.GlobalConfig
[14:21] <jelmer> ChrisCauser: can you run "bt" in the python debugger and pastebin the output?
[14:22] <ChrisCauser> jelmer: http://pastebin.com/Ak7e0m2N
[14:24] <catphish> jelmer: sorry to be dumb but how do actually use the GlobalConfig class to read a config option?
[14:24] <jelmer> catphish: GlobalConfig().get_user_option('bar') IIRC
[14:24] <jelmer> ChrisCauser: hmm, that's odd. It's trying to push a non-mainline revision for some reason. What does "bzr missing SVN_URL" report?
[14:26] <catphish> jelmer: works like a charm, thanks
[14:32] <ChrisCauser> jelmer: I appear to get back the entire history of the repo. There is an svn revno right up to the point I see my first [merge]. Could this be a clue? I have two branches which I merge via bzr locally and push to svn separately. Any merges I have done purely in svn don't seem to have revno: number [merge] written on them.
[14:35] <jelmer> ChrisCauser: yes, that's probably related. Was the branch you're working in currently based on the remote svn repo?
[14:35] <jelmer> ChrisCauser: Is there a difference in any way between the local and the remote commits reported by "bzr missing"
[14:35] <jelmer> ?
[14:41] <ChrisCauser> jelmer: So basically I had two branches, development and production. I branched both of them and merged back and forth and pushed to the svn repo.
[14:43] <ChrisCauser> jelmer: On the same machine, but in a completely new bzr repo, I have checked out the production branch and it seems to have checked out the branch but the missing command reports that the 200 commits I have made on svn are not commited locally yet I have 200 identical commits locally.
[14:44] <ChrisCauser> jelmer: There are no local commits as yet. This is a fresh checkout that I haven't changed.
[14:46] <catphish> jelmer: it appears that the problem with my http server isn't as simple as i thought, the bzr client is (sometimes) sending duplicate identical HTTP requests at once
[14:46] <catphish> so it sends 2 lock requests, the first succeeds and the second one of course fails
[14:47] <catphish> i'm sure there's a reason, just can't see what it is :(
[14:48] <jelmer> catphish: is there any reason for using a custom http server rather than e.g. just apache with wsgi?
[14:48] <catphish> yes
[14:49] <vila> catphish: highly suspicious, there shouldn't be multiple lock requests coming from a bzr client
[14:49] <vila> any gentoo packager around ?
[14:49] <jelmer> ChrisCauser: can you spot any differences in the revisions present locally and remotely?
[14:49] <catphish> i'll get a full packet dump and see if i'm doing something to upset it
[14:50] <vila> http://packages.gentoo.org/category/dev-vcs?full_cat seem to imply (I'm a gentoo noob) that 2.3.0 is not available (hardmask). What's the rationale ?
[14:51] <jelmer> vila: They filed some bugs earlier about several plugins not having a compatible release with 2.3 out yet
[14:51] <vila> jelmer: ho ! thanks. Now that you mention it...
[14:52] <ChrisCauser> jelmer: I've just realized, when you say SVN_URL, is that the path to the SVN_ROOT or does it include the path? If it includes the path then bzr is reporting that the branch is up to date.
[14:52] <jelmer> ah, hmm.. time for my afternoon tea!
[14:52]  * jelmer runs off
[14:52] <jelmer> ChrisCauser: including the path
[14:53] <jelmer> ChrisCauser: even in the original branch?
[14:53] <ChrisCauser> jelmer: Hope you have a nice tea! I'm afraid there is no original bazaar branch as I suffered data loss.
[14:54] <jelmer> ChrisCauser: I was just teasing vila since he was going to ask me about doing a bzr-svn release...
[14:54] <vila> jelmer: haha
[14:54] <ChrisCauser> jelmer: Ooops. Sorry
[14:54] <vila> jelmer: I haven't made the connection yet, but I plan to freeze 2.3.1 tomorrow, be ready ;-D
[14:54] <jelmer> ChrisCauser: I mean, the original branch in which you tried to run "bzr commit"
[14:58] <ChrisCauser> jelmer: Oh, there is now only one bzr branch checked out at the moment, the "production branch." I originally had on my last computer two branches "production" and "development" (both in svn) which have now gone and these were the ones that I merged back and forth
[14:58] <jelmer> ChrisCauser: Hmm, ok
[14:58] <jelmer> I wonder why it's trying to commit to a non-mainline branch then
[14:59] <jelmer> the change you're trying to commit, what sort of change is it?
[14:59] <ChrisCauser> jelmer: I've just tried to check out the development branch and that is causing another error on checkout: http://pastebin.com/XrQmAQet (hopefully nothing too incriminating here ;) )
[15:00] <jelmer> ChrisCauser: but it still did the checkout I presume (those are just warnings)?
[15:00] <ChrisCauser> jelmer: Yes, it still did the checkout
[15:01] <jelmer> ChrisCauser: the change you're trying to commit, what sort of change is it?
[15:02] <ChrisCauser> jelmer: It happens on modifying, adding and removing
[15:02] <jelmer> ChrisCauser: any merges involved?
[15:02] <ChrisCauser> No
[15:06] <jelmer> ah, I see what's happening
[15:06] <jelmer> ChrisCauser: this is a regression caused by bzr 2.4
[15:07] <jelmer> ChrisCauser: please file a bug
[15:07] <ChrisCauser> jelmer: Brilliant :) Will do.
[15:07] <ChrisCauser> jelmer: Is there any information that will help describe the situation?
[15:08] <jelmer> ChrisCauser: bzr-svn doesn't implement Branch.import_last_revision_info_and_tags(), which was added recently
[15:10] <jelmer> hmm, Branch.import_last_revision_info_and_tags doesn't make sense
[15:12] <jelmer> ChrisCauser: can you try trunk?
[15:12] <ChrisCauser> of bzr-svn or bzr?
[15:12] <jelmer> ChrisCauser: bzr-svn
[15:18] <ChrisCauser> jelmer: :-$ I'm having a bit of difficulty here. I got a "AttributeError: 'SvnBranch' object has no attribute 'source'" when I commited to the same checkout and when I checkout a new branch and commit I get an invalid http code (401)
[15:19] <ChrisCauser> jelmer: Did I not supply enough flags to the setup script?
[15:35] <jelmer> ChrisCauser: I've committed a fix, please try again
[15:57] <catphish> does anyone know if bzr with http has problems with keepalive? i'm pretty sure it tries to send requests down connections that have already been closed
[16:06] <vila> catphish: it's been a very long time since we had reports about problems with keep-alive
[16:07] <vila> catphish: you can use -Dhttp on your bzr client commands to get a debug output of all requests
[16:07] <vila> catphish: the output should go to ~/.bzr.log IIRC
[16:07] <catphish> yeah, i tried that, the duplicates i'm seeing don't appear there
[16:07] <catphish> but i see them in a packet dump
[16:07] <catphish> so i'm a little confused at the moment
[16:07] <vila> weird
[16:07] <vila> do you have some proxy may be ?
[16:08] <catphish> will post some info if it persists
[16:08] <catphish> i do have a proxy, which was my first suspicion, but the duplicate requests are visible at the client too
[16:08] <vila> catphish: if -Dhttp doesn't output the faulty request, bzr is out of the equation
[16:08] <vila> err
[16:09] <vila> what do you mean by 'visible at the client' ?
[16:09] <catphish> i mean, wireshark on my client shows 2 http requests to lock a repo
[16:09] <catphish> one at the end of a kept-alive http session
[16:09] <catphish> and another at the start of a new http connection
[16:10] <catphish> however i will confirm that and get some logs and evidence together to make sure i'm not being stupid
[16:10] <catphish> i have no doubt it's the result of one of my proxies, but i need to establish exactly why
[16:16] <catphish> vila: actually the duplicate http requests do show up in the http log
[16:17] <vila> catphish: ha ! now we've got something :)
[16:17] <catphish> but the response doesn't appear
[16:17] <catphish> http://paste.codebasehq.com/pastes/sxze691xetsn
[16:17] <vila> catphish: can you pastebin the relevant part making sure you remmo... you're too fast :)
[16:18] <catphish> i didn't remove my auth details
[16:18] <vila> catphish: argh, change your password, the Auth header is only lightly protected
[16:18] <catphish> i know that all too well
[16:18] <vila> ok
[16:18] <catphish> brb
[16:19]  * vila should really obfuscate these headers...
[16:20] <catphish> seems wise
[16:20] <vila> catphish: can you paste a bit more ?
[16:20] <catphish> sure
[16:20] <fullermd> Bah.  Silly diff algorithm, picking the wrong bit of code to leave in place.
[16:21] <vila> fullermd: ha, one of those cases, painful heh ?
[16:21] <catphish> http://paste.codebasehq.com/pastes/64m6nvijy788
[16:22] <fullermd> The "oh crap, why and how did I delete that important code?!" sudden-panic is particularly fun.
[16:22] <vila> :)
[16:23] <catphish> passwords changed, dunce cap applied
[16:23] <vila> :)
[16:23] <vila> err, didn't I just say that ?
[16:24] <vila> catphish: so, the first thing that catch my eye is that the keep-alive is reset far too early (at 92 !)
[16:26] <catphish> vila: what's odd is that the request is sent, the reply is received (at least to the packet sniffer on my pc), but bzr misses the reply and opens a new connection to send the request again
[16:26] <vila> ha crap, the pieces I'm searching for are logged only when _debuglevel is set
[16:26] <vila> catphish: can you edit bzrlib/transport/http/_urllib2_wrappers.py for a test /
[16:26] <vila> ?
[16:27] <catphish> sure
[16:28] <catphish> but you'll need to guide me in the right direction since i'm not a python developer
[16:28] <vila> there is a DEBUG variable at the top the file set to 0, setting it to 3 will give us more data
[16:28] <vila> no worries, you just have to change 0 to 3 :)
[16:28] <vila> hmm, is upgrading to bzr-2.3.0 an option too ?
[16:29] <catphish> wow
[16:29] <catphish> that's a lot of info
[16:29] <vila> I don't remember related fixes since 2.1.1 but it's quite old so I may be wrong
[16:30] <vila> catphish: I don't remember the details, but 3 should output a lot about proxies but only once whereas 2 will output for requests but not significantly more than -Dhttp
[16:32] <ChrisCauser> jelmer: Thank you so much. That did the trick wonderfully. I can now checkout and commit to an svn repository.
[16:33] <vila> catphish: concretely, I suspect some transient error trigering a resent of the same request
[16:33] <catphish> i have a full log now
[16:33] <catphish> just going to clean the passwords and paste it
[16:33] <vila> catphish: in your case, it could be that the request went through to the server but we still get what looks like a transient error
[16:34] <catphish> Received exception: [BadStatusLine('0\r\n',)]
[16:34] <vila> urgh, the infamous :(
[16:34] <catphish> you know it well?
[16:35] <vila> catphish: more or less, it generally means a bug somewhere else :-/
[16:36] <vila> catphish: the status line is something like 'HTTP/1.1 200 OK' , if we got a bad one... it could mean we didn't consume the socket content properly
[16:37] <catphish> i wonder if it's bad handling of the chunked encoding
[16:39] <catphish> since all responses end with 0\r\n
[16:39] <catphish> it may have still had 0\r\n in the buffer from the previous request
[16:39] <catphish> and read it as the start of the next response
[16:40] <vila> catphish: that would trigger with the second request then
[16:41] <catphish> vila: http://paste.codebasehq.com/pastes/eaoht6hslbts
[16:41] <catphish> there's the log snipper
[16:41] <catphish> *snippet
[16:44] <vila> where is that 'reply:' coming from ?
[16:46] <catphish> http://paste.codebasehq.com/pastes/49osq8c9otx7
[16:46] <catphish> that's the data on the tcp socket
[16:47] <catphish> only the bottom is relevent (the lock_write) request
[16:48] <catphish> but the response appears the same as the others, nothing unusual
[16:48] <vila> catphish: I mean, did you type that or is it coming from bzr ?
[16:48] <catphish> from bzr
[16:49] <vila> grep 'reply:' returns no matches
[16:50] <catphish> what are you grepping?
[16:50] <vila> the bzr sources for 2.1.1
[16:50] <catphish> you're right, but i can see it clearly on my screen
[16:51] <vila> ho ! probably from httplib itself
[16:51] <catphish> 'send:' doesn't appear either
[16:51] <vila> hmm, what python version are you using ?
[16:52] <vila> confirmed, from httplib when debuglevel is set (via DEBUG)
[16:52] <catphish> Python 2.6.5 (r265:79063, Apr 16 2010, 13:09:56)
[16:54] <vila> hmmm
[16:54] <vila> 0\r\n is an empty chunk no ?
[16:54] <catphish> correct
[16:54] <catphish> more than that, it's the end of the response
[16:55] <vila> one possible cause would be that the server issues an empty chunk wrongly (as in bzr doesn't expect it), but we've never encountered such servers...
[16:55] <catphish> empty chunks are necessary as far as i know
[16:55] <catphish> they mark then end of the chunked response
[16:55] <catphish> http://en.wikipedia.org/wiki/Chunked_transfer_encoding#Encoded_response
[16:56] <catphish> The response ends with a zero-length last chunk: "0\r\n" and the final "\r\n".
[16:56] <vila> sure, but what if the sever is sending two of them instead of one
[16:56] <vila> catphish: just throwing ideas there
[16:56] <catphish> it's not on this occasion
[16:57] <vila> catphish: ok
[16:57] <catphish> i sent the raw tcp dump
[16:57] <vila> where ?
[16:58] <catphish> http://paste.codebasehq.com/pastes/49osq8c9otx7
[16:58] <catphish> that's just one tcp connection
[16:58] <vila> wow, I missed that
[16:58] <catphish> specifically the one that is terminated prematurely
[16:58] <catphish> you see it send the successful response at the end
[16:58] <catphish> the one that is never received by bzr
[17:00] <vila> indeed, so you got that from the server side ?
[17:00] <catphish> no
[17:00] <catphish> packet sniffer on the client
[17:00] <vila> O_o
[17:00] <catphish> it's 100% what the http library is seeing
[17:02] <vila> waitaminute
[17:02] <catphish> :)
[17:02] <catphish> i'd love to hear that my server is doing something dumb
[17:02] <vila> the status lines appears at the end of the lines in a weird form
[17:02] <vila> hmm
[17:03] <vila> may be just some formatting wart of the packet sniffer but...
[17:03] <catphish> the response status lines are just on the same line as the end of the request
[17:03] <catphish> because technically there is no \n between them
[17:03] <vila> well, they don't travel in the same part of the socket either
[17:03] <catphish> unfortunately i had no way to colour in the data in each direction
[17:03] <vila> yup
[17:04] <catphish> you have to assume where they client and server packets start and end
[17:04] <catphish> "....d16:Software version5:2.1.1es...!l25:Branch.get_stacked_on_url1:.ee" << end of request
[17:04] <catphish> start of response >> "HTTP/1.1 200 OK"
[17:05] <vila> catphish: so from the send:/reply: in the full trace you should be able to match that no ?
[17:05] <vila> ha, well, no
[17:06] <vila> httplib will only tell you that it read the headers but nothing about the body
[17:06] <vila> so, try setting DEBUG to 9
[17:06] <catphish> eek ok
[17:06] <vila> don't worry, only 1 2 3 9 are used
[17:07] <vila> 9 will output a bunch of crap once at the beginning and then the bodies (well, some bodies IIRC :-/)
[17:07] <catphish> ok
[17:07] <catphish> i'll try it
[17:08] <vila> more precisely the bodies that the higher levels didn't consume...
[17:08] <vila> ... damn, that's silly, we are indeed searching for a case where bzr fail to consume such bory remains :(
[17:10] <catphish> i don't think that made any difference to the log
[17:11] <vila> catphish: did you see any 'Consumed body:' ?
[17:11] <catphish> no
[17:12] <vila> I'm a bit lost :-/
[17:12] <vila> catphish: looking at the modifications in _urllib2_wrappers *after* 2.1.1, I don't see clearly connected modifications but some may apply...
[17:13] <vila> catphish: what os are you using on the client and the server ?
[17:13] <catphish> ubuntu 10.04
[17:13] <catphish> 32 and 64 respectively
[17:13] <catphish> the server is actually an apache2 proxy and a backend server
[17:14] <vila> shudder... nothing weird there
[17:15] <vila> catphish: anyway, there is a PPA you can use to upgrade both: https://launchpad.net/~bzr/+archive/ppa
[17:15] <catphish> it's a complicated arrangement, which is why i'm focusing this discussion on what the client sees
[17:15] <vila> catphish: sure, and you're doing well, it's just that remote debugging is.... hard :-/
[17:15] <catphish> the server is running 2.3.0 from easy_install
[17:16] <vila> catphish: and the extensions get compiled with easy_install ?
[17:16] <catphish> i honestly don't know
[17:16] <vila> not that this should make a difference...
[17:16] <catphish> i haven't needed any
[17:16] <vila> catphish: oh yes you need them :)
[17:16] <catphish> why?
[17:17] <vila> catphish: otherwise we use the python fallback implementation and the performance suffers
[17:17] <catphish> ah
[17:18] <vila> catphish: the ppa is the next best thing after the official Ubuntu releases
[17:20] <vila> catphish: you just need to do 'sudo add-apt-repository ppa:bzr/ppa' and you'll get the repository added
[17:22] <catphish> not sure what best to do
[17:22] <catphish> interestingly if i disable keepalive at the server side, the client receives the connection: closed header and sends another request anyway
[17:23] <catphish> maybe i'll just try the ppa and tell customers to do the same
[17:25] <catphish> i'm also trying to get my post_change_branch_tip hook on the server running when i push over http
[17:25] <catphish> but hopefully that won't be a problem
[17:26] <vila> catphish: right, without keepalive, the things are far simpler, no need to babysit the socket content (but that's not enough evidence to confirm a bug in the bzr client side there :-/)
[17:27] <vila> catphish: https is not involved here right ?
[17:28] <catphish> no, i pulled that ages ago because it was totally broken with my version
[17:28] <catphish> the same problem exists with the 2.3.0 ppa version
[17:29] <vila> installed on both client and server ? (just checking)
[17:29] <catphish> no, the server is running the 2.3.0 from easy_install
[17:29] <vila> hmm, shouldn't be relevant
[17:29] <catphish> but that's almost entirely irrelevant since the http stuff is done in ruby
[17:29] <catphish> and in apache
[17:34] <catphish> well definitely a server problem
[17:34] <vila> catphish: ? why ?
[17:35] <catphish> because i can't be the only person using the smart protocol over http
[17:35] <vila> oh no, you aren't
[17:35] <catphish> and since i'm using the lastest version, something must be different about my server
[17:35] <catphish> not a bug necessarily
[17:35] <catphish> but something about my server that bzr or the http library doesn't like
[17:36] <vila> catphish: try pinging spiv, he's in AU times and should arrive later, I'm about to EOD myself
[17:36] <catphish> where are you?
[17:36] <vila> catphish: what is the most troubling for me is that your tcp dump looks fine
[17:37] <vila> catphish: france
[17:37] <catphish> ah ok
[17:37] <catphish> definitely home time then :)
[17:37] <catphish> i thought my tcp dump looked fine, and i don't do any of the keepalive or chunked encoding myself so i trust that it's correct
[17:37] <vila> catphish: spiv should be able to validate this stream better than me
[17:38] <vila> catphish: you mean your server do something between the bzr server and the client ?
[17:39] <catphish> in my case the 'bzr server' is just "bzr serve --inet"
[17:39] <catphish> and there's a ruby server sitting in front of it, with an apache proxy
[17:40] <catphish> one day i'll explain why that is
[17:40] <vila> but in this case you're just relaying the bytes right ?
[17:40] <catphish> correct
[17:40] <lifeless> uhm
[17:40] <lifeless> so bzr+http:// uses a different encapsulation to bzr://
[17:40] <catphish> the only thing i interfere with is the request, prepending the branch name to any paths
[17:41] <jam> vila: it is very funny to still see you online at 7pm my time. but I realize, you never were very good at stopping by 5/6 :)
[17:41] <vila> jam: :)
[17:41] <catphish> vila: i will try getting rid of the chunked encoding
[17:41] <catphish> there's no need for it
[17:42] <lifeless> catphish: you probably need to get a wsgi service up and forward to that, not to bzr serve --inet
[17:42] <catphish> lifeless: i hope i don't need to do that
[17:42] <catphish> since my implementation works well, apart from these randomly dropped http sessions
[17:42] <jam> lifeless: I believe he wants to use a ruby server
[17:42] <lifeless> jam: sure, you can do that
[17:42] <vila> catphish: worth a try, we don't it need it AFAIR but I think it's handled by httplib so we shouldn't care either... but may be not
[17:43] <lifeless> jam: I'm just trying to remember the exact framing changes for bzr over http
[17:43] <catphish> i think the problem is in httplib personally
[17:43] <catphish> chunked should never be necessary
[17:44] <catphish> vila: thanks very much for taking so long to help debug and tracing it to the 0\r\n
[17:44] <vila> catphish: always happy to help (TM by jam ;)
[17:45] <catphish> vila: setting a content-length prevented my http server from using chunked encoding
[17:45] <catphish> and... it works
[17:46] <catphish> now just to get the hook working and i have a fully working service :)
[17:46] <vila> catphish: huh, how stupid ! I didn't check the Content-Length !
[17:46] <catphish> content-length is not required for chunked encoding, they're mutually exclusive
[17:46] <catphish> but apparantly one works and the other doesn't :)
[17:47] <catphish> so that'll do
[17:47] <catphish> i prefer sending content-length anyway, much simpler approach
[17:50] <vila> catphish: indeed, I used chunked encoding so long ago I forgot it *is* targeted at unknown length contents :-D
[17:50] <catphish> anyway i must get home
[17:51] <catphish> thanks again :)
[17:56] <guest> hello, I have a question on hooks and was wandering if someone could have time to help ...
[17:56] <lifeless> ask away
[17:57] <guest> together with source files I have a compiled file versioned as well, so need to not forget to compile before commiting
[17:57] <guest> so was thinking, can it be done in a hook (pre_commit etc) or I'll have to do it outside in a batch running compiler first then bzr commit?
[18:00] <lifeless> guest: you are storing the compiled versions in bzr?
[18:00] <guest> yes
[18:00] <lifeless> if you run 'bzr help hooks | less' and look for 'start_commit
[18:00] <lifeless> '
[18:00] <lifeless> that hook runs before bzr starts calculating the commit
[18:01] <lifeless> so it can change things however you like
[18:02] <guest> aha, I was just reading that, figured pre_commit is not good since it already has deltas, so start_ commit is the way to go. great, thanks a lot :)
[18:31] <briandealwis> hi jelmer.  I saw yesterday that you might try to add an env var to specify remote branch names in bzr-git?
[18:59] <Stavros> hello
[18:59] <Stavros> can someone explain the pipeline plugin to me? it looks like it does exactly what i want, but i don't get all the pumping
[19:02] <beuno> Stavros, have you seen: http://www.youtube.com/watch?v=HujoyGSq8n4
[19:02] <Stavros> i haven't, i'll watch that now, thanks
[19:17] <Stavros> hmm, that video mentions the same things as the docs
[19:17] <Stavros> basically what i want is colocated branches with uncommitted changes being stored in the branch
[19:17] <Stavros> which is exactly what pipes do
[19:18] <Stavros> but with colocated branches i can merge into trunk whenever i finish a feature in a branch
[19:18] <Stavros> whereas pipes always go from top to bottom
[19:18] <Stavros> which is what i don't understand, what sort of workflow needs things to go from top to bottom?
[19:27] <shakaran> Hi, I have a bzr repository, but I want merge a commit from a svn repository. It is possible? I try with bzr-svn merge -c 419 svn_url_repo, but it don't work
[19:38] <shakaran> I am doing a:
[19:38] <shakaran> svn diff -r 419 snv_url_repo
[19:38] <shakaran> For get the diff, but this is tricky, someone with better solution?
[22:14] <jelmer> re
[22:14] <jelmer> briandealwis: hi
[22:14] <briandealwis> hi jelmer
[22:14] <jelmer> briandealwis: It's a gross hack so I won't add it to bzr-git itself, but I'm looking at providing a patch that does that
[22:15] <briandealwis> that's cool, jelmer.  I hurt my brain trying to figure out git's push command line.  Gross hacks are preferrable.
[22:16] <briandealwis> I currently use Eclipse's EGit to do pushes :)
[22:16]  * jelmer wished there were some more people to help with eclipse-bzr :-/
[22:16] <mr-russ> eclipse has a git plugin?
[22:16] <mr-russ> I wish that too.
[22:17] <mr-russ> I'd like to make use of eclipse-bzr.  But my python and java skills don't exist.
[22:17] <briandealwis> mr-russ: yeah.  They're moving to git.
[22:17] <briandealwis> mr-russ: There are two Eclipse projects: JGit, equivalent to Dulwich, and EGit, providing Eclipse tooling
[22:18] <mr-russ> Oh, that's going to hurt.  Good eclipse support makes the game different.
[22:19] <briandealwis> mr-russ: the good news is that the EGit tooling reflects Git.  My thoughts were that if bzr-git can push to branches, then BzrEclipse may be a happy medium.
[22:20] <briandealwis> Gerrit looks pretty nice too.
[22:20] <lifeless> briandealwis: which 'they' are moving to git?
[22:21] <jelmer> eclipse itself I think?
[22:21] <briandealwis> lifeless: There's a concerted effort to move all Eclipse projects to Git.
[22:21] <lifeless> briandealwis: oh, interesting.
[22:21] <briandealwis> Almost all projects are currently either still CVS or Subversion
[22:32] <wolfpack> Hey, Can bzr push the code on launchpad with http protocol? I am working behind http proxy and cannot make ssh connection.
[22:33] <spiv> wolfpack: no, Launchpad doesn't run the bzr service over http
[22:34] <wolfpack> spiv: but branching is allowed! So is there any options to work on the projects?
[22:34] <wolfpack> any other option *
[22:34] <spiv> https://bugs.launchpad.net/launchpad/+bug/165087
[22:36] <spiv> wolfpack: you can sometimes convince http proxies to carry SSH traffic
[22:36] <wolfpack> spiv: How?
[22:36] <spiv> If you're using Ubuntu, try installing the 'corkscrew' package and using that
[22:38] <spiv> It can help to have an SSH server of your own somewhere listening on port 443 (i.e. the HTTPS port)
[22:38] <spiv> Otherwise, I don't know that there's much you can do.
[22:39] <wolfpack> Are you referring to this "http://omappedia.org/wiki/Using_bzr_and_launchpad_behind_a_proxy "
[22:40] <spiv> wolfpack: I hadn't seen that link before, but those instructions look reasonable
[22:41] <wolfpack> spiv: Well, I tried that but that does not works :(
[22:42] <spiv> Your proxy is probably restricts access to ports other than 80 and 443 then :(
[23:08] <wolfpack> thanks for helping .