=== Ursinha-afk is now known as Ursinha [01:32] hello [01:33] is there a way to have bzr store branches in the same directory and switch uncommitted changes too? [01:33] basically, colocated branches but with shelving [01:34] bzr switch should just do that [01:35] lifeless: last i tried, switch didn't switch uncommitted changes, was that added? [01:38] lifeless: nope, it doesn't [01:39] what do you mean by switch uncommitted changes then ? [01:39] for me, it keeps uncommitted changes in the tree, so I can commit them to another branch. [01:39] oh [01:39] i mean shelve them in the branch [01:39] so i can have uncommitted changes per branch [01:40] for example, i'm working on feature 1 but it's half done [01:40] so, standard shelve is in the working tree [01:40] yes, but per-branch [01:40] the pipeline plugin adds a shelf per branch as well [01:40] hmm [01:40] nothing that will automatically shelve everything on swich, though? [01:41] pipeline does when working with a pipeline [01:41] is pipeline good? i found it a bit confusing [01:41] some folk love it [01:41] 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] its quite polished at the use case it aims to solve (a series of feature branches tackling one large problem) [01:41] right now i have to do some complicated shelving [01:41] ah [01:41] hmm yes [01:41] maybe this is what i need, then [01:41] Stavros: what about just committing?: [01:42] i don't like committing half-working things :/ [01:42] work on feature 1, commit, switch to feature 2, work, commit, switch to feature 1, *uncommit*, keep working. [01:42] i don't trust me to remember to uncommit :/ [01:42] good solution if you're not ocd, though [01:43] a shelf per branch would be a good facility for core I think, perhaps file a bug ? [01:43] i will, thanks [01:43] i'll try pipeline in the mean time [01:44] shouldn't i post a feature request rather than a bug? [01:45] Stavros: there is no difference [01:46] ah, thanks, i'm filing one now [01:46] Stavros: bugs.launchpad.net/bzr [07:47] hi all ! [07:49] * fullermd waves at vila through the lightning. [07:49] :) [08:20] morning all [08:21] Moggûh, jelmer (though you're probably not up yet :) [08:21] morning vila [08:21] hey jam ! [08:22] so vila, what are you working on these days? Still poking at the package importer mostly? [08:23] I've been catching up with mails and reviews so far, I will focus on the p-i again now [08:27] jam: oh, and 2.3.1 should have been released last week so I need to catch up with that too [08:27] well, give it a sec, since I have a patch progressing through the stack :) [08:27] jam: did you merge your fix up to trunk for the missing inventories ? [08:27] hehe [08:27] I'm up to 2.3 [08:27] which is where you get NEWS conflicts because of the split-out [08:28] 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] 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] running ubuntu 10.04 [08:48] mr-russ: which doc are you reading ? bzr-smart.py doesn't appear to be part of the bzr sources [08:49] It's more or less part of the docs. [08:49] Last I checked. [08:49] yeah, that was my complaint really. http://doc.bazaar.canonical.com/bzr.dev/en/user-guide/http_smart_server.html [08:49] but there is no way to easily find the source from that page. [08:49] after 10-15 minutes googling, I think https://lists.ubuntu.com/archives/bazaar/2006q4/020376.html has the details I need. [08:50] mr-russ: But the source is in that page. [08:50] mr-russ: Copy and paste it. [08:50] thanks, excuse the dumb moment. [08:51] It's not ideal, of course. Maybe someone should stuff them all in contrib/ or somethuing. [08:52] yeah, it would be nice to have an example as part of the bzr doc when you apt-get. [08:53] I'm about to find out what I need to do to get modpywsgi installed. === Ursinha is now known as Ursinha-afk === hunger_ is now known as hunger [09:17] vila: on the plus side, it seems this was the only patch that needs merging-up [09:17] so you've kept the branches fairly in-sync [09:18] :) [09:20] modpywsgi seems difficult to find, links don't work. [09:21] mr-russ: http://code.google.com/p/modwsgi/ ? [09:21] mr-russ: :-/ patch welcome ! [09:21] if you can give updates to the docs, that would be great [09:21] what branch would I checkout? [09:22] for http://doc.bazaar.canonical.com/bzr.dev/ it should be the bzr trunk itself [09:23] so there is no python file, I need an apache module now? [09:23] 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] mr-russ: could very well be the case, that's why we generally encourage the use of bzr+ssh [09:24] okay. I was trying to keep away from having server accounts for each user. [09:25] shudder [09:25] yeah, that's the other missing bit... [09:25] what does lp use under the hood? [09:25] ssh :) [09:25] I understand the authentication issues I think [09:26] mr-russ: for lp you authenticate with one of your registered ssh keys [09:26] maybe I'll switch back to ssh. But is there a tute on restricting the ssh commands users can run? [09:26] LP doesn't use an ordinary sshd server, though. [09:26] mr-russ: as in restricting the ssh command to bzr ? [09:26] yes. [09:27] you can only use bzr over ssh, no account login at all. [09:27] oh, it's in ~/.ssh/authorized_keys IIRC [09:27] let me check [09:27] yes, with the funny commands out the front. [09:27] It's getting those commands right that is always painful. [09:27] indeed (searching for an example) [09:28] I think I may have gone that route first if I found a clear example. [09:28] I'm branching bzr now, so I'll see how I go with doc patches. [09:28] I've not used bzr with launchpad before, how does patch contribution work? [09:29] mr-russ: so, in the general case: branch; hack hack; commit; push lp:~// [09:30] mr-russ: 'bzr lp-open' will open the pushed branch page from where you can select: 'propose for merging' [09:30] cool. [09:30] I'm sure it's easy when I get the hang of it. [09:31] mr-russ: for bzr you will need to go thru http://www.canonical.com/contributors [09:33] Oh the joy of the legal world :) [09:33] 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] mr-russ: yeah :-/ There is a work in progress to satisfy more people but as often with legal it takes time [09:35] http://thias.marmotte.net/2009/05/creating-a-restricted-bzrssh-smart-server/ [09:35] does that look right for the bzrssh server setup? [09:37] mr-russ: looks highly plausible [09:37] 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] mr-russ: see also contrib/bzr_ssh_path_limiter in the bzr source tree [09:37] spiv: hey ! [09:37] Hey :) [09:38] I"m still waiting for my branch to finish downloading, not the greatest performance [09:38] I'll see if the lucid package installed contrib. [09:38] mr-russ: I don't think contrib is ever installed (apart from the bash completion stuff though...) [09:39] that's what I'm seeing on my server. waiting for branch to complete. [09:39] mr-russ: so you server is lucid, you know you can use the stable ppa to get newer releases right ? [09:40] 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] mr-russ: lucid provides bzr-2.1.1 while the ppa will gives you bzr-2.3.0 (and the associated plugins) [09:40] I usually upgrade with all LTS releases though. [09:41] the stable PPA will support LTS as well [09:41] but LTS does not support the PPA :) [09:42] the PPA content ? no :) [09:42] but *we* do :) [09:42] That is not what the average user will expect. [09:43] I will consider upgrading once I actually have this working neatly. [09:43] via SRUs we may be able to provides 2.1.4 for lucid, but we are not there yet [09:43] too many things that I and others are used to with SVN. [09:43] mr-russ: and what clients are you using ? [09:44] lucid. [09:44] all lucid at the moment. [09:44] command line bzr mostly. [09:45] 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] right, so, indeed, if you start using the PPA you'd better deploy it everywhere too, no urgency [09:45] AD ? [09:45] active dir [09:45] So I have a lot of learning todo before I can encourage them towards that stance. [09:45] sry [09:45] Active Directory. ldap windows. [09:46] right, so we don't support 2.1 on windows, only the most recent stable release (2.3) [09:46] this shouldn't be a problem [09:46] but if you'll get better performance with 2.3 [09:46] s/if// [09:47] mr-russ: no pressure, just presenting the options [09:47] okay, that will go with we use RedHat as a server and I'm sure it has and older version of bzr. [09:48] ah the joy of learning new stuff. [09:48] hehe [09:48] 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] Well, I've backed back to using bzr+ssh, much easier. No tricks with folder permissions when new branches are created? [09:49] mr-russ: no, as long as you use a single user on the server [09:49] 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] err [09:50] as long as the same user owns the branch and is used to ssh connect, no permissions tricks are needed [09:50] I've created a bzr group. added relevant users to it, and set all permissions to group rw(x). [09:51] 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] 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] vila: If I find anything or progress down that path, I'll report back. [09:51] mr-russ: right, but the ssh server filters the group permissions bits IIRC which is the source of all the problems [09:51] mr-russ: thx [09:52] 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] Or use a real OS with simpler FS semantics 8-} [09:52] oh. [09:53] fullermd: you mean... Windows ? [09:53] 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] 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] 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] 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] mr-russ: think of it as a user with different roles, each role is associated to a key [09:55] mr-russ: you give keys to users that can push to the server [09:55] mr-russ: and you define a single user on the server for this role [09:56] ssh account developer has (x) ssh keys that can run bzr. [09:56] on the server, yes [09:57] All developers on remote boxes use; bzr push bzr+ssh://user@my-bzr-server/path/to/bzr/branch/ [09:57] where user is the common user. Their ssh key is of course already setup properly. [09:57] with an appropriate ~/.ssh/config you can even use bzr push bzr+ssh://my-bzr-server/path/to/bzr/branch/ [09:58] I just wish I could short circuit the /path/to/bzr/branch to /branch. [09:58] I think I need to write a tutorial for this kind of setup. [09:58] bzr+ssh://my-bzr-server/~/project/branch/ [09:59] '~' will expand to the ssh user home directory on the server [09:59] the URL I sent before fixes taht. [09:59] as the command forces the folder for you. [09:59] http://thias.marmotte.net/2009/05/creating-a-restricted-bzrssh-smart-server/ [09:59] mr-russ: http://paste.ubuntu.com/577750/ is an excerpt of my ~/.ssh/config [10:00] I think I have found a winning configuration. Thanks all for your help. [10:00] mr-russ: good ! [10:01] 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] s/load/road/ [10:02] 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] mr-russ: sounds like it, that would be awesome ! [10:04] is it possible to create a shared / default branch.conf? [10:04] mr-russ: may be check in admin-guide too [10:04] catphish: what's your use case ? [10:04] eg. repo.conf or just plain bzr.conf [10:05] catphish: there is a work in progress to allow that [10:05] well i am setting up some hooks, and i want them to run on all branches in a particular repository [10:05] vila: can I send the contributor form to you, or to Mr Pool? [10:05] catphish: see configurations.txt in lp:~bzr-core/bzr/devnotes for an almost up-to-date description [10:06] mr-russ: poolie [10:06] mr-russ: err, yeah, Martin Pool [10:06] yes, I know poolie is Martin Pool :) [10:06] thanks vila, bazaar.conf will probably do, i was really hoping to do it per-repo [10:07] catphish: me too :) [10:07] 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] 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] now, i could use a single hook globally, however in every other SCM, hooks are defined per-repository [10:10] i can't define it per-branch easily because users can dynamically create branches within their repository [10:11] my hook currently reads the name of a shell script from the [hooks] configuration parameter and executes it [10:12] vila: I've sent the agreement, so that mean magic happens and my contributions will be considered for merging? [10:12] 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] mr-russ: yup, poolie should process it and from there we will land your contributions after reviewing them [10:13] thanks. [10:16] vila: what's the ppa address? [10:22] https://launchpad.net/~bzr/+archive/ppa [10:23] the various ppas are described at https://launchpad.net/bzr [10:23] and it's stable, even though it's labelled for developers? [10:25] okay, reading that page says it's stable releases. [10:26] mr-russ: oh, it's labeled for 'Bazaar Developers' because they are the maintainers not the targeted users [12:35] i am having problems with locking [12:35] bzr: ERROR: No such file: '/data/repos2/b5/70ff4d-c20f-d082-210b-d51b37b6bb92/default/.bzr/branch/lock/held' [12:36] a directory that quite clearly does exist [12:40] hi catphish [12:40] hi [12:40] catphish: when do you get that error, what are you trying to do? [12:43] jelmer: http://paste.codebasehq.com/pastes/xpt7u0ga7152 [12:43] catphish: is it perhaps a path that exists remotely? [12:44] it DOES exist remotely, see the ls [12:48] catphish: sorry, I missed that that was on the remote host [12:49] catphish: This is probably a bug in the smart server, can you file a bug report? [12:49] ideally i'd like to be able to confirm whether it's a bug in my http server first [12:50] catphish: It could be, but I think a bug in the bzr smart server is a lot more likely [12:51] jelmer: the error certainly implies an error in the smart server [12:51] the file it is complaining about clearly exists [12:51] jam: Goeiesmorgens! [12:51] where do i report it? [12:51] jelmer: when you sleep in, boy do you sleep in :) [12:52] jam: :) [12:52] catphish: it might be that the path is being sent across the wire and the bzr client tries to access it locally [12:53] good point [12:53] i'm using a sucky old client [12:53] will try upgrading first [12:53] 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] jelmer: dirstate can compute deltas quickly, and 2a can store deltas quickly [12:54] so rather than build the whole inventory [12:54] and save it [12:54] we build a delta and apply it [12:54] it was slower in pre-2a [12:54] and didn't handle merge commits for a while [12:54] I think that has been fixed [12:55] but I'm not positive [12:55] ah, thanks [12:56] I'm pretty sure record_iter_changes is the recommended path right now [12:57] 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] The last condition is the one you mentioned, I assume? [12:58] jelmer: i think i found my problem by looking closer at the protocol log [12:58] I'm not sure what is ANDed and what is ORed in that statement [12:58] but sure [12:59] I trust that you're looking at it more closely than I [12:59] we don't support it with nested trees, because it isn't well defined [12:59] so no work was actually done on it [12:59] filter_iter_changes() does actually handle kind == 'tree-reference' though, strangely enough [13:00] jelmer: that doesn't mean that all the other bits of the stack do [13:00] 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] jam: right [13:01] the branch name wasn't appended to the second parameter, the error it returns is misleading [13:01] 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] jelmer: well, if you want to implement --exclude handling for record_iter_changes, I'd be ok with that [13:02] catphish: Ah, I see [13:02] I think there was some discussion about how it should be done [13:02] that it should be passed into iter_changse [13:02] rather than filtered on top, etc. [13:03] i guess my code that injects branch names needs to be a little more intelligent [13:03] catphish: you're running a custom http server? [13:03] jelmer: yes [13:05] it just accepts http requests and passes them on to bzr serve --inet [13:06] unfortunately because my url structure contains a repo and a branch, it is necessary to inject the branch name into commands [13:06] right now i just have (ruby code): command[1] = branch + '/' + command[1] if branch [13:06] assuming the second parameter is always a path [13:09] 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] 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] i can just address them as i find them [13:42] looks like my original problem is fixed anyway :) [13:50] Hi guys, have I come to the right place for bzr-svn help? [13:50] probably [13:51] catphish Thanks [13:51] by the way, is this room affiliated with canonical and launchpad directly? [13:51] Basically, I'm getting weird things with bzr 2.4 dev and was wondering if anyone had seen it before? [13:51] $ bzr commit [13:51] Committing to: svn+https://SVN_REPO [13:51] modified FILES [13:51] bzr: ERROR: Layout CustomLayout([PATH_FROM_SVN_ROOT],[]) does not support custom branch paths. [13:52] Argh, stupid formatting [13:52] catphish: not per se, but many people haunt the same channels [13:52] Basically, If I checkout a svn repo, I get the error above [13:52] If I unbind it and push to it, there is no error [13:52] Does anyone know what I'm doing wrong? The svn layout is indeed a little strange [13:53] i wasn't really sure how closely bazaar was tied to canonical and to launchpad [13:54] but it's not really important [13:57] ChrisCauser: PATH_FROM_SVN_ROOT is not the path you have checked out? [13:58] 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] ChrisCauser: but "bzr commit" says "Committing to SVN_ROOT" ? [14:00] jelmer: No. It says "Committing to SVN_ROOT/PATH_FROM_SVN_ROOT" [14:02] ChrisCauser: hmm, that's odd. Do you perhaps have push_merged_revisions enabled? Does the branch have tags? [14:04] 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] ChrisCauser: Can you try that commit again with BZR_PDB=1 set and pastebin a backtrace? [14:08] catphish: bzr is a GNU project for which Canonical is the copyright holder [14:08] jelmer: Thanks for that. It has entered the debugger but the lines prior to that are at http://pastebin.com/3fX6dTQP [14:09] that's fine then, it was primarily the integration with launchpad that concerned me, seemed that a bit of a commercial injection [14:10] catphish: look harder :) 1) launchpad is free software, 2) the integration is done via a single plugin (bundled with bzr core though) [14:10] vila: that's cool, it hadn't occurred to me that LP was free / multihomed :) [14:11] i won't concern myself then [14:12] catphish: see https://launchpad.net/launchpad, licence: GNU Affero GPL v3 [14:12] i did :) [14:12] thanks [14:12] hehe [14:14] 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] Just Config? [14:20] catphish: bzrlib.config.GlobalConfig [14:21] ChrisCauser: can you run "bt" in the python debugger and pastebin the output? [14:22] jelmer: http://pastebin.com/Ak7e0m2N [14:24] jelmer: sorry to be dumb but how do actually use the GlobalConfig class to read a config option? [14:24] catphish: GlobalConfig().get_user_option('bar') IIRC [14:24] 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] jelmer: works like a charm, thanks [14:32] 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] ChrisCauser: yes, that's probably related. Was the branch you're working in currently based on the remote svn repo? [14:35] ChrisCauser: Is there a difference in any way between the local and the remote commits reported by "bzr missing" [14:35] ? [14:41] 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] 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] jelmer: There are no local commits as yet. This is a fresh checkout that I haven't changed. [14:46] 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] so it sends 2 lock requests, the first succeeds and the second one of course fails [14:47] i'm sure there's a reason, just can't see what it is :( [14:48] catphish: is there any reason for using a custom http server rather than e.g. just apache with wsgi? [14:48] yes [14:49] catphish: highly suspicious, there shouldn't be multiple lock requests coming from a bzr client [14:49] any gentoo packager around ? [14:49] ChrisCauser: can you spot any differences in the revisions present locally and remotely? [14:49] i'll get a full packet dump and see if i'm doing something to upset it [14:50] 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] vila: They filed some bugs earlier about several plugins not having a compatible release with 2.3 out yet [14:51] jelmer: ho ! thanks. Now that you mention it... [14:52] 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] ah, hmm.. time for my afternoon tea! [14:52] * jelmer runs off [14:52] ChrisCauser: including the path [14:53] ChrisCauser: even in the original branch? [14:53] jelmer: Hope you have a nice tea! I'm afraid there is no original bazaar branch as I suffered data loss. [14:54] ChrisCauser: I was just teasing vila since he was going to ask me about doing a bzr-svn release... [14:54] jelmer: haha [14:54] jelmer: Ooops. Sorry [14:54] jelmer: I haven't made the connection yet, but I plan to freeze 2.3.1 tomorrow, be ready ;-D [14:54] ChrisCauser: I mean, the original branch in which you tried to run "bzr commit" [14:58] 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] ChrisCauser: Hmm, ok === andreas__ is now known as ahasenack [14:58] I wonder why it's trying to commit to a non-mainline branch then [14:59] the change you're trying to commit, what sort of change is it? [14:59] 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] ChrisCauser: but it still did the checkout I presume (those are just warnings)? [15:00] jelmer: Yes, it still did the checkout [15:01] ChrisCauser: the change you're trying to commit, what sort of change is it? [15:02] jelmer: It happens on modifying, adding and removing [15:02] ChrisCauser: any merges involved? [15:02] No [15:06] ah, I see what's happening [15:06] ChrisCauser: this is a regression caused by bzr 2.4 [15:07] ChrisCauser: please file a bug [15:07] jelmer: Brilliant :) Will do. [15:07] jelmer: Is there any information that will help describe the situation? [15:08] ChrisCauser: bzr-svn doesn't implement Branch.import_last_revision_info_and_tags(), which was added recently [15:10] hmm, Branch.import_last_revision_info_and_tags doesn't make sense [15:12] ChrisCauser: can you try trunk? [15:12] of bzr-svn or bzr? [15:12] ChrisCauser: bzr-svn [15:18] 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] jelmer: Did I not supply enough flags to the setup script? [15:35] ChrisCauser: I've committed a fix, please try again === Ursinha-afk is now known as Ursinha [15:57] 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] catphish: it's been a very long time since we had reports about problems with keep-alive [16:07] catphish: you can use -Dhttp on your bzr client commands to get a debug output of all requests [16:07] catphish: the output should go to ~/.bzr.log IIRC [16:07] yeah, i tried that, the duplicates i'm seeing don't appear there [16:07] but i see them in a packet dump [16:07] so i'm a little confused at the moment [16:07] weird [16:07] do you have some proxy may be ? [16:08] will post some info if it persists [16:08] i do have a proxy, which was my first suspicion, but the duplicate requests are visible at the client too [16:08] catphish: if -Dhttp doesn't output the faulty request, bzr is out of the equation [16:08] err [16:09] what do you mean by 'visible at the client' ? [16:09] i mean, wireshark on my client shows 2 http requests to lock a repo [16:09] one at the end of a kept-alive http session [16:09] and another at the start of a new http connection [16:10] however i will confirm that and get some logs and evidence together to make sure i'm not being stupid [16:10] i have no doubt it's the result of one of my proxies, but i need to establish exactly why [16:16]