[00:00] Version: 1.1~rc1-1 [00:00] Python-Version: 2.4, 2.5 [00:00] Version: 0.11-1.1 [00:00] Python-Version: >= 2.4 [00:00] just do apt-get install bzr [00:00] that'll get you the latest and greatest bzr [00:00] Gotcha. that will use the correct python right? [00:00] well, yes [00:00] but your _path_ will still use /usr/local/bin/bzr [00:00] so I'd get rid of that [00:01] just delete it [00:01] will do [00:01] you might want to kill your /usr/local/bin/python* too [00:03] That sounds risky [00:04] did you specifically want a non-Debian python installed, or were you just trying to get bzr working? [00:04] That old python was installed on the system by a previous BOFH [00:04] ah [00:04] oh. well in that case just leave it [00:04] but know that whenever you just run python, it's going to pick that one up first [00:05] which is almost never going to be what you want [00:05] so you might want to alter your path to not use /usr/local or something [00:05] or just be explicit [00:05] and it will probably break other Debian python software [00:06] jesus chr*st [00:06] (e.g. anything else that uses the "bz2" module :) [00:11] rolly: I'd also send a death gram to the previous BOFH :) [00:12] hehe, it's horrible. It's like he encrusted python into this system [00:12] I just replaced /usr/local/bin/python with a symbolic link to the right one, and I'll start keeping a tally of broken python programs :p [00:14] hooray, svn2bzr works now [00:14] YAY [00:14] \o/ [00:16] So yesterday I asked a question about creating non-propagating revisions, but I framed it poorly. Now I found a diagram that explains exactly what I'd like to do in bzr ---> http://merge-tracking.open.collab.net/servlets/ProjectProcess?documentContainer=c2__Sample%20repository [00:16] see operation 'b' in that diagram? "Marking r7@branches/a to be blocked. From this point on forward, this change set shall not propagate anywhere." [00:16] Can that be done in bzr? [00:22] I'd like a "telepathy" option to 'bzr blame'.. It's good at telling me what change I made six months ago, but unfortunately it fails to explain the logic of my reasoning on why I thought it was a good idea [00:23] hah :) [00:24] I wrote about the fact that two methods have to be called in a particular order, only I can't now see why... they look independent... [00:26] poolie, lifeless, I'm working on the automatic plugin suggestion bit, and I have a conceptual question I can't seem to resolve on my own [00:28] (basically, ping :p) [00:29] When using bzr-svn, how do I authenticate when pushing to an https:// URL (Sourceforge, in this case)? [00:30] Odd_Bloke: See the bzr-svn FAQ [00:33] jelmer: Oh yeah. I scanned the page but somehow managed to completely miss that entry. /o\ [00:33] jelmer: Thanks. :) [00:39] are hooks executed on the server side when i do a push using ssh+bzr? [00:39] man jetlag kills [00:41] poolie: want a call ? [00:41] beuno: pong [00:43] lifeless, I'm going to have an XML file with all available plugins bundled with bzr so users don't need internet connection to use the command-not-found bit. What I'm not really sure is where to locate it within the bzr directory structure so it's accesible even if you run bzr from source [00:44] beuno: I don't understand why you need that file [00:44] beuno: we know what commands the user /has/ [00:44] beuno: everything else is unknown. [00:45] cliechti: afaik they're all client side at this point [00:46] lifeless, not for the new spec. You wouldn't know what commands uninstalled plugins provide, so I'm going bundle an XML file with that information (which will be available to update later on on user request) [00:46] beuno: in my head there are three states for a command: found locally, not found locally, not found locally and found in a directory service [00:46] beuno: I don't like the idea of a static file in bzr itself; it _will_ bitrot. [00:47] jelmer: yeah it looked like that. the push+update plugin also does a separate ssh connection. and a rss generator plugin sneaks in the rss file into the .bzr folder of the server, but no code execution there [00:47] lifeless, so how do you suggest I handle this? Make bzr download an updated XML file the first time the user hits a not-found command? doesn't seem sensible to me :D [00:48] ET software? that phones home? ;-) [00:48] I would like to ship with bzr a list of official plugins that can be suggested [00:48] so I believe this would be a new state for a command [00:50] beuno: Couldn't this rather be in a separate plugin, just like is done for the bash/zsh scripts? [00:51] beuno: E.g. just make core bzr provide a "Command not found" hook [00:51] jelmer, yes and no. It can if it's not going to be part of the core. If these bits _are_ going to be in the core, then I have to have a DB already available [00:52] as lifeless suggests in: https://lists.ubuntu.com/archives/bazaar/2008q1/037066.html [00:52] a big part will be in the core [00:54] jelmer: I think the core mechanism of this should in the core, so that it gets loved as much as possible [00:54] beuno: I'm entirely happy with having the directory services be plugins [00:55] lifeless: I have no problem with the add-plugin, list-plugins, etc commands as part of core [00:55] beuno: in fact, perhaps the plugin for installing plugins in a particular manner also is the directory service for that manner [00:56] beuno: e.g. you want to write a 'checkout to install' style plugin - cool. That plugin can use a xml file if you want. [00:56] lifeless: however, I would really like to see the plugin that provides access to the "trusted repository" as a plugin (no objection if it's shippedinthe standard tarball) [00:56] I want to write/see a plugin that installs from debs [00:56] ^^++ [00:56] so it needs at minimum a mapping from plugin name to deb [00:57] and adding a mapping of command to plugin at the same spot seems reasonable at first glance [00:57] jelmer: I agree thats what I am saying - the mechanism to install things should be plugins, the UI and core logic should not [00:57] lifeless: Ok, then we're on the same line. [00:58] Thanks :-) [00:58] * beuno thinks [00:58] I see a plugin for finding and installing to ~/.bazaar/plugins/, a plugin for installing via debs, a plugin for installing via easy_install, a plugin for installing via rpm's, and one for whatever gentoo call their packages [00:59] beuno: the directory service is a dynamic thing [00:59] beuno: in fact, one interesting case is 'command not found' -> 'new bzr supplies it' [00:59] lifeless, ah, yes, that's interesting to provide too [01:00] which would require bzr to download on some sort of regular basis the updated DB [01:01] I'm a bit confused on having the code for checking if a plugin is available for a command in the core, but having the actualy db as a plugin [01:01] although it does make sense in some level [01:01] I was thinking of shipping a db file with bzr, and then just update to the users ~/.bazaar dir [01:01] make the plugin first check in the ~/.bazaar dir, and if not, fall back into the a default location [01:02] one think going around in my head was to serialize the db to a file so it can be accesed faster than parsing XML each time [01:03] s/think/thing [01:04] lifeless: I wonder if we could do that with tracebacks.. [01:04] lifeless: "The bug you just hit has been fixed in a newer version of bzr" [01:05] beuno: in the core it will be something like: for provider in providers: try: plugin_name = provider.command_name_to_plugin_name(); except LookupError: continue; raise InstallableCommand(provider, plugin_name) [01:05] jelmer: cute [01:06] beuno: I would expect the debian packaging to make sure that only the install_via_deb provider is present [01:08] lifeless, so the db of plugins will be provided by each provider (with checkout plugin installed by default in bzr) [01:08] approximately [01:08] we'll also want branch/repo/tree formats to be supplied [01:08] and others [01:08] eventually [01:09] wouldn't it be nice if rather than 'unknown format ... needs 1.4' you got 'unknown format ... needs 1.4' Lookup support for this [Y/n] [01:09] heh, yes [01:09] hit Y, and get 'upgrade bzr to the current release 1.6 which supports this' [01:10] but lets stay focused [01:10] missing commands [01:10] I suddenly have 100x times more things in my head than before (which wasn't little) [01:10] ok [01:10] well, I just have one concern [01:10] which is more of short-term problem [01:10] I'd like to implement this in stages [01:10] "This bug has been fixed in a newer version of $software, so go upgrade already" would be awesome :) [01:11] first stage would just tell the user the command is available in a plugin, and the URL where it's located [01:11] beuno: I think thats a second or third stage [01:11] second stage, installing it with the checkout plugin [01:11] lifeless, ok. What's the first stage then?? [01:12] beuno: first stage is to my mind the bzrlib core being done, with no providers present [01:12] lifeless, so it would check for providers, and not find any (useless to the actual users) [01:12] beuno: which means UI and appropriate lookup facilities, the add-plugin or whatever its called command being present, remove-plugin likewise [01:13] beuno: this is important as it is a likely common corner case (some folk will not want this facility) [01:13] then second stage is write a plugin which can identity other plugins [01:14] it can on add-plugin 'foo' print out 'the home page for foo is XXX, please follow the README/INSTALL instructions there' [01:14] and you can refine the plugin further from there [01:14] but at the same time jelmer/james/dato can be writing a deb based version of the same thing [01:15] my point is that bzr itself probably never needs to know 'the url homepage' or anything like that [01:15] all be needs to know is 'plugin X is supplied by provider Y for the problem of 'missing command Z'' [01:17] lifeless, so each provider will have it's own db of available plugins? [01:18] if I "python setup.py install" the newest version of bzr-svn, do I have to go and manually remove the old egg or will bzr find and use the newest one? [01:19] beuno: surely that has to be the arrangement, not all plugins are available to .debs at the moment, and someone may package an older/newer version of a plugin with different commands than the one in e.g. rpms [01:19] SmileyChris: I really don't understand eggs, they seem to do very strange things. [01:20] SmileyChris: its why I don't use them, and just put plugins in ~/.bazaar/plugins - e.g. ~/.bazaar/plugins/svn [01:21] lifeless, ok. And we would ship the checkout (native) plugin by default, so we would already have a DB available. And, when another provider is installed as a plugin, it should somehow specify "check me first", so we can fall back to checkouts if it's not provided as a .deb (which is very likely to happen often) [01:21] if that's the case, my only concern would be how each plugin would keep it's DB updated [01:23] beuno: thats up to the plugin surely [01:23] the easiest way to make tricky decisions is to get someone else to make them [01:24] lifeless, ok, you got me :p [01:24] alright, that works for me [01:24] (I'm not entirely sure we would ship any plugin by default). But we certainly could have a 'bundle' release for non-distro users that adds e.g. bzrtools and checkout-plugin and whatnot [01:24] I can have all the core bits in there [01:24] (any plugin that does this I mean) [01:25] lifeless, if we don't ship the plugin by default, most users will miss out on the command-not-found bit [01:25] ("most users" is a wild un-educated guess) [01:26] I'm thinking what gets shipped in the standard bzr tarball [01:27] which is what propagates to the distros and all those weird places [01:27] so all the code will be in place, but no db of known plugins will be available [01:41] lifeless, I'm off to get some dinner, but I'll be back in a short while to keep on working on this [01:55] New bug: #187916 in bzr "bzr crashed on 'bzr branch'" [Undecided,New] https://launchpad.net/bugs/187916 [01:56] beuno: yet, on a debian system you don't want user-installed plugins, you want deb installed plugins with dependencies [01:58] lifeless, though, that might be strange if bzr itself was installed from source [01:59] i would say it should match the method used for the current bzr process [01:59] probably [02:09] I have to say I'm a bit dismayed by the whole idea. [02:10] Haven't we got enough package tools already? [02:10] well, i think just suggesting the right thing would be a good start [02:11] Yeah, that seems okay. [02:12] Actually installing the plugins via various package systems seems like it could cause a lot of confusion. [02:13] Especially if platforms like Ubuntu support 3 install methods. [02:14] And while I love using apt or synaptic, there are tons of plugins that aren't packaged. [02:15] right [02:15] ideally, we'd automatically package all of them, but that would take some time [02:51] back [02:53] lifeless, I'm thinking most plugins don't/won't have dependencies, so the per-distro installing will be more of an exception than a rule [02:53] I'd actually prefer to focus this as a feature of the core, recommending plugins by default in any type of installation, with checkouts being the default way of installing them [02:54] and have the per-distro installations be a "maybe in the future someway" sort of thing [02:54] this way we guarantee it works in all platforms [02:54] and we have control over the end-result [02:56] making optional plugins necessary to make all this work will end up missing most of the targeted users: the ones that don't want to install them manually [02:56] poolie: And then there's my hax plugin, which isn't even spelled right ... ;-) [02:56] and also depend heavily on per-distro setups [02:59] so, I need to solve this before I continue hacking on it. How/where/when to place the available plugins DB [03:05] New bug: #162368 in bzr-svn "bzr branch fails with foreign filenames" [Medium,Fix committed] https://launchpad.net/bugs/162368 [03:06] New bug: #174947 in bzr-svn "Commands for changing/viewing file properties" [Wishlist,Fix released] https://launchpad.net/bugs/174947 [03:10] * beuno goes on and works on it as a plugin with minimal code in the core, and prepares himself for future refactoring [03:16] New bug: #181790 in bzr-svn "NoSuchId traceback when branching a svn repository" [Medium,Fix released] https://launchpad.net/bugs/181790 [03:16] New bug: #183853 in bzr-svn "bzr status crash w/ svn checkout" [Medium,Fix committed] https://launchpad.net/bugs/183853 [03:16] bzr is a delight to work with, after months of fighting svk [03:25] New bug: #183361 in bzr-svn "bzr-svn on a branches not working" [Medium,Triaged] https://launchpad.net/bugs/183361 [03:28] argh, jaj for mass bug changes in the middle of the night [03:28] I just accidently changed 10 bzr-svn bugs to be against bzr [03:28] sorry [03:39] jelmer: you know you can just change the product back [03:39] jelmer: you don't have to mark it as invalid in bzr [03:59] lifeless: what's the command for that? [03:59] lifeless: I added a product by accident [04:00] oh [04:00] lifeless: in this case [04:00] I'm not aware of a 'remove this reference' thing; there should be though :) [04:00] BjornT: ^ [04:01] I usually just mark as invalid [04:01] which is basically noise ;) [04:01] yeah [04:01] I mean, its equally invalid on all products:) [04:01] that memory bug in python-subversion was at some point reported to exist in 10 products [04:02] beginner seeking help [04:02] hi keithy_ [04:02] I started a local repo using cd dev; bzr init [04:02] I'm just cooking lunch, but ask the questions and someone will answer you sortly :) [04:03] then on a remove mc I try [04:03] then on a remote mc I try bzr checkout --lightweight ssh://keith@squeak.warwick.st/dev [04:04] igc: is there some way with usertest to benchmark different bzr storage formats? [04:04] and I get "not a branch" [04:04] keithy_: try bzr+ssh rather than ssh [04:04] ? [04:04] bzr+ssh://keith@squeak.warwick.st/dev [04:04] as a url [04:05] oh oops I did [04:05] then on a remote mc I try bzr checkout --lightweight sftp://keith@squeak.warwick.st/dev [04:05] keithy_: and /dev is actually a repository on that host?? [04:05] its my working dir [04:05] jelmer: yes ... [04:05] and I did bzr init in it [04:06] jelmer: let me think how best to do that [04:06] keithy_: You have to specify the path to your homedir as well [04:07] igc: we were benchmarking packs vs knits in the past [04:07] which home dir? [04:07] igc: that approach worked well [04:07] keithy_: the path after the hostname is an absolute path [04:07] yes [04:07] lifeless: yes, though that was 2 different branches [04:07] keithy_: e.g. sftp://keith@squid.warwick.st/home/keith/dev ? [04:07] ah [04:07] keithy_: you are versioning the special files in /dev ? [04:08] igc: so create two branches of .dev? :) [04:08] jelmer: I'd add a user parameter holding options to init-repo in InitialImportTask [04:08] why an absolute path? [04:08] keithy_: so that you can refer to e.g. /srv/ and /var - where people often have repositories [04:08] ic [04:08] keithy_: on sftp you can use /~/ to get into your home dir, that is not implemented for bzr+ssh yes. [04:08] s/yes/yet/ [04:08] igc: ah, ok [04:09] I'll give that a try some time, thanks! [04:09] then I'd pass in the file format using the --config-file options [04:09] * jelmer is interested in testing the performance of various bzr-svn versions [04:09] jelmer: that's how I test various networking protocols [04:09] and it works well [04:11] great its working [04:12] ok next question [04:12] I have a directory of files [04:12] and I want a commit to always include all of the files in that directory [04:13] without having to manually add them, they may change frequently [04:13] jelmer: my wrapper script for testing networking scenarios - http://rafb.net/p/prTgqd10.html [04:14] keithy_: we don't have a facility for that yet; we have an open bug to have a --automatic flag to commit to automatically add and delete files [04:14] a flag on commit will not doit [04:15] I want to version the files of an oodb [04:15] but they change [04:15] keithy_: well with that flag you could add an alias of commit to commit --automatic ;) [04:15] I dont want to automatic everything [04:15] just that one dir [04:15] ok [04:15] well its doable via a plugin but there is no canned feature for this [04:16] I thought that bzr add blah/ [04:16] should do it [04:16] bzr add blah/ adds the current content [04:16] it does not trigger an automatic add on every operations [04:16] as I found out [04:16] k next question [04:16] having checkedout whats the easiest way to push changes back [04:17] well checkouts work like svn/cvs [04:17] so when you commit they are recorded in the place you checked out [04:17] you need to push and pull when you've made a new branch (using bzr branch) [04:17] ah so the master is the origina [04:17] I dont understand branch yet [04:18] so... [04:18] I have dev as the repo on one mc [04:18] and I check out to a second [04:18] you're in the squeak world obviously :) [04:18] perhaps an analogu will help [04:18] then any commits on the second are sent to the dev mc [04:19] I develop in squeak, and version my images in bzr [04:19] a squeak image is a bit like a branch: you can change it (by journalling your actions) [04:19] then I use the checkout to deploy to the webserver [04:19] you can take a copy of it to get an identical image [04:19] and that can then change further; or you can take your journalled actions from your first image and apply them to the second to end up with an updated and now identical image [04:20] so if you are using a checkout to deploy, your deploy process will be to run 'bzr update' [04:20] on the server [04:20] yes [04:20] because you need the working files update [04:20] *updated* [04:21] and if I fix a bug on the server and want to send the result back upstream [04:21] thats a straight commit? [04:21] beuno: Still around? [04:21] well, by using a checkout you don't really have upstream/downstream - so yes, just commit [04:21] wow thats great [04:21] better than mercurial [04:21] -) [04:21] :-) [04:22] you can work the same as you would in mercurial, in fully distributed mode. But we found that there are things where distributed does /not/ make sense. [04:22] a leightweight remote working dir [04:22] so we made it a choice for the user [04:23] right so I can scrap using unison as well [04:23] cool! [04:27] abentley, yeap [04:27] silly question: there's no authentication possible with the smart server, right? [04:28] playing around with registrys [04:28] rolly: the smart server itself does not do authentication [04:28] rolly: we let apache or ssh do that [04:31] beuno: My best theory is that this branch was recently upgraded to packs, but never reconciled. [04:31] abentley: errors on push/pull ? [04:31] Yes. [04:31] sftp/smart server/local ? [04:31] lifeless: gotcha, but how do I NOT serve via HTTP? [04:31] rolly: sorry I don't understand your question [04:32] abentley, ah, yes, was my guess too. No way of fixing it though, right? [04:32] beuno: sftp/smart server/local ? [04:32] I would like my smart server to be accessible via ssh, but not via http [04:32] rolly: so just don't make the directory visible over http :) [04:33] Oh, I'm not using apache [04:33] rolly: or don't configure up the smart server on http. it takes explicit actions to make it visible over http [04:33] beuno: Do you have write access to it? [04:33] But "bzr serve" starts a listening port [04:33] abentley, no, I don't. synic, still around? [04:34] rolly: yes, thats on the bzr:// port though. If you want it working over ssh you don't have to do anything special at all [04:34] rolly: just install bzr on the server and you're done [04:34] lifeless, pushed to launchpad. It really doesn't have much to do with me as I'm just trying to help out someone. Don't really know how/what went on. [04:34] Anyhow, you can run bzr reconcile on it now. [04:35] Or synic can, or whatever. [04:35] beuno: they should bzr reconcile it remotely [04:35] after I did my checkout, can I rename the directory? [04:35] keithy_: sure [04:35] and I could move it? [04:35] lifeless: argh, sorry. All that I was saying about http://, I meant bzr://. I would like to restrict access via bzr:// and only allow bzr+ssh://. Sorry [04:35] keithy_: yup [04:35] The http version actually a copy, and in this case, it's a failed copy. [04:35] great! [04:35] rolly: thats trivial; don't run bzr serve :) [04:36] Oh... duh :D [04:36] rolly: you have to do stuff to make bzr:// work - by default it doesn't run anywhere :) [04:36] Had a mental roadblock there, thanks [04:36] yeah :p [04:36] np [04:36] I don't think we explicitly say anywhere that we don't dopen stuff etc [04:37] beuno: they should also upgrade the branch; its at branch5, not branch6 [04:37] beuno: I suggest they do 'bzr upgrade sftp://b.l.n/~....' and 'zr reconcile sftp://b.l.n/~/ [04:38] lifeless, they did reconcile [04:38] didn't fix it [04:38] abentley, aaah, ok ok, it's been tweaked then [04:39] well, synic, ^ [04:40] so hang on a second [04:40] its in pack on the public mirror of lp [04:40] this means a pull from the master repo worked [04:40] using bzr 1.0 as thats what lp is running [04:41] lifeless, it didn't work before. abentley, did you fix anything? [04:42] beuno: No, I don't have those kind of super cow powers. [04:42] bzr branch http://bazaar.launchpad.net/~exaile-devel/exaile/main [04:42] Branched 0 revision(s). [04:42] ah, so it's still borken [04:42] lifeless, they did run reconcile on it [04:42] and it didn't fix it [04:42] lifeless: Exactly. [04:43] its got no revision history [04:43] The http version doesn't. [04:43] I think the quarrantine version probably does. [04:43] abentley: true; hmm, does lp create the branch and then pull; if so blech [04:43] * beuno has to go [04:43] beuno: get them to talk to us [04:43] lifeless, ok, synic is the man [04:43] beuno: if they ran reconcile locally it won't fix the remote one [04:43] synic: ping [04:44] lifeless, he did run it remotely [04:44] beuno: so we need to be really quite sure of whats going on [04:44] beuno: also, there should be an error in the lp web page if it was faulting [04:44] lifeless: it was remotely [04:44] lifeless: does reconcile work over bzr+ssh? [04:44] lifeless, agreed. synic, lifeless is your man [04:44] k [04:44] abentley: it should I think, but for surety I'd try sftp [04:45] synic: can I talk you though some python ? [04:45] yeah - I'm running reconcile remotely again... should I stop it? [04:45] * abentley has no idea how the branch puller works. [04:45] synic: nah, let it finish [04:45] alright. [04:45] synic: we can do this in another window [04:45] ok, I've got one open [04:46] thumper: ping; errors on code.* branches - does everyone see them? (please say yes) [04:46] $ python [04:46] >>> from bzrlib.branch import Branch [04:46] >>> b = Branch.open('sftp:// >>> b.lock_read() [04:47] >>> print b._format [04:47] paste the output of the last line [04:47] Bazaar-NG branch format 5 [04:47] lifeless: what's up? [04:47] >>> b.last_revision() [04:47] sasongko@gmail.com-20080129204555-7h0j46m8wwlpcff2 [04:47] thumper: https://code.edge.launchpad.net/~exaile-devel/exaile/main shows no error in mirroring, but the mirrored branch has no revision history [04:48] lifeless: Essentially yes, it does a branch followed by a pull. [04:48] lifeless: right, this is the branch I talked to abentley about this morning [04:48] bzr info on the remote branch raises an error [04:48] thumper: so I'm asking if the reason we don't see errors could be UI madness rather than 'no error occuring' [04:48] lifeless: I confirm ui madness [04:49] will fix on edge soonish [04:49] Who's saying we don't see errors? I posted an OOPS to you! [04:49] abentley: the UI is not showing the error text [04:49] True. [04:49] that madness [04:49] abentley: yes the errors are available for developers; but folk like beuno that want to help don't have access there [04:50] abentley: so we should allow the community to share their expertese [04:50] synic: ok, thats good. [04:50] synic: whats the exact reconcile command you ran ? [04:50] bzr reconcile bzr+ssh://arolsen@bazaar.launchpad.net/~exaile-devel/exaile/main/ [04:50] synic: ok [04:50] it's still running [04:50] synic: back in python [04:50] >>> from bzrlib.repository import Repository [04:51] >>> r = Repository.open('bzr+ssh://arolsen@bazaar.launchpad.net/~exaile-devel/exaile/main/') [04:51] >>> r.lock_read() [04:51]