[00:00] LeoNerd: I'm going to bed now, if you want to discuss this in more detail, drop me an email at D.M.Watkins@warwick.ac.uk (or email the list). :) [00:00] Night all! [00:05] damn people in london and their sleeping habits === mwhudson_ is now known as mwhudson [00:25] Hi. someone remind me how to roll a working copy back to a previous revision? I seem to have svn brain today, I expected 'bzr up -r ...' to do it :) [00:25] bzr revert -r ... [00:25] hah, ok [00:26] You're thinking in CVS-mode :) === mw is now known as mw|out [06:53] Hi everyone [06:54] Anyone have success using bzr-svn against a svn repository with authentication? The passwords are cached by my subversion client, but no joy on both gentoo and mac os x... [07:44] * mwhudson_ has been amusing himself this evening: http://people.ubuntu.com/~mwh/really_hacked_up_changelog_view.png === mwhudson_ is now known as mwhudson === abentle1 is now known as abentley [08:37] anyone knows if there is a way to have bzr behave in a similar way to git ? concerning branches and repositories ? [08:37] I mean 1 folder contains many branches [08:37] Not yet. [08:37] Maybe in the future. [08:47] ans is there a way to rewrite the history ? [08:52] rewrite in what way? [08:53] morning [08:53] luks: change the commit log [08:54] or change the committed files [08:54] uncommit + commit? [08:57] luks: something like : http://www.kernel.org/pub/software/scm/git/docs/git-filter-branch.html [08:58] luks: maybe you would want to take a look at this: http://blogs.gnome.org/newren/2008/03/01/happenings-in-the-vcs-world/ [08:58] it is quite biased toward git, but still contains interesting ideas and complains about bzr [08:58] umm, I think I really don't want to :) [08:59] no, bzr doesn't have anything like git-filter-branch, but I think that's good, not bad [08:59] luks: that's exactly his complain: the bzr devs don't want to listen:p [08:59] I'm not a bzr dev, btw [09:00] but I wouldn't listen anyway :) [09:00] luks: and honestly git-filter-branch can be really useful [09:00] how so? [09:00] isn't VCS about keeping your history? [09:00] I can understand it's use for migrating or restructuring branches [09:01] but not to change commit message or things like you mentioned [09:01] yes, but let me give you some use cases [09:01] let's say I work for a company A, that uses bzr [09:01] There are many very good reasons to want to wipe out history :) [09:02] I worked for a long time on a proprietay project for them , and some day they decided it should go open source [09:02] however, there are some files early in the history of the bzr branch, that are confidential [09:02] I still want to pusblish the whole branch with its history [09:02] how do I do ? [09:02] yes, that's one valid use case [09:03] but the first two you mentioned were not [09:03] which ones ? [09:03] luks: change the commit log [09:03] or change the committed files [09:03] luks: sometimes there are typos in the commit log [09:04] typo in the commit message is IMO part of the history and should stay there [09:04] and sometimes there is a morron in your project who would put crappy commit logs [09:04] otherwise you break the branch for everybody else [09:04] and you want to fix that [09:04] it's part of the history, don't change the history :) [09:05] Down, boy! Keep your dogma on its leash! [09:05] :) [09:06] I guess I just don't like git too much, so I'm not the right person do discuss this :) [09:06] luks: I don't like git at all, and for good reasons [09:06] In a lot of cases, breaking the branch is totally acceptable. In a lot of cases, I know exactly where every copy of the branch is, so remaking them all is a bloody inconvenience, but entirely possible. [09:06] but many people like git, and if you really like bzr, you should listen to their critics and improve [09:07] I'm not saying filtering shouldn't be possible [09:07] but in git it' a common operation [09:07] *it's [09:08] btw, I don't like bzr either :) [09:08] ... [09:08] but it's the only acceptable one [09:08] I think there are many things to improve in bzr, maybe also change its name [09:09] "All mail clients suck. This one just sucks less." [09:09] many people still confuse bzr with bazaar [09:10] asabil: That's going to be fixed soon. [09:11] oh really ? [09:11] The Debian 'bazaar' package will install both bzr and baz. [09:11] And eventually just bzr. [09:11] that would be better [09:11] Typos are one thing, but sometimes I really do want to change the commit message when it's wrong. [09:12] version the changelogs lol [09:12] err commit messages [09:13] That could work. [09:13] johnny: The commit messages _are_ versioned, with the content of the trees. [09:13] It would, of course, be too complicated, but would be useful. [09:14] i mean seperately Odd_Bloke [09:14] but i personally don't need such a thing.. [09:14] you could find a way to replay the history tho [09:14] Peng: then uncommit it and commit again [09:15] if you notice it later and the branch is already published, rewriting is IMO the wrong thing to do [09:16] morning [09:18] I still think that rewriting the history and filtering a branch can be a really neat fature for bzr [09:18] also bzr could improve its handling of Limbo files [09:18] maybe by adopting an interactive ui like darcs [09:19] or having an ibzr command that is fully interactive [09:34] luks: The only time I can remember it bothering me was with a personal, non-code branch that isn't published. There had also been commits since it. [09:44] asabil: handling of Limbo files? [09:46] LarstiQ: unknown files [09:47] LarstiQ: you know the "Oh sh*t i forgot to add those files before committing" [09:49] asabil: ah. You confused me since limbo has a specific meaning in bzr, and I have never heard of this use before.\ [09:49] jam: are you running bzr serve or somesuch? [09:50] LarstiQ: http://blogs.gnome.org/newren/2007/12/08/limbo-why-users-are-more-error-prone-with-git-than-other-vcses/, presumably [09:51] asabil: There's 'bzr shell', in bzrtools I think. [09:51] LarstiQ: I am now :) [09:51] Odd_Bloke: and ? [09:52] Odd_Bloke: ever used darcs ? [09:52] asabil: maybe you are looking for commit --strict? [09:53] LarstiQ: rather something like darcs record [09:53] asabil: 'bzr shell' is similar to an interactive bzr command, but I should have read more context. [09:54] asabil: Didn't you write the 'record' plugin? [09:54] Odd_Bloke: yes, the record plugin should be renamed btw into bzr make-patch [09:54] or something like that [09:54] asabil: Ah, yes, I recall now. [09:54] I wanted it to become like darcs record, but never had time to finish it [09:55] * LarstiQ is a bit low on cycles [09:55] I'd have thought it would be fairly trivial to switch from creating a patch to creating a commit. [09:55] asabil: I don't know darcs well, what about record is it that you are looking for? [09:55] * Odd_Bloke doesn't have any motivation to do it himself, because he wouldn't ever use it. [09:55] I'd be happy to help someone who does have some motivation though. [09:58] LarstiQ: basically darcs is fully interactive, so when you issue a darcs record (the commit equivalent), it will prompt you about the hunks to record [09:59] (in a similar manner to bzr shelve), then it will ask you for a record name (commit message), before finishing the record [09:59] iirc it will also warn you about unknown files [09:59] asabil: right, which --strict will also do [10:00] LarstiQ: --strict is interactive ? [10:00] asabil: no [10:00] Odd_Bloke: maybe can we cook up something together ? [10:00] Odd_Bloke: I want to make the record plugin add a --interactive command to commit [10:01] * LarstiQ doesn't think interactivity is desirable in the general case, so if there are useful features of record that can also work non-interactive, that would be nice to factor out [10:01] s/command/option/ [10:01] or rephrased, not only the interactive users should benefit [10:02] make the interactive users benefit until you find a way to make the non interactive users benefit as well [10:02] fair enough :) [10:02] dudes! [10:02] jelmer! [10:02] how is the sprint today? [10:03] jelmer: they just did a firealarm test [10:03] but announced it so we could just sit and not do the entire evac thing [10:04] asabil: There was someone in here last night who was also interested in that exact thing. [10:05] It was, in fact, LeoNerd (implicit ping). :) [10:14] LarstiQ: ah, that's nice for a change [10:15] yeah, there were nice enough when I explained why *I* prefer it to be a lighter test... [10:17] jelmer: do you have anything to say on file copies/path tokens? [10:18] LarstiQ: I'm not sure I entirely remember how they were supposed to work [10:18] ah :) [10:19] jelmer: abentley and lifeless are probably about to have a discussion regarding file copies, hence the question. :) [10:22] Odd_Bloke: Any chance of you adding a "mirror-update" command to that plugin today? :) [10:23] Odd_Bloke/LarstIq: The wiki page on path tokens doesn't appear to have any actual design details, just use cases :-( [10:23] spiv: That's my next step. :D [10:23] jelmer: rob's comment was that pathtokens may be a implementation strategy for filecopies, but they don't need to be the way to do it. [10:24] Odd_Bloke: I have a use-case of a sort [10:24] LarstiQ: makes sense [10:25] spiv: Cool. [10:25] Odd_Bloke: I have just made a "bzr svn-import" of Twisted's SVN on my laptop, and when I update it (by running bzr svn-import again in the same dir), I'd like a way to update the copy of the import I've put at http://people.ubuntu.com/~andrew/twisted/ [10:25] Odd_Bloke: rsync works atm, but isn't exactly ideal... [10:50] Odd_Bloke: let's say I have a patch, how do I commit it (working on --interactive) [10:50] too bad there's no video feeds [10:50] but at least there is the BrainStorms page [10:51] asabil: Well, apply it to the tree and then commit as normal, I guess. [10:51] jelmer: we could do a conference call I suppose [10:52] oki [10:52] spiv: I've just pushed an initial implementation of mirror-update to mirror.dev. [10:53] Odd_Bloke: thanks! [10:58] LarstiQ: it's being discussed right now? [10:59] jelmer: Nope, plugins ATM. [11:00] spiv: So I'm finding some slightly odd behaviour in that the mirror-update command is pulling the revisions and the history into the branches appropriately but 'bzr log' complains about logging the null revision. [11:00] 'bzr log -r1' shows the right thing, however. [11:01] Odd_Bloke: hmm, mirroring a rich-root-pack repo doesn't work [11:01] It creates pack-0.92 at the destination then barfs. [11:02] hmm, is bundle-buggy down or just being slow [11:03] Odd_Bloke: are you using tree.pull() or branch.pull() [11:03] I get "bzr: ERROR: Repository KnitPackRepository('file:///var/tmp/foo/.bzr/repository/') is not compatible with repository KnitPackRepository('file:///var/tmp/blah/.bzr/repository/')" when doing that. [11:03] spiv: ^ [11:03] james_w: branch.pull() [11:03] Odd_Bloke: right. [11:03] Odd_Bloke: you want tree.pull() anyway. [11:03] jelmer: abentley was using it earlier, but I don't know about ATM. [11:04] james_w: How's that going to cope with branches without trees, which is probably what we want from this (as the eventual use-case is switching into the mirrored branches)? [11:05] Odd_Bloke: well, use open_tree_or_branch() and then you know whether there is a tree there already, and then switch between tree.pull() and branch.pull() [11:06] Odd_Bloke: and I guess you have to solve that branch.pull() problem. [11:06] I can show you some code that does the former if you like. [11:06] james_w: Sure, please. :) [11:06] jelmer: BundleBuggy WFM ATM TLA. [11:07] Odd_Bloke: hmm, looks like it's just being very slow to me [11:08] spiv: Yeah, it'll be fun. :p [11:11] Peng: Do you have pqm access or should I submit the branch for "http://bundlebuggy.aaronbentley.com/request/%3C47C5D9C0.5080702@mattnordhoff.com%3E" ? [11:13] jelmer: the debian/watch files for bzr-email and bzr-pqm in Debian seem to be pointing at the wrong LP pages [11:13] according to http://qa.debian.org/developer.php?login=pkg-bazaar-maint@lists.alioth.debian.org [11:14] jamesh: as far as I know there is no watch file for bzr-email and bzr-pqm [11:15] jelmer: maybe that site creates automatic watches then. My mistake :) [11:16] jamesh: I wonder how though [11:17] since it seems to be using launchpad urls [11:17] igc: ayt? [11:17] heya dato [11:17] hey LarstiQ [11:18] jelmer: the home page from the package metadata [11:20] New bug: #199440 in bzr "Traceback if authentication.conf contains section without password " [Undecided,New] https://launchpad.net/bugs/199440 [11:22] hi dato [11:22] jamesh: and it then makes assumptions about the releases being on launchpad as well? [11:22] dato: spoke to abentley re the best way to do fast-export ... [11:22] aha [11:22] two revision-trees and changes_from is fine [11:23] abentley also mentioned iter_changes [11:23] and had some idea down the track [11:24] I saw iter_changes, but only as a _underscore_method, so I went with public stuff [11:25] changes_from is a bit ugly and lossy. [11:25] s/idea/ideas/ [11:25] re more efficient ways [11:25] I imagine that two rev-trees + changes_from is fast enough for any projects though ... [11:25] so we ought to stick with that initially I feel [11:25] s/any/many/ [11:25] abentley: lossy? [11:25] Odd_Bloke: one of the log messages of bisect we looked at mentioned working with merged revisions, what was that about then? [11:26] New bug: #199442 in bzr "every command twice encode sys.stdout?" [Undecided,New] https://launchpad.net/bugs/199442 [11:26] LarstiQ: I dunno, I thought it coped with them too. [11:26] I may have screwed the test up. ^_^ [11:26] igc: now, I have bzr-crude-export.py in a state that does everything I'd need, so I'm not sure how much more time I'd like to put into it. otoh, I'd like to release it. so, how about I drop a mail about it in bazaar@ and git@, and mention that it'll probably need a new home in the future, possibly bzr-fastimport? [11:27] dato: There are some combinations with kind changes that aren't recorded properly by changes_from. [11:27] abentley: ok. my script doesn't look at kind_changes atm, so... [11:28] dato: I definitely want it in fastimport and I'm happy to own it [11:29] abentley: btw kind_changed seems missing in TreeDelta's __doc__ [11:30] spiv: I'm not going to work that mirror bug out now, as I think the git-style branches discussion will have some bearing on it. [11:30] igc: ok. shall I keep calling it -crude, or would be -fast ok with you? I'll mention in __doc__ that later on it'll live in launchpad.net/bzr-fastimport [11:32] dato: fast is ok. If you send me the code or link, I'll include it real soon now [11:32] bbiab [11:33] Odd_Bloke: ok, done I will publish my interactive commit crack [11:34] asabil: Cool. :) [11:35] Odd_Bloke: any name to suggest ? [11:35] bzr_interactive ? [11:36] asabil: interactive-commit, or somesuch. [11:36] Odd_Bloke: it also contains a record-patch command [11:36] asabil: I dunno then. [11:36] It can always be changed later. :p [11:44] abentley: what do you think about adding the record-patch command to bzrtools ? [11:45] LarstiQ, *ahem*debconf*ahem* [11:47] I'm not keen on making it easy for people to do partial commits. [11:53] It's already easy... bzr ci some files here [11:53] The hunk selection only extends a bit further, to do changes -within- files.. It's really no worse in principle [11:54] It just depends on the (fairly-arbitrary) way that the user has split their content across files [11:57] LeoNerd: Different-in-degree is good enough for me. [11:59] abentley: oO record-patch is about creating patches manageable with quilt [12:02] beuno: yes, thank you :) [12:12] asabil: You should really look into looms, then. [12:13] That should be a much more reliable way of generating quilt-compatible patches. [12:14] igc: ok, I CCed you. I'm sorry is a git repo, but feel free to use git-fast-export! :-P [12:14] oh, oki didn't know aboutit [12:14] thanks [12:20] Odd_Bloke: makes sense [12:21] spiv: That's what I thought. However, it seems like the discussion may not happen after all... [12:23] Odd_Bloke: we'll see... [12:23] *ominous music* [12:43] how do I list all commands provided by a plug in? [12:47] jml: "bzr help commands | grep PLUGIN-NAME [12:47] jml, or use lifeless' plugin-info plugin: https://launchpad.net/bzr-plugin-info [12:48] spiv: doesn't work [12:48] <-- still not stupid [12:48] abentley: http://pastebin.slackadelic.com/426 is a patch that removes a couple of Python-2.5isms from your LP directory service patch. [12:48] spiv: because help wraps [12:52] Odd_Bloke: tx [12:52] abentley: NP. [12:56] jml: "grep -1 PLUGIN_NAME" ;) === mrevell is now known as mrevell-lunch [12:57] spiv: wrath [12:59] spiv: and violence. [13:08] jml: :) [13:12] spiv: (it doesn't always wrap) === mw|out is now known as mw === FreeNode is now known as herb === mrevell-lunch is now known as mrevell [13:56] i'm using bzr to control a web application. My hosting co only gives me access to the webspace by ftp. Can I use bzr to push changes up to the hosting space? [13:57] VSpike: yes. You can push over ftp. [13:57] i tried "bzr init ftp://user:pass@hosting.com" but I get an error "File exists: '/.bzr': 550 /. bzr: access is denied" [13:57] VSpike: that doesn't look good. [13:57] I'm using bzr 1.2.0 on Windows [13:58] VSpike: also, bzr will not create a working tree on the ftp server, so I don't think it will do what you want. [13:59] VSpike, and also, it will have the bzr repository online, making it easy to download the source [13:59] VSpike, we are working an a plugin to tackle the website-uploading workflow [13:59] so keep an eye out for it ;) [14:00] bueno the whole source is always in the webspace anyway, and I can specifically block access to .bzr [14:02] Hmm I don't think even rsync can do ftp [14:02] rats [14:03] VSpike, right, well, you still have the working tree issue, which is the actualy files [14:03] but, again, a solution to that is very close by [14:03] just not today [14:04] I'm not sure i understand the working tree issue? [14:04] VSpike, the working tree is the actual files [14:04] The "bzr push" will only push the repository part, i.e. stuff under ".bzr". [14:04] so when you push, you just send the repository files, which are the ones under .bzr [14:05] ah right [14:05] VSpike, so you would need ssh access on the other end to do this now [14:05] (if you're willing to block the .bzr directory via htaccess or something) [14:06] Understood [14:06] Timestamps never seem to match either so probably the easiest/safest thing to do it use a sledgehammer and just write a script to ftp everything up [14:07] VSpike, right, at the moment [14:07] okay. thanks! [14:07] Any ftp mirroring tool should be able to do the job. [14:07] (I'm personally doing php magic to do it on top of bzr, but that's not available yet either :p) [14:07] Is this stuff convered in the FAQ? Because it's sure as heck a FAQ in here. [14:08] Oh, and while we're talking about timestamps, was it a conscious design decision for timestamps in working trees not to match the timestamp of the files last revision? === thumper_laptop is now known as thumper [14:09] awilkins, we're aiming at solving the actual problem, so I suppose a FAQ wouldn't make any sense at the moment [14:09] I seem to recall there being a bug on the file-timestamp issue; don't know the status, though. [14:10] awilkins: What are they instead and what case are you thinking of? [14:10] I find the timestamp thing annoying because my tree compare tool is time sensitive [14:10] LarstiQ: The timestamps are "time of writing to disk" from the build phase [14:10] awilkins: ah right, so clean checkout you mean. [14:11] LarstiQ: Yup [14:11] awilkins: Doesn't sound like a desing decision, but rather a bug I think. [14:11] It feels like a bug to me :-) [14:11] ALthough AFAIR it's optional behaviour in TSVN... I'll look at the settings dialogue [14:11] Of course, in a distributed system, using the "commit time" for file timestamps could lead to clock skew related problems. [14:12] Yech, there is that [14:12] Ok, it's optional default to "off" in TSVN [14:13] But I find myself comparing local file trees a lot more with bzr because branching is much more frequent [14:14] Out of interest, which timestamp-sensitive tree compare tool are you using? [14:14] Beyond Compare 2 [14:15] awilkins: any chance that could use bzrlib? [14:15] It has a rules-based compare as well, which gives more accurate results, but it still marks the "newer" file if they are different [14:15] awilkins: timestamps are not set to time of last revision deliberately [14:15] awilkins: /away [14:16] Would you be against an option to do so? [14:16] awilkins: without a good reason, yes. :). We do have an open bug that the times should all be identical [14:18] Is this because it's expensive to determine the last revision of individual files? [14:19] Oh, anyone who does BzrGtk here? [14:19] I've never used "Beyond Compare", but according to http://diablopup.blogspot.com/2007/07/product-recommendation-beyond-compare.html it would seem that it has an "ignore timestamp differences" option? [14:19] awilkins, jelmer and phanatic [14:20] what did i wrong this time? :) [14:20] phanatic, bzr-gtk, apparently :p [14:21] phanatic: Nothing, I just have a suggestion to make tool shelling a bit more flexible ; I'm currently operating with a very crude custom hack so I can use my 3-way merger of choice [14:22] Using subprocess with a list of args isn't compatible because it uses an arg format that isn't MFC flavoured [14:22] I've just hacked in a custom line for the tool I'm using using a % format string, but that obviously isn't portable to anyone else [14:24] hmeland: Thanks for that, it's nice to learn new things about your favourite tools (even thought they are blindingly obvious) [14:24] awilkins: No problem, glad to help :-) [14:26] I just wish it did 3-way merge (have to wait for v3 to do that....) [14:41] awilkins: several reasons. [14:42] awilkins: one is that different machines have datestamp skew [14:42] awilkins: another is that datestamp of commit is not sufficient to ensure correctness for build systems it in fact makes things worse than what we do today) [14:42] Yes, I can see that too ; different platforms with different timezone behaviours too. [14:43] awilkins: that too [14:43] * awilkins curses Win32 for having stupid TZ behaviour and has for many years [14:44] Do the dates in bzr try to be UTC internally, btw? [14:46] awilkins: they are in local time + timezone [14:46] Ng: want to stab loggerhead btw? [14:46] lifeless: sure [14:47] awilkins: anyhow, what would settingthe datestamp for you buy you? [14:47] lifeless: done [14:47] lifeless: the red "newer" highlights in my compare tool would be on the right side [14:59] awilkins: ah; so the tool is broken ? :> [14:59] well, if it's just a general tree compare tool, where else would it get the information from? [14:59] LarstiQ: newer from datestamps is inherently meangingless in the presence of diff & patch [15:00] awilkins: a plugin to 'reset' a tree timestamp state should be easy enough to write [15:00] lifeless: I thought the same myself [15:01] lifeless: "newer" has value if you are (e.g.) uploading content to an FTP with limited bandwidth and youre target FTP server does not support CRC [15:06] New bug: #103199 in bzr-gtk "diff window should not block typing in gcommit" [Medium,Fix released] https://launchpad.net/bugs/103199 [15:18] igc: I'm pretty happy with the 'mirror' command available at https://code.edge.launchpad.net/~daniel-thewatkins/bzr-mirror/mirror.dev . If you want to have a play around with it and give me some feedback, that'd be good. :) [15:36] New bug: #118461 in bzr-gtk "symlinks not handled correctly" [Low,Confirmed] https://launchpad.net/bugs/118461 [15:36] New bug: #120524 in bzr-gtk "Fold arrow in commit dialog serves no purpose" [Low,Fix released] https://launchpad.net/bugs/120524 [15:42] New bug: #120526 in bzr-gtk "Not possible to specify an external diff viewer to use" [Low,Confirmed] https://launchpad.net/bugs/120526 [16:28] Verterok, https://bugs.launchpad.net/bzr/+bug/86652 [16:28] Launchpad bug 86652 in bzr "commit option to set revision properties" [Undecided,New] [16:29] would your patch fix that? [16:36] Peng: ping [16:38] beuno: No, that only supports registering custom revision property displayers if we're talking about the same patch [16:38] beuno: nope, I'm working on showing the properties [16:38] jelmer, right, but that would be a start, wouldn't it? [16:38] jelmer: thanks ;) [16:39] * beuno pokes ponders asigning the bug to Verterok [16:40] * Verterok hides, and run away :) [16:40] * beuno stops bug triaging and goes back to coding [16:41] beuno: but I can put some time in adding the option, but I need someone to review my code [16:41] New bug: #131471 in bzr-gtk "bzr gconflicts outputs error messages when pushing green button and no files are in conflict" [Low,Fix committed] https://launchpad.net/bugs/131471 [16:41] New bug: #199513 in olive "gcommit crashes: ERROR: dbus.exceptions.DBusException" [Undecided,New] https://launchpad.net/bugs/199513 [16:41] Verterok, right, just kidding (not really) [16:42] beuno: I actually think #86652 would be a bad idea [16:42] beuno: I've just commented [16:42] ok [16:46] New bug: #147011 in bzr-gtk "[viz] date format is too verbose" [Wishlist,Fix released] https://launchpad.net/bugs/147011 [16:53] hello [16:54] squashing bugs is fun [16:55] i have a problem: i and another developer use launchpad+bazaar for the code. now he did some changes and pushed them as revision 11. i did some changes, too, and so i committed by own changes in my own branch and then merged his and my changes together. but after pushing it to launchpad, his revision disappears and is replaced by my revision. what's wrong? :) === mrevell is now known as mrevell-post-box [16:56] fredreichbier: It didn't disappear but is merged in, have a lookg at bzr log, it should show his commit indented [16:57] right, but it disappeared in launchpad [16:58] fredreichbier, well, launchpad doesn't show sub-revisions [16:58] you will probably see it with "code browse" [16:58] jml, ^ :p [16:58] ah [16:59] ah yes in 'browse code' it's visible. thank you :) [16:59] fredreichbier, welcome [17:07] jam, https://code.launchpad.net/landscape == no code. I'm I looking in the wrong place? === mrevell-post-box is now known as mrevell [17:21] New bug: #199527 in bzr-gtk "viz tracebacks when refreshing on an uncommitted and recommitted branch" [Undecided,New] https://launchpad.net/bugs/199527 [17:23] how would i uninstall bzr 1.2 if i installed it from source (ie. python setup.py install) into the default directory? [17:24] tro: in what OS? [17:24] linux [17:25] tro: as root? [17:25] i have bzrlib in /usr/lib/python.2.5/site-packages [17:25] ya [17:25] rm bzrlib, and the bzr executable [17:25] that's all [17:25] o ok. thanks [17:25] tro: manually remove the bzrlib directory there + bzr executable + bzr manpage -- that's pretty much all i guess [17:25] Odd_Bloke, would you take a look at: https://bugs.edge.launchpad.net/bzr/+bug/190512 [17:25] phanatic: thanks [17:25] New bug: #199539 in bzr "plugins command crashes complaining about "verbose"" [Undecided,New] https://launchpad.net/bugs/199539 [17:25] Launchpad bug 190512 in bzr ""bzr: ERROR: No such file" on bzr push" [Undecided,New] [17:25] it might be realted to the bug you just posted [17:26] man, you'd think setup.py would be able to record where it installed the files and have an "uninstall" command or something [17:29] tro: That's what your package manager is for. :) [17:30] Odd_Bloke: yeah, i guess. i wonder if checkinstall can handle setup.py installations [17:31] tro: as far i know it can [17:38] Anyone know if the capability for symlink on Vista (NTFS 6) has shown up in CPython? [17:38] Verterok: beuno: ISTR https://bugs.edge.launchpad.net/bzr/+bug/199539 being something to do with xmloutput. Am I just inventing that? [17:38] Launchpad bug 199539 in bzr "plugins command crashes complaining about "verbose"" [Undecided,New] [17:40] Odd_Bloke, I'd like to go for the "inventing" bit, but I can change my mind if you point me to what makes you think that [17:41] Odd_Bloke: thanks, the xmloutput it's fixed, maybe it's a old version? [17:41] * awilkins discovers that symlinks for Vista have not shown up yet [18:12] i had asked this a while back but is it possible with bazaar to branch from one remote tree to another remote tree without going through the local machine [18:12] e.g. can i branch from a launchpad tree to another launchpad tree without first downloading the first tree and reuploading it [18:13] batoms: You could probably do it if you had ssh access to the target machine, but otherwise, no [18:15] How does run the tests from inside a python console? [18:15] * awilkins is testing IronPython to see how lacking it is to run BZR [18:15] awilkins: os.system('./bzr selftest')? ;) [18:16] awilkins: I think we looked at IronPython yesterday and got a bit scared at the differences. [18:16]