#bzr 2008-02-01 <rolly> Version: 1.1~rc1-1 <rolly> Python-Version: 2.4, 2.5 <rolly> Version: 0.11-1.1 <rolly> Python-Version: >= 2.4 <mtaylor> just do apt-get install bzr <mtaylor> that'll get you the latest and greatest bzr <rolly> Gotcha. that will use the correct python right? <mtaylor> well, yes <mtaylor> but your _path_ will still use /usr/local/bin/bzr <mtaylor> so I'd get rid of that <mtaylor> just delete it <rolly> will do <mtaylor> you might want to kill your /usr/local/bin/python* too <rolly> That sounds risky <bob2> did you specifically want a non-Debian python installed, or were you just trying to get bzr working? <rolly> That old python was installed on the system by a previous BOFH <bob2> ah <mtaylor> oh. well in that case just leave it <mtaylor> but know that whenever you just run python, it's going to pick that one up first <mtaylor> which is almost never going to be what you want <mtaylor> so you might want to alter your path to not use /usr/local or something <mtaylor> or just be explicit <bob2> and it will probably break other Debian python software <rolly> jesus chr*st <bob2> (e.g. anything else that uses the "bz2" module :) <mtaylor> rolly: I'd also send a death gram to the previous BOFH :) <rolly> hehe, it's horrible. It's like he encrusted python into this system <rolly> 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 <rolly> hooray, svn2bzr works now <mtaylor> YAY <rolly> \o/ <rolly> 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 <rolly> 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." <rolly> Can that be done in bzr? <LeoNerd> 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 <rolly> hah :) <LeoNerd> 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... <beuno> 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 <beuno> (basically, ping :p) <Odd_Bloke> When using bzr-svn, how do I authenticate when pushing to an https:// URL (Sourceforge, in this case)? <jelmer> Odd_Bloke: See the bzr-svn FAQ <Odd_Bloke> jelmer: Oh yeah. I scanned the page but somehow managed to completely miss that entry. /o\ <Odd_Bloke> jelmer: Thanks. :) <cliechti> are hooks executed on the server side when i do a push using ssh+bzr? <lifeless> man jetlag kills <lifeless> poolie: want a call ? <lifeless> beuno: pong <beuno> 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 <lifeless> beuno: I don't understand why you need that file <lifeless> beuno: we know what commands the user /has/ <lifeless> beuno: everything else is unknown. <jelmer> cliechti: afaik they're all client side at this point <beuno> 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) <lifeless> 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 <lifeless> beuno: I don't like the idea of a static file in bzr itself; it _will_ bitrot. <cliechti> 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 <beuno> 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 <cliechti> ET software? that phones home? ;-) <beuno> I would like to ship with bzr a list of official plugins that can be suggested <beuno> so I believe this would be a new state for a command <jelmer> beuno: Couldn't this rather be in a separate plugin, just like is done for the bash/zsh scripts? <jelmer> beuno: E.g. just make core bzr provide a "Command not found" hook <beuno> 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 <beuno> as lifeless suggests in: https://lists.ubuntu.com/archives/bazaar/2008q1/037066.html <beuno> a big part will be in the core <lifeless> jelmer: I think the core mechanism of this should in the core, so that it gets loved as much as possible <lifeless> beuno: I'm entirely happy with having the directory services be plugins <jelmer> lifeless: I have no problem with the add-plugin, list-plugins, etc commands as part of core <lifeless> beuno: in fact, perhaps the plugin for installing plugins in a particular manner also is the directory service for that manner <lifeless> beuno: e.g. you want to write a 'checkout to install' style plugin - cool. That plugin can use a xml file if you want. <jelmer> 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) <lifeless> I want to write/see a plugin that installs from debs <mtaylor> ^^++ <lifeless> so it needs at minimum a mapping from plugin name to deb <lifeless> and adding a mapping of command to plugin at the same spot seems reasonable at first glance <lifeless> jelmer: I agree thats what I am saying - the mechanism to install things should be plugins, the UI and core logic should not <jelmer> lifeless: Ok, then we're on the same line. <jelmer> Thanks :-) * beuno thinks <lifeless> 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 <lifeless> beuno: the directory service is a dynamic thing <lifeless> beuno: in fact, one interesting case is 'command not found' -> 'new bzr supplies it' <beuno> lifeless, ah, yes, that's interesting to provide too <beuno> which would require bzr to download on some sort of regular basis the updated DB <beuno> 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 <beuno> although it does make sense in some level <beuno> I was thinking of shipping a db file with bzr, and then just update to the users ~/.bazaar dir <beuno> make the plugin first check in the ~/.bazaar dir, and if not, fall back into the a default location <beuno> 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 <beuno> s/think/thing <jelmer> lifeless: I wonder if we could do that with tracebacks.. <jelmer> lifeless: "The bug you just hit has been fixed in a newer version of bzr" <lifeless> 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) <lifeless> jelmer: cute <lifeless> beuno: I would expect the debian packaging to make sure that only the install_via_deb provider is present <beuno> lifeless, so the db of plugins will be provided by each provider (with checkout plugin installed by default in bzr) <lifeless> approximately <lifeless> we'll also want branch/repo/tree formats to be supplied <lifeless> and others <lifeless> eventually <lifeless> 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] <beuno> heh, yes <lifeless> hit Y, and get 'upgrade bzr to the current release 1.6 which supports this' <lifeless> but lets stay focused <lifeless> missing commands <beuno> I suddenly have 100x times more things in my head than before (which wasn't little) <beuno> ok <beuno> well, I just have one concern <beuno> which is more of short-term problem <beuno> I'd like to implement this in stages <AfC> "This bug has been fixed in a newer version of $software, so go upgrade already" would be awesome :) <beuno> first stage would just tell the user the command is available in a plugin, and the URL where it's located <lifeless> beuno: I think thats a second or third stage <beuno> second stage, installing it with the checkout plugin <beuno> lifeless, ok. What's the first stage then?? <lifeless> beuno: first stage is to my mind the bzrlib core being done, with no providers present <beuno> lifeless, so it would check for providers, and not find any (useless to the actual users) <lifeless> beuno: which means UI and appropriate lookup facilities, the add-plugin or whatever its called command being present, remove-plugin likewise <lifeless> beuno: this is important as it is a likely common corner case (some folk will not want this facility) <lifeless> then second stage is write a plugin which can identity other plugins <lifeless> it can on add-plugin 'foo' print out 'the home page for foo is XXX, please follow the README/INSTALL instructions there' <lifeless> and you can refine the plugin further from there <lifeless> but at the same time jelmer/james/dato can be writing a deb based version of the same thing <lifeless> my point is that bzr itself probably never needs to know 'the url homepage' or anything like that <lifeless> all be needs to know is 'plugin X is supplied by provider Y for the problem of 'missing command Z'' <beuno> lifeless, so each provider will have it's own db of available plugins? <SmileyChris> 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? <lifeless> 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 <lifeless> SmileyChris: I really don't understand eggs, they seem to do very strange things. <lifeless> SmileyChris: its why I don't use them, and just put plugins in ~/.bazaar/plugins - e.g. ~/.bazaar/plugins/svn <beuno> 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) <beuno> if that's the case, my only concern would be how each plugin would keep it's DB updated <lifeless> beuno: thats up to the plugin surely <lifeless> the easiest way to make tricky decisions is to get someone else to make them <beuno> lifeless, ok, you got me :p <beuno> alright, that works for me <lifeless> (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 <beuno> I can have all the core bits in there <lifeless> (any plugin that does this I mean) <beuno> lifeless, if we don't ship the plugin by default, most users will miss out on the command-not-found bit <beuno> ("most users" is a wild un-educated guess) <beuno> I'm thinking what gets shipped in the standard bzr tarball <beuno> which is what propagates to the distros and all those weird places <beuno> so all the code will be in place, but no db of known plugins will be available <beuno> lifeless, I'm off to get some dinner, but I'll be back in a short while to keep on working on this <ubotu> New bug: #187916 in bzr "bzr crashed on 'bzr branch'" [Undecided,New] https://launchpad.net/bugs/187916 <lifeless> beuno: yet, on a debian system you don't want user-installed plugins, you want deb installed plugins with dependencies <poolie> lifeless, though, that might be strange if bzr itself was installed from source <poolie> i would say it should match the method used for the current bzr process <poolie> probably <abentley> I have to say I'm a bit dismayed by the whole idea. <abentley> Haven't we got enough package tools already? <poolie> well, i think just suggesting the right thing would be a good start <abentley> Yeah, that seems okay. <abentley> Actually installing the plugins via various package systems seems like it could cause a lot of confusion. <abentley> Especially if platforms like Ubuntu support 3 install methods. <abentley> And while I love using apt or synaptic, there are tons of plugins that aren't packaged. <poolie> right <poolie> ideally, we'd automatically package all of them, but that would take some time <beuno> back <beuno> 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 <beuno> 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 <beuno> and have the per-distro installations be a "maybe in the future someway" sort of thing <beuno> this way we guarantee it works in all platforms <beuno> and we have control over the end-result <beuno> 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 <abentley> poolie: And then there's my hax plugin, which isn't even spelled right ... ;-) <beuno> and also depend heavily on per-distro setups <beuno> so, I need to solve this before I continue hacking on it. How/where/when to place the available plugins DB <ubotu> New bug: #162368 in bzr-svn "bzr branch fails with foreign filenames" [Medium,Fix committed] https://launchpad.net/bugs/162368 <ubotu> New bug: #174947 in bzr-svn "Commands for changing/viewing file properties" [Wishlist,Fix released] https://launchpad.net/bugs/174947 * beuno goes on and works on it as a plugin with minimal code in the core, and prepares himself for future refactoring <ubotu> New bug: #181790 in bzr-svn "NoSuchId traceback when branching a svn repository" [Medium,Fix released] https://launchpad.net/bugs/181790 <ubotu> New bug: #183853 in bzr-svn "bzr status crash w/ svn checkout" [Medium,Fix committed] https://launchpad.net/bugs/183853 <rolly> bzr is a delight to work with, after months of fighting svk <ubotu> New bug: #183361 in bzr-svn "bzr-svn on a branches not working" [Medium,Triaged] https://launchpad.net/bugs/183361 <jelmer> argh, jaj for mass bug changes in the middle of the night <jelmer> I just accidently changed 10 bzr-svn bugs to be against bzr <jelmer> sorry <lifeless> jelmer: you know you can just change the product back <lifeless> jelmer: you don't have to mark it as invalid in bzr <jelmer> lifeless: what's the command for that? <jelmer> lifeless: I added a product by accident <lifeless> oh <jelmer> lifeless: in this case <lifeless> I'm not aware of a 'remove this reference' thing; there should be though :) <lifeless> BjornT: ^ <jelmer> I usually just mark as invalid <lifeless> which is basically noise ;) <jelmer> yeah <lifeless> I mean, its equally invalid on all products:) <jelmer> that memory bug in python-subversion was at some point reported to exist in 10 products <keithy_> beginner seeking help <lifeless> hi keithy_ <keithy_> I started a local repo using cd dev; bzr init <lifeless> I'm just cooking lunch, but ask the questions and someone will answer you sortly :) <keithy_> then on a remove mc I try <keithy_> then on a remote mc I try bzr checkout --lightweight ssh://djennings@example.org/dev <jelmer> igc: is there some way with usertest to benchmark different bzr storage formats? <keithy_> and I get "not a branch" <jelmer> keithy_: try bzr+ssh rather than ssh <keithy_> ? <jelmer> bzr+ssh://djennings@example.org/dev <jelmer> as a url <keithy_> oh oops I did <keithy_> then on a remote mc I try bzr checkout --lightweight sftp://djennings@example.org/dev <jelmer> keithy_: and /dev is actually a repository on that host?? <keithy_> its my working dir <igc> jelmer: yes ... <keithy_> and I did bzr init in it <igc> jelmer: let me think how best to do that <jelmer> keithy_: You have to specify the path to your homedir as well <lifeless> igc: we were benchmarking packs vs knits in the past <keithy_> which home dir? <lifeless> igc: that approach worked well <lifeless> keithy_: the path after the hostname is an absolute path <keithy_> yes <igc> lifeless: yes, though that was 2 different branches <lifeless> keithy_: e.g. sftp://djennings@example.org/home/keith/dev ? <keithy_> ah <jelmer> keithy_: you are versioning the special files in /dev ? <lifeless> igc: so create two branches of .dev? :) <igc> jelmer: I'd add a user parameter holding options to init-repo in InitialImportTask <keithy_> why an absolute path? <lifeless> keithy_: so that you can refer to e.g. /srv/ and /var - where people often have repositories <keithy_> ic <lifeless> keithy_: on sftp you can use /~/ to get into your home dir, that is not implemented for bzr+ssh yes. <lifeless> s/yes/yet/ <jelmer> igc: ah, ok <jelmer> I'll give that a try some time, thanks! <igc> then I'd pass in the file format using the --config-file options * jelmer is interested in testing the performance of various bzr-svn versions <igc> jelmer: that's how I test various networking protocols <igc> and it works well <keithy_> great its working <keithy_> ok next question <keithy_> I have a directory of files <keithy_> and I want a commit to always include all of the files in that directory <keithy_> without having to manually add them, they may change frequently <igc> jelmer: my wrapper script for testing networking scenarios - http://rafb.net/p/prTgqd10.html <lifeless> 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 <keithy_> a flag on commit will not doit <keithy_> I want to version the files of an oodb <keithy_> but they change <lifeless> keithy_: well with that flag you could add an alias of commit to commit --automatic ;) <keithy_> I dont want to automatic everything <keithy_> just that one dir <lifeless> ok <lifeless> well its doable via a plugin but there is no canned feature for this <keithy_> I thought that bzr add blah/ <keithy_> should do it <lifeless> bzr add blah/ adds the current content <lifeless> it does not trigger an automatic add on every operations <keithy_> as I found out <keithy_> k next question <keithy_> having checkedout whats the easiest way to push changes back <lifeless> well checkouts work like svn/cvs <lifeless> so when you commit they are recorded in the place you checked out <lifeless> you need to push and pull when you've made a new branch (using bzr branch) <keithy_> ah so the master is the origina <keithy_> I dont understand branch yet <keithy_> so... <keithy_> I have dev as the repo on one mc <keithy_> and I check out to a second <lifeless> you're in the squeak world obviously :) <lifeless> perhaps an analogu will help <keithy_> then any commits on the second are sent to the dev mc <keithy_> I develop in squeak, and version my images in bzr <lifeless> a squeak image is a bit like a branch: you can change it (by journalling your actions) <keithy_> then I use the checkout to deploy to the webserver <lifeless> you can take a copy of it to get an identical image <lifeless> 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 <lifeless> so if you are using a checkout to deploy, your deploy process will be to run 'bzr update' <keithy_> on the server <lifeless> yes <lifeless> because you need the working files update <lifeless> *updated* <keithy_> and if I fix a bug on the server and want to send the result back upstream <keithy_> thats a straight commit? <abentley> beuno: Still around? <lifeless> well, by using a checkout you don't really have upstream/downstream - so yes, just commit <keithy_> wow thats great <keithy_> better than mercurial <keithy_> -) <lifeless> :-) <lifeless> 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. <keithy_> a leightweight remote working dir <lifeless> so we made it a choice for the user <keithy_> right so I can scrap using unison as well <keithy_> cool! <beuno> abentley, yeap <rolly> silly question: there's no authentication possible with the smart server, right? <beuno> playing around with registrys <lifeless> rolly: the smart server itself does not do authentication <lifeless> rolly: we let apache or ssh do that <abentley> beuno: My best theory is that this branch was recently upgraded to packs, but never reconciled. <lifeless> abentley: errors on push/pull ? <abentley> Yes. <lifeless> sftp/smart server/local ? <rolly> lifeless: gotcha, but how do I NOT serve via HTTP? <lifeless> rolly: sorry I don't understand your question <beuno> abentley, ah, yes, was my guess too. No way of fixing it though, right? <lifeless> beuno: sftp/smart server/local ? <rolly> I would like my smart server to be accessible via ssh, but not via http <lifeless> rolly: so just don't make the directory visible over http :) <rolly> Oh, I'm not using apache <lifeless> rolly: or don't configure up the smart server on http. it takes explicit actions to make it visible over http <abentley> beuno: Do you have write access to it? <rolly> But "bzr serve" starts a listening port <beuno> abentley, no, I don't. synic, still around? <lifeless> 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 <lifeless> rolly: just install bzr on the server and you're done <beuno> 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. <abentley> Anyhow, you can run bzr reconcile on it now. <abentley> Or synic can, or whatever. <lifeless> beuno: they should bzr reconcile it remotely <keithy_> after I did my checkout, can I rename the directory? <lifeless> keithy_: sure <keithy_> and I could move it? <rolly> 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 <lifeless> keithy_: yup <abentley> The http version actually a copy, and in this case, it's a failed copy. <keithy_> great! <lifeless> rolly: thats trivial; don't run bzr serve :) <rolly> Oh... duh :D <lifeless> rolly: you have to do stuff to make bzr:// work - by default it doesn't run anywhere :) <rolly> Had a mental roadblock there, thanks <rolly> yeah :p <lifeless> np <lifeless> I don't think we explicitly say anywhere that we don't dopen stuff etc <lifeless> beuno: they should also upgrade the branch; its at branch5, not branch6 <lifeless> beuno: I suggest they do 'bzr upgrade sftp://b.l.n/~....' and 'zr reconcile sftp://b.l.n/~/ <beuno> lifeless, they did reconcile <beuno> didn't fix it <beuno> abentley, aaah, ok ok, it's been tweaked then <beuno> well, synic, ^ <lifeless> so hang on a second <lifeless> its in pack on the public mirror of lp <lifeless> this means a pull from the master repo worked <lifeless> using bzr 1.0 as thats what lp is running <beuno> lifeless, it didn't work before. abentley, did you fix anything? <abentley> beuno: No, I don't have those kind of super cow powers. <lifeless> bzr branch http://bazaar.launchpad.net/~exaile-devel/exaile/main <lifeless> Branched 0 revision(s). <beuno> ah, so it's still borken <beuno> lifeless, they did run reconcile on it <beuno> and it didn't fix it <abentley> lifeless: Exactly. <lifeless> its got no revision history <abentley> The http version doesn't. <abentley> I think the quarrantine version probably does. <lifeless> abentley: true; hmm, does lp create the branch and then pull; if so blech * beuno has to go <lifeless> beuno: get them to talk to us <beuno> lifeless, ok, synic is the man <lifeless> beuno: if they ran reconcile locally it won't fix the remote one <lifeless> synic: ping <beuno> lifeless, he did run it remotely <lifeless> beuno: so we need to be really quite sure of whats going on <lifeless> beuno: also, there should be an error in the lp web page if it was faulting <synic> lifeless: it was remotely <abentley> lifeless: does reconcile work over bzr+ssh? <beuno> lifeless, agreed. synic, lifeless is your man <synic> k <lifeless> abentley: it should I think, but for surety I'd try sftp <lifeless> synic: can I talk you though some python ? <synic> yeah - I'm running reconcile remotely again... should I stop it? * abentley has no idea how the branch puller works. <lifeless> synic: nah, let it finish <synic> alright. <lifeless> synic: we can do this in another window <synic> ok, I've got one open <lifeless> thumper: ping; errors on code.* branches - does everyone see them? (please say yes) <lifeless> $ python <lifeless> >>> from bzrlib.branch import Branch <lifeless> >>> b = Branch.open('sftp://<your branch url here') <lifeless> >>> b.lock_read() <lifeless> >>> print b._format <lifeless> paste the output of the last line <synic> Bazaar-NG branch format 5 <thumper> lifeless: what's up? <lifeless> >>> b.last_revision() <synic> djennings@example.org <lifeless> thumper: https://code.edge.launchpad.net/~exaile-devel/exaile/main shows no error in mirroring, but the mirrored branch has no revision history <abentley> lifeless: Essentially yes, it does a branch followed by a pull. <thumper> lifeless: right, this is the branch I talked to abentley about this morning <thumper> bzr info on the remote branch raises an error <lifeless> thumper: so I'm asking if the reason we don't see errors could be UI madness rather than 'no error occuring' <thumper> lifeless: I confirm ui madness <thumper> will fix on edge soonish <abentley> Who's saying we don't see errors? I posted an OOPS to you! <thumper> abentley: the UI is not showing the error text <abentley> True. <thumper> that madness <lifeless> abentley: yes the errors are available for developers; but folk like beuno that want to help don't have access there <lifeless> abentley: so we should allow the community to share their expertese <lifeless> synic: ok, thats good. <lifeless> synic: whats the exact reconcile command you ran ? <synic> bzr reconcile bzr+ssh://djennings@example.org/~exaile-devel/exaile/main/ <lifeless> synic: ok <synic> it's still running <lifeless> synic: back in python <lifeless> >>> from bzrlib.repository import Repository <lifeless> >>> r = Repository.open('bzr+ssh://djennings@example.org/~exaile-devel/exaile/main/') <lifeless> >>> r.lock_read() <lifeless> >>> ids = r.all_revision_ids() <lifeless> >>> len(ids) <synic> 1628 <lifeless> >>> print r._format <synic> <RemoteRepositoryFormat> <lifeless> heh <lifeless> r._ensure_real() <lifeless> print r._real_repository._format <synic> <RepositoryFormatKnitPack1> <lifeless> ok <synic> reconcile done. <lifeless> cool <lifeless> exit that python shell <synic> alright <lifeless> now <lifeless> cd /tmp <lifeless> bzr branch sftp://djennings@example.org/~exaile-devel/exaile/main/ tmp-main <lifeless> oh, and separately, 'bzr upgrade sftp://djennings@example.org/~exaile-devel/exaile/main/' <lifeless> (your branch object is still branch5, not branch6 <synic> bzr: ERROR: Could not install revisions: <synic> djennings@example.org <lifeless> can you pastebin the full backtrace from your ~/.bzr.log <lifeless> synic: do you have a local copy of this that is working well ? <synic> yes <synic> http://rafb.net/p/2UgHVp51.html <abentley> lifeless: I thought you were saying there was no indication of errors. I think everyone agrees that having the error details would be handy. It's even awkward for me to get those error details, much less community people. <lifeless> abentley: thats cool; we're on the same page now <lifeless> synic: oh, what version of bzr are you using ? <synic> 1.1 <synic> just upgraded today. <lifeless> ok, heres what I think is happening <lifeless> the branch history includes a revision id not in the repository <lifeless> we can test this <lifeless> python <lifeless> >>> from bzrlib.repository import Repository <lifeless> >>> r = Repository.open('sftp://djennings@example.org/~exaile-devel/exaile/main/') <lifeless> >>> r.lock_read() <lifeless> >>> r.has_revision('djennings@example.org') <abentley> lifeless: cat-revision FTW <synic> False <lifeless> abentley: I have the internal api branded on the inside of my skull <lifeless> synic: ok, this hypothesis is proved :) <synic> nice <abentley> Do we know the revision's in the history, not just the ancestry? <lifeless> abentley: given the error its the branch tip <abentley> That's curious. <lifeless> abentley: its raised from missing_revision_ids(ID) <lifeless> synic: but lets dig a little further <lifeless> >>> from bzrlib.branch import Branch <lifeless> >>> b = Branch.open('sftp://djennings@example.org/~exaile-devel/exaile/main/') <lifeless> >>> b.last_revision_id() <synic> AttributeError: 'BzrBranch5' object has no attribute 'last_revision_id' <abentley> lifeless: bzr revision-history FTW <lifeless> abentley: shrug <lifeless> synic: sorry, drop the _id() <lifeless> abentley: I find it easier when passwords etc are involved to be using a stateful instance <synic> djennings@example.org <lifeless> right, the tip revision id is not in the repository <lifeless> synic: can you bzr push your good local copy to the remote repository please <synic> well, it's not completely up to date <lifeless> synic: your local one ? <synic> probably a few revisions behind. He pushed a couple yesterday and the day before <lifeless> synic: this should fix itself if he pushes now <synic> hehe, if only he'd sign on. <synic> but ok, I can wait <synic> ... wait, so I can push now anyway, and at least the repo will be usable, and then if he pushes, it'll be up to date <synic> ? <lifeless> yes <synic> ok, cool <lifeless> as long as you have djennings@example.org in your branch and repository <lifeless> you can check that the same way ;) <synic> hrmm, yeah, it says the branches have diverged, and to merge <synic> at which point I get the same error <lifeless> right <lifeless> you don't have the tip <synic> ok, so plan is: just wait for him to push again <lifeless> are you sasongko ? <synic> no. <lifeless> are you are <djennings@example.org> ? <synic> yeah <lifeless> you know, you guys probably want heavyweight checkouts for this shared branch <lifeless> it will avoid commits like 1518. By Adam Olsen <djennings@example.org> on 2008-01-03 <lifeless> merging <synic> ok, that's what we'll do from now on <synic> thank you very much for your help <lifeless> np <synic> oh, how do we avoid this in the future? <synic> was it an upgrade or something? <abentley> synic: Bazaar is designed not to cause this kind of problem in the first place. I'd really like to hear what happened. <abentley> Your problem was basically that the branch was updated to point to a revision that wasn't in the repository. <abentley> But we always put the data in the repository first. <abentley> And we update the branch after that. <synic> hrmm, well I'll talk to Johannes when I can get ahold of him, and if he noticed anything strange happened, I'll let you guys know <synic> he's usually on every day, I'm not sure where he is today. <abentley> Ask him if he uses rsync. <abentley> And have you guys upgraded recently? <lifeless> abentley: can't use rsync against lp :) <abentley> Well, that's good. <abentley> I suppose it's possible he ran a copy locally or something. <abentley> I'm just trying to think of a likely operation that would update the branch before the repo. <lifeless> yah <lifeless> poolie: So pulling that 100 mainline revisions <lifeless> poolie: we have a cache hit rate of 22% <poolie> (here) <lifeless> I'm going to chase a few thoughts down, see if I can increase that <lifeless> and 5 round trips <lifeless> conceptually, if I get that up to say 70 or 80 % <lifeless> and bzip2 the content <lifeless> it should get down to 2 rt at most <lifeless> neat, my register-branch fix has landed <Peng> Can you do random sftp stuff to Launchpad? <igc> have a good weekend all <lifeless> Peng: not really <poolie> Peng, it's not supported <ubotu> New bug: #187988 in bzr-webserve "Time is 38 years" [Undecided,New] https://launchpad.net/bugs/187988 <awilkins> jelmer? <jelmer> awilkins: hi <awilkins> jelmer: I can't seem to use bzr-svn ; it keeps saying "not a branch", even for bzr svn-branching-scheme --set <url> <jelmer> awilkins: What URL are you trying to access and what do you have the branching scheme set to? <awilkins> URL is svn+http://commsg1lds.npfit.nhs.uk/svn/mim/trunk <awilkins> Branching scheme is set to nothing because it produces the error when you try to set it <awilkins> (domain isn't accessible outside our intranet I'm afraid) <jelmer> What error does it produce exactly when you try to set the branching scheme? <awilkins> bzr: ERROR: Not a branch: "svn+http://commsg1lds.npfit.nhs.uk/svn/mim/trunk". <awilkins> This is bzr-svn 0.47 (pulled from the repo). <jelmer> You can only set the branching scheme on the repository <jelmer> not on a branch <awilkins> Ah, right, it's a repository level variable? <jelmer> you probably want svn+http://commsg1lds.npfit.nhs.uk/svn/mim <jelmer> you should be able to check out /trunk without messing with the branching scheme though <awilkins> Same again <awilkins> Tried the root of the repo, same error <awilkins> Client is win32 bzr 1.1. <awilkins> server is windows apache 2.0 SVN 1.4.3 <jelmer> awilkins: Does "bzr selftest svn" work ok? * awilkins sets it off <jelmer> This may be a windows-related problem <awilkins> Yeah, I tried mirroring a different SVN repo on my Ubuntu laptop at home and it worked fine <awilkins> The test is just sitting there not eating CPU time. <jelmer> doesn't give a progress indicator? <jelmer> It can take some time to run <awilkins> It's only printed the banner to STDOUT (got as far as C:\Python25\lib\site-packages\bzrlib (1.1.0 python2.5.1.final.0)" <awilkins> Not responding to ^C either <awilkins> Looking at the files it was loading, I think it got stuck somewhere in xmloutput, I'll move that folder <awilkins> It's hitting "Unable to open an ra_local session to URL" errors now <awilkins> [42/728 in 209s, 35 errors, 1 failed] <awilkins> I'm guessing something isn't right :-) <awilkins> Lots of those 180001 errors <jelmer> awilkins: what python-subversion bindings are you using? <jelmer> the latest from the wiki? <awilkins> jelmer: I'm running the patched ones (installed the official ones and unpacked the patched ones over the top) <jelmer> awilkins: It looks like the bindings you have installed didn't link against bdb? <awilkins> THe bindings from here : http://home.comcast.net/~klight/bzr/ <jelmer> hmm, those should work ok <awilkins> DO you use bdb repositories for the test, or just hte default>? <jelmer> we use the default <awilkins> The default has been FSFS for some time <jelmer> Any chance you can upload the output of the test run somewhere? <jelmer> I also did this with bialix a couple of days ago and thought most of the errors on Windows were fixed.. <awilkins> Does the output get logged because I didn't redirect it anywhere. <jelmer> no, it doesn't afaik <jelmer> you'd have to redirect it <awilkins> It all looks like the same error <awilkins> ERROR: bzrlib.plugins.svn.tests.test_repos.TestSubversionRepositoryWorks.test_format ('Unable to open an ra_local session to URL', 180001) <jelmer> Without the full backtrace (printed at the end of the test run) that error isn't very useful <awilkins> Ah, well, when it finally finibzr plguins <awilkins> Oops <awilkins> Would a single test run from a python interpreter be sufficient? <awilkins> As you said, it takes some time <awilkins> jelmer: I have that trace if you want it uploaded somewhere <jelmer> awilkins: Yeah, that would be useful <awilkins> http://filebin.ca/sgsgjc/svntest.zip <jelmer> awilkins: thanks <awilkins> It does look like a bindings problem <awilkins> Maybe <jelmer> ah, it's one of the test functions that's going wrong.. <jelmer> Yeah, this explains why you would get that NotBranchError <jelmer> strangely enough bialix was able to Kevin's bindings without problems <awilkins> Is this to do with the "short" path wrangling that's going on? <jelmer> I don't know <awilkins> Weird suggestion ; my user profile is not on the same drive as my PYTHON_HOME <jelmer> I don't think that should matter <jelmer> I'm afraid you're on your own here though, I don't have windows here atm :-/ <awilkins> I'm looking .... IDLE makes a sorry debugger next to Eclipse or Visual Studio :-( <ubotu> New bug: #188042 in bzr "workflow improvement. bzr locked whilst uploading, can't bzr add." [Undecided,New] https://launchpad.net/bugs/188042 * awilkins hangs himself from a noose composed of recycled fibres from printouts of the VB6 code he is debugging. <TFKyle> who in their right mind would print code out? :P <lixomancem> Hello. I was taking a look at Bazaar and checking its features and how it worked, but there is something I couldn't find any info on and would like to ask here. Does Bazaar have a feature like SVN's "externals"? I.e., a folder inside a branch that actually represents a branch of another repository, and that is updated from that repository when I run the update command on the whole thing? If... <lixomancem> ...so, where can I read more about this? <beuno> lixomancem, AFAIK, that's not available yet. We're still waiting for nested trees feature to get polished for wider use, which would be a requirement for something like that <beuno> of course, I'm fairly sure you can do some black magic with plugins <lixomancem> Alright, thank you for your answer. I believe I'd rather wait for support for that kind of thing on bzr instead of trying plugins for that. <ubotu> New bug: #188089 in bzr "relies on sha1 for inventories" [Undecided,New] https://launchpad.net/bugs/188089 <lixomancem> Just out of curiosity: is there any work being done on a Windows GUI? Not that I need one, but I can't get my company to use bzr unless there is one. <beuno> lixomancem, you _do_ have the eclipse plugin, but I'm not sure if that's what you're looking for <lixomancem> Hmm I didn't know about that one. Not exactly what I'm looking for, but I'll take a djennings@example.org. Thanks. <beuno> lixomancem, np <LeoNerd> bzr log --line >some-file truncates the lines at 80 columns with "...".. How can I make it not do that? <dato> LeoNerd: COLUMNS=3000 bzr log --line >some-file <dato> or, for portability, `env COLUMNS=...` <LeoNerd> Ah :) That got it, thanks <mthaddon> can someone help me out - just trying to get the status of a bzr tree in python using bzrlib - must be missing something simple <mthaddon> I've tried bzrlib.show_tree_status(path), but no luck <luks> get the status in what form? <mthaddon> in the same way that I would from "bzr st" from the command line, for instance <mthaddon> basically I just want to see if there are uncommitted changes <luks> tree.changes_from(tree.basis_tree()) will get you lists of changed files <luks> or you you want actual text output? <mthaddon> what's the "tree" object? <luks> *do <luks> a result of e.g. WorkingTree.open(path) <luks> or WorkingTree.open_containing(path)[0] <mthaddon> sorry, I'm really basic here - I'm doing "import bzrlib" but don't see WorkingTree as a module of bzrlib <james_w> bzrlib.workingtree.WorkingTree <luks> from bzrlib.workingtree import WorkingTree; tree = WorkingTree.open('.'); print tree.changes_from(tree.basis_tree()) <mthaddon> great, thanks!! <noblex> hi, is bzr-gtk 0.93 compatible with bazaar 1.1? <rolly> works for me on Windows <n[ate]vw> can bzr set the PYTHONPATH for an ssh connection like it can set the BZR_REMOTE_PATH ? <dato> n[ate]vw: I don't think so, but you could set remote_path to a local executable wrapper that sets it, and execs bzr, if you really need it <n[ate]vw> sounds like a good solution, though I might just install system-wide and be done with it <abentley> n[ate]vw: bzrlib doesn't have to be in your PYTHONPATH if the bzr executable is directly above it. <n[ate]vw> abentley: interesting. it complained about bzrlib the first time, but not the second <n[ate]vw> might have to go that route, looks like bzr wants to install in /usr/local/bin, which isn't in the ssh path <n[ate]vw> or maybe this is all moot, since I just learned the difference between .bash_profile and .bashrc. I can just amend the PATH/PYTHONPATH to my user install <abentley> n[ate]vw: bzr doesn't have to be installed, btw. You can just unpack the tarball and run it from there. <n[ate]vw> abentley: doesn't installation pre-compile some stuff, though? <n[ate]vw> basically, the deal is that OS X doesn't come with a /usr/local, and so I typically just install things to a custom prefix (since I have to modify path anyway) <abentley> It does, but that stuff is optional. And you can compile it in place, too. <n[ate]vw> how would I compile in place? <abentley> make <n[ate]vw> heh, easy enough <n[ate]vw> probably better to just keep intalling it in /Users/Shared/dev instead of having my path point to ~/Downloads, though :-) <ubotu> New bug: #188198 in bzr "Network outage results in unrecoverable interruption during svn+http:// branch" [Undecided,New] https://launchpad.net/bugs/188198 * awilkins waves at ubtou <jelmer> awilkins: See the bzr-svn FAQ for a workaround of the bug you just filed <jelmer> awilkins: sorry, please look at the bug I just linked your bug report to <awilkins> jelmer: Aha, thanks for that. <awilkins> jelmer: The problems I was having earlier seem to have evaporated ; maybe it's just my weird repo layout at work <awilkins> I'm not trying to branch the same repository here. <jelmer> awilkins: not the same repository? <jelmer> you mean the repository that was giving trouble was different? <awilkins> jelmer: Yes, the repo I was having trouble with "not a branch" errors is an internal one. <jelmer> awilkins: The testsuite also failed so there's definitely something broken in your setup <awilkins> jelmer: pycurl respets the IE proxy settings (if bzr-svn uses pycurl for HTTP traffic)? <jelmer> no idea <awilkins> It appears to, I had to go into IE options and switch off proxy to branch this repo from home. <awilkins> The selftest doesn't run, but I've just managed to branch a repo here. <awilkins> jelmer: I think I found the problem with the tests ; file:// urls on windows still have to start with a / (so they end up as file:///d:/stuff <awilkins> Well, one problem <rolly> To move a standalone branch into a --no-trees shared repository, is it sufficient to just copy it over with my OS? <Peng> If you just copy it over, you'll copy over the branch's copy of the repo too. <Peng> It would be better to "bzr branch" into the repo. <rolly> Ah, yes. Thanks Peng <Peng> You might also be able to manage something with copying it over and using "bzr reconfigure". <Peng> "bzr branch" ensures that the shared repo has all of the revisions in the branch and sets it all up correctly, but you'll have to set the branch's parent again. <rolly> It's an empty shared repo, and I'm adding the "top-most" branch parent <rolly> hm, I tried bzr reconfigure -v --branch ., and the result was an error ("already a branch"). But branching worked fine. Thanks again Peng <hsn_> any work on Netbeans BZR plugin? <jelmer> hsn_: No, afaik not <awilkins> jelmer: I fixed up that ra_local problem in the tests, and found a couple of other potential problems <jelmer> awilkins: Ah, cool <awilkins> jelmer: Some of the code is using os.name instead of sys.platform == 'win32' (os.name == 'nt). And those links have to start with a slash on win32, not a drive letter. <jelmer> awilkins: ahh <awilkins> it;s like there's a magic "root" above the drives <awilkins> Still getting errors, but not the same boring error for every single test. <jelmer> this is 0.4.7 ? <awilkins> Right, I don't have enough battery (laptop or brain) to stay awake. <awilkins> This is 0.4.7 (pulled to r 877 from the 0.4 branch) <awilkins> Lots of "permission denied" on removing test directories. <awilkins> But that isn't causing failures or errors #bzr 2008-02-02 <jelmer> awilkins: any chance you can file a bug with that patch attached before you go to sleep? <awilkins> jelmer: Hmm, this is odd ; bzr update says tree is up to date, but there's a huge diff <awilkins> smore like it - diff -r 877 <jelmer> awilkins: what do you expect "bzr update" to do? <jelmer> it only makes sense if you have a bound branch <awilkins> I was expecting it to update my working tree to the latest revision in the repository <jelmer> it will only do that if you used "bzr co" <jelmer> if you used "bzr branch" to create the branch you need to use "bzr pull" <awilkins> No revisions to pull , my tree is at 877 but my repos is at 891 ; hence a huge diff unless I specify 877 <jelmer> awilkins: A repository doesn't have a tip, not sure I'm following... <awilkins> The source in my working tree (plugin folder) is at 877 (release 0.4.7) <awilkins> But the repo has revisions up to 891 (HEAD) <awilkins> If I diff the tree, it includes reverse diffs all the way back to 877 <awilkins> Launchpad is fubar <jelmer> Where do you diff against? <jelmer> Also, what do you mean by repo? <awilkins> The revisions in the .bzr folder (it's a standalone branch) <awilkins> bzr log -r -1.. shows revision 891 <awilkins> But the source is at 877 <jelmer> "bzr revno" gives 891 ? <awilkins> ItYes <awilkins> The source being at 877 was intentional, I wanted the release tag <jelmer> Ah, you ran "bzr update -r877" or something? <jelmer> or perhaps "bzr revert -r877" ? <awilkins> bzr pull -r 877 I think <awilkins> Maybe revert <jelmer> revert would do that <jelmer> if you can send in a diff against 877 that would help too <awilkins> jelmer: sorry, downtime, ignored my battery warning for too long. <awilkins> Back up again now <jelmer> welcome back :-) <awilkins> #188233 <jelmer> thanks * jelmer waits for ubotu to announce <awilkins> Grr, I've reverted up to 891 and now gnu patch won't apply <ubotu> New bug: #188233 in bzr-svn "PATCH : fix some win32 testing issues" [Undecided,New] https://launchpad.net/bugs/188233 <awilkins> Hooray for ~1~ files <rolly> Hm, if I make several revisions to a branch, how can I merge those changes to a parent branch without losing the original commit messages? <rolly> SVK has "--verbatim --incremental" <jelmer> rolly: Just use "bzr merge" <jelmer> bzr log will then show the merged revisions indented <rolly> I can't, because there is a revision that must not be propagated <rolly> i have to specify a range <jelmer> rolly: that would be a cherrypick <jelmer> rolly: tracking cherrypicks is not supported yet <rolly> OK thanks <rolly> This puts a damper on my plans for world domination <rolly> :p <awilkins> Do the merge and reverse merge the "bad" revision? <awilkins> jelmer: Do you prefer bzr send output or bzr diff? <rolly> That would be only slightly better <jelmer> awilkins: bzr send please <rolly> I'm just going to have to refactor this code so there aren't any "special" files that can't be propagated * awilkins attaches <awilkins> Ah, the old "special" files with the CEO's password in. <rolly> yep yep <rolly> nuclear launch codes <jelmer> awilkins: For "bzr send", you have to commit ifrst <jelmer> you now attached an empty bundle :-) <awilkins> I wondered why it was so short, I was really impresed :-) * awilkins attaches a patch with stuff in it <jelmer> thansk, merged <mtaylor> is there a roadmap/timeframe for 1.2? <awilkins> https://launchpad.net/bzr/1.2/ <mtaylor> awilkins: thanks <rolly> Say, what are the *.~1~ files? No mention of them in the reference guide <mtaylor> anybody know what this means: "not updating child fraction" <jelmer> mtaylor: A progress bar issue <Peng> rolly: "bzr revert". <rolly> Peng: thanks <rolly> (handy feature) <homerj> floam likes to touch himself at night <homerj> don't listen to him <floam> can bazaar automatically throw the current revision into files at some spot I wish somehow? <floam> god damn it <rolly> automatically? there are hooks you can use <Peng> floam: There's no built-in support for keywords like $Id$ though. <floam> rolly: I just meant, magically have a number pop up in some file under version control without having to call bzr revno or anything <floam> Peng: ok, thanks <rolly> Oh I misread you. Something like CVS then eh <Peng> floam: Yeah, currently you have to do something like execute "bzr revno" in your Makefile. <floam> yeah, I was doing that. It just means I need to think a bit harder, because I was hoping the number would be there when my users run a setup.py. I'll just need to keep a static file in the distribution with the number in it <homerj> floam, things popping up and thinking "harder" is what leads yourself to touch yourself at night <rolly> That's a bit of stretch <floam> ... <mtaylor> dude. I walked in on the wrong conversation <awilkins> rolly: ~1~ files are "revert" leftovers <awilkins> jelmer: I have a new trace from bzr seltest svn on win32 if you want it. <awilkins> Not that you have a windows box :-) <awilkins> jelmer: The major error now appears to be that the support for is_executable relies on the inventory, but it's being called in the read_inventory routine (in add_file_to_inv) <Stavros> hello <Stavros> i am thinking of using bzr for regular backups <Stavros> does it only keep the diffs of changed files, or the whole files? <james_w> Stavros: diffs. <Stavros> even for binary files? <james_w> Stavros: yes, but the diffs are not very efficient in that case. They can be very suboptimal in fact. <Stavros> ah hmm <Stavros> and it keeps the history locally as well, so it wouldn't
{'channel': 'bzr', 'month': 2}