[00:27] morning [00:56] lifeless: for landing lp:~spiv/bzr-pqm/submit-relock, which has 1 new rev, do you prefer a direct push to lp:bzr-pqm, or merge+commit in a checkout? [01:05] hi spiv, all [01:06] spiv: if the lhs ancestry is unchanged I don't care [01:06] spiv: besides, its jams code ;P [01:08] lifeless: ah :) [01:17] spiv: are you lunching with us? [01:18] lifeless: hmm! [01:18] lifeless: I think I will. [01:23] poolie: if you want to tell RAOF spiv and I the alternate venue you have in mind, please do so [01:25] brb brekfast [01:39] lifeless: i don't care where it is as long as it's some specific place [01:39] the link in your invitation points to 6 different restaurants [01:47] poolie: what link ? [01:48] you sent an invitation whose 'where' link points to the set of all chinese restaurants in st leonards :) [01:48] poolie: anyhow, how would you describe the generic asian on the east side of the station [01:48] now i know what you mean [01:48] hmmm, I thought i said 'station' rather specifically [01:48] oh no, I didn't [01:49] because google calendar failed and I had to retype [02:21] I was planning to just turn up at the station in an hour and a half and hang around looking awkward until someone noticed me ;) [02:21] Hm. That reminds me. Who's got my copy of /A Bit of Fry and Laurie/? Is it you, spiv? :) [02:22] RAOF: It is [02:22] RAOF: I was thinking today would be a good opportunity to return it :) [02:23] Superb! [02:37] :) i like that, but i have my own copy [02:38] * igc out for a few hours [03:31] igc, do you need anything from me atm re doc builds? [04:00] I am looking for an authentication/control mechanism for bzr that (1) uses PAM for authentication, (2) controls access to individual files by file level permissions (r-w-x), (3) does not require public key infrastructure (but rather uses passwords for authentication), and (4) restrictions directory navigation to files contained in a designated "root directory" (or a subdirectory). ssh+bzr with BzrAccess seems to be applicable [04:00] on all accounts except (3), and plain old bzr+ssh can't give me (4). Any other options to get all four requirements? [04:09] What do you mean by "individual files"? [04:11] fullermd: chmod/chown, basically. native Linux file permissions coupled with PAM's user database provide (1) and (2) exactly, built-in, so anything that hooks into that system (such as ssh) will immediately benefit from it. That's why I'm hesitant to give up bzr+ssh at all, but I don't want to have to pull in PKI just to get the benefits of BzrAccess (namely, (4)) [04:12] Right, but I mean what "individual files" do you want to control access to? [04:12] Are you talking about individual files within a branch? [04:13] in a practical sense, what I'll probably do is have a root directory containing N project directories. Each project directory will be controlled by potentially different people, with o-x permissions so that people who don't have the right user or group can't go snooping in there. [04:13] Everyone should be able to access and view the contents of the root project directory, but not necessarily the sub directories unless I've specifically set the permissions that way. [04:13] which is how linux file permissions work anyway [04:13] but within a given project, I expect all the permissions to be exactly the same [04:13] in practice, anyway [04:15] Well, you can do 4 with a chroot, as long as you have enough in the chroot to run bzr. [04:16] yeah, I was thinking of doing that, but I'm not sure exactly what bzr needs to run, and I don't know of a convenient way to capture exactly (and only) the files needed. [04:17] I don't necessarily want to enable these users to login to a bash shell over ssh though, I just want them to be able to use bzr itself for official bzr operations on files within the repository. so for example they shouldn't be able to overwrite a file in the chroot's /usr/bin, or set something executable and exec() it. [04:17] Well, python and bzrlib should be enough. You drag in some extra deps for client-side sftp support, but you don't need that there. [04:18] If they have permissions to overwrite files in /usr/bin, chroot or otherwise, you need to rethink your life :p [04:18] well, true [04:19] i guess the latter part of that sentence is more sobering than the former. so, say, they have rwx permissions within a project directory they own. if they can exec a shell, they can create an arbitrary executable file in there and exec() it. Can they potentially do that with bzr being the command ssh invokes as their shell? [04:19] It's very hard to absolutely lock things out. Hard enough that I always assume it's impossible and work from that. [04:20] Probably. I can dream up ways (at a high level) it could be made to happen, and dream up ways of shutting those doors to prevent it. [04:20] But I would never assume I could think of every dodge. [04:21] If you can mount all the FSen that are writable noexec, and not have anything that could function as a command interpreter... nope, too late, there's python. [04:22] Hmmm... this is a problem shared with git. It's just a normal UNIX-y binary on the system, and authentication/network transparency is left completely up to the sysadmin. I really wish there were a way to lock this down as well as 99% of the other services out there. I mean, I don't typically worry about people who can HTTP GET from Apache being able to invoke a shell and exec() stuff. [04:22] Well, you could do bzr+http. [04:22] But you're still talking to bzr on the server. If you can manage to get a plugin in place, you could make it do anything. [04:23] Only way to absolutely lock it out would be dumb server. Dumb servers suck though. [04:27] What is the best practice, then? I assume people who connect to Launchpad over bzr+ssh to do their (free) open source commits are in a different group than the list of people Canonical trusts performing arbitrary fork/exec on their servers. So what's the catch? [04:27] Launchpad is a whole different ballgame. [04:28] It runs a custom ssh server, and talks to a completely virtual filesystem. [04:28] I know, but Launchpad hosts bzr, and somehow they do it in a secure manner. [04:28] oh, I see. [04:28] very interesting. [04:28] that's kind of nice. since Launchpad is (recently-ish) open sourced I guess I could deploy that on my own box and have a more robust system all around. [04:29] The code is available, so you could potentially grab those pieces out of it and try working from there if you wanted. [04:29] Presumably it would be easier than trying to get the whole thing running, which I understand is a bear. But maybe not. [04:30] yeah -- actually I wouldn't mind deploying the entire Launchpad on my box. We have a very small dev team (3 people) so I'm not sure how useful all the wiki/bugtracking features would be, but it would be nice to have them. [04:30] Yeah, I handle those issues with my co-developers in totally different ways. [04:31] Specifically, I know where they live, and I'm better armed than any of them. [04:31] I long to have the project I'm working on open sourced, but unfortunately we're still being bitten by licensed code from the 90s. Long story. Short version: closed source freeware. [04:32] And with not having a budget of $250/year, we can't go launchpad commercial. [04:32] With a public system (like LP), you definitely need to lock down hard. But with a small dev team like that, I'd just rely on them not being retarded or evil (and deal with those cases by a bootoff) [04:33] I mean, if they're likely to go to moderately extreme lengths to do something evil, you wouldn't be letting them have access in the first place, neh? [04:34] well, yes, I can definitely trust the two other people who have access to a fairly good extent. I do want to make read-only accounts for testers within the community (who are not developers) but if I'm willing to give someone write access to the source code, I'm also willing to trust them with exec() powers on the system. [04:34] Oh, that's plenty easy. [04:34] I guess I was being a little overzealous in that regard, actually. The people who _really_ shouldn't be exec()ing anything on the system will not have access to it at all, except for public http of webpages. [04:34] Just setup read-only bzr+http. Easy peasy. [04:35] Assuming bzr doesn't itself have a hole allowing access (hard-to-impossible to prove, but a reasonable base assumption), the only way somebody with RO access like that could do something evil[er than DoS] would be with inside help. [04:36] Perhaps a requirement easier to satisfy, then: instead of (for read/write access) going to a URL like bzr+ssh://user@server.com/path/from/root/filesystem/to/bzr/repos/my_project, how about a way to shorten it to bzr+ssh://user@server.com/my_project ? [04:37] BzrAccess _can_ do that, and so can chroot, but they both have rather burdensome baggage that's part of the game. [04:37] * fullermd shrugs. [04:37] I'd just toss in a /repos symlink and call it a day. [04:37] oh, that works... why didn't I think of that :P [04:37] Or use home-relative paths, and setup users home dirs appropriately. [04:38] bzr+ssh://user@server/~/mybranches/... [04:38] (possibly with the two combined; symlinks in the homedirs) [04:38] You need a relatively recent version for the ~ over bzr+ssh. 2.1 maybe? Or was that in 2.0... [04:38] 2.1 looks like. [04:38] yeah, I read the release notes mentioning the ~ syntax [04:39] we are using 2.1 so that's fine [04:39] Technically, I think that's all server side, so a pre-2.1 client may still work fine as long as the server is 2.1. [04:42] fullermd: Thanks for the help. I'm not at all upset that there isn't any whiz-bang solution to my original query. I might be able to live with the /repo symlink, since I do trust the SSH users after all. [04:42] I needed more conceptual help than technical it seems ;) [04:43] I'm always in favor of insane overengineering. But in general, not always in specific :) [04:57] I [04:57] I'm at a client, where [as I mentioned] I saw the Git book. They're Subversion right now, and going to switch to Git on the strength of: [04:57] NGO? [04:58] 1. perception that more people have Git skills [04:58] 2. perception that IDE integration (IntelliJ + Eclipse) is better [04:58] there was no real interest in technical argument about Bazaar's superiority (or inferiority, or anything else). It was really "I can hire guys who already know Git" [04:59] Nobody ever got fired for buying IBM. [04:59] If any Canonical people are in the room, I can pass on the name of this Engineering Manager, but I'm not sure anyone at Canonical is making sales pitches to small medium business. [05:00] But as a more general comment, it sounds a lot like the "you should switch from {Windows,Solaris} to Red Hat because" that is what RH sales & marketing does for a living. [05:01] [with some success, I gather] [05:01] and perhaps we as the Bazaar community are going to need to chip in on a well co-ordinated campaign along the same lines. [05:02] Said engineering manager also said "VHS vs Beta" [05:03] which is scary because that meme "justifies" the choice of an inferior product based on perceived market adoption, and I'm VERY worried that's going to get hung on Bazaar [05:12] if I branch lp:/project-dev to ~/project, can I then point ~/project to lp:/project? [05:13] What do you mean "point to"? [05:17] fullermd: I'd like to change the repo from lp:/project-dev to lp:/project [05:18] fullermd: does that help? [05:18] That... doesn't make any sense. [05:18] Do you mean you want to change the _parent_ pointer? [05:19] I think so [05:19] The repo is in ~/project (or maybe ~/, or ~/../, etc, but probably not) [05:19] You can use 'pull --remember' to set the parent. [05:19] It sounds a little XY-ish, though. [05:19] What are you trying to _accomplish_ by this? [05:20] allow people who are using out dev branch to upgrade to our non-dev branch [05:20] without having to wipe the files from their local dir first [05:21] So, the equivalent of `rm -rf ; bzr branch lp:project` without all the re-copying. [05:21] yeah [05:21] exactly [05:21] Something like `bzr pull --overwrite --remember` will mostly do it. [05:21] killer [05:21] Of course, if they have pre-existing push locations or the like, that won't change them. But presumably they'd still be correct. [05:22] --remember is needed to reset the 'parent' pointer; otherwise it'll stay at the old one, and just use the given location for THIS pull, not future ones. [05:22] ahh, ok, good to know [05:22] --overwrite makes it throw away anything that's not part of that new branch, which is what you'd want for switching from one to another. [05:22] (not if they have local work on top of the branch to be preserved, though) [05:22] fullermd: exaactly what we need [05:23] good to know [05:23] i'm new to version control (that's probably obvious). bzr is amazing. *so* much betetr than svn [05:24] The benchmarks page is slightly out of date and I would like to update it. I have a script that will run the benchmarks and generate the output table. Who should I contact regarding this? [05:24] cakoose: I think igc might have been the last person to do much work there? [05:25] fullermd: thanks for your time [05:25] igc: ^^ [05:35] igc: I'd like to update the benchmarking page. fullermd tells me you might be the one to talk to about this. [05:37] cakoose: if igc isn't around at the moment, try the mailing list. igc (among others) will see it there. [05:38] spiv: k, thanks [05:49] back [05:50] hi cakoose: you're very welcome to update the benchmark page [05:52] He just snuck out on ya ;) [06:11] igc can you answer https://answers.launchpad.net/bzr/+question/107463 [06:12] poolie: sure [07:26] hi all [07:29] * fullermd flops at vila. [07:30] fullermd: you mean something like: _o/ \o/ \o_ ? [07:31] Oh, I didn't think it through that carefully. I just thought it would be a nice change from waving. [07:32] I only knew flop in 'megaflops', 'teraflops' and the like, so I had to look in my dictionary :) [07:32] I mostly think of it as what a fish does when you toss it on the ground :p [07:50] morning [07:51] when I add a patch from a peer to the trunk, needs the peer to merge instead of pulling the newest trunk? [08:35] hi vila [08:36] hey poolie ! === oubiwann` is now known as oubiwann [09:29] * igc dinner [10:31] Hi, if i shelved some changes, how can I see what exactly is in a specific shelved change? [10:31] radoe_: unshelve --preview [10:31] night all === radoe_ is now known as radoe [10:35] I'm a bzr newbie, id like to publish an emacs bzr branch on savannah. have anyone here done this? [10:35] kfogel probably has [10:35] Thx, and now I have to file a bug regarding the bzr crash occured while previewing my shelved changes :( [10:35] kfogel: ping [10:39] I shelved some changes, bzr unshelve --preview produces "bzr: ERROR: exceptions.UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 7: ordinal not in range(128)' [10:41] radoe: please do file a bug [10:41] What should I attach to a bugreport in addition to the crashlog? [10:41] the crashlog should be sufficient, initially. [10:41] obviously a description of what went wrong. [10:45] lifeless: got already reported as bug #518916 two months ago. [10:45] Launchpad bug 518916 in bzr "`unshelve --preview` fails with unicode error" [Medium,Confirmed] https://launchpad.net/bugs/518916 [10:45] radoe: if the backtrace is /identical/ it may be the same issue [10:45] jave: have you tried just pushing it? [10:45] jave: should work [10:46] radoe: but unicode errors can turn up from many places; I don't assume that they are the same without checking in detail [10:47] jave: lp:~kfogel/emacs/3646-bookmark-format-compat for example [10:47] jave: expanded, that's https://code.edge.launchpad.net/~kfogel/emacs/3646-bookmark-format-compat [10:53] lifeless: except for the last line where the bugreport has an additional reference to encodings\cp866.pyo the backtraces are identical. [10:54] I'll attach it to the bugreport nevertheless [11:39] kfogel: so, "bzr push sftp://jave@bzr.savannah.gnu.org/srv/bzr/emacs/imagemagick" in my case? [11:50] I tried it and it didnt complain, so maybe it worked. how do I verify it? [11:51] http://bzr.savannah.gnu.org/lh/emacs says "loggerhead disabled due to unstability; if you're interesting in maintaining it, please contact us" [11:52] ok, "bzr ls sftp://jave@bzr.savannah.gnu.org/srv/bzr/emacs/imagemagick" shows some files [12:41] jml: ping === gnomefreak76 is now known as gnomefreak [13:29] how can I remove a tag? [13:30] bzr tag --delete FOO [13:41] spiv: thanks! [13:46] can anybody answer me some questions about binary file handling? [13:47] damiro: probably :) [13:47] bialix: pong. [13:48] can bzr identify binary files? [13:49] damiro: in what sense? When merging? [13:50] no.. only to prevent line-ending conversion [13:50] Ah. [13:51] bzr doesn't convert line endings, unless you configure it to: http://doc.bazaar.canonical.com/bzr.dev/en/user-reference/eol-help.html [13:51] ahh... thats good. [13:54] so there will be no difference in handling files? [13:55] damiro, `bzr diff` won't tell you *what's* different in binary files, only that they *are* different [13:55] otherwise, they're all just files [13:57] and what about the data store... if i have a bigger binary file with 2 versions. saves bzr the delta to version 1 or the whole file again? [14:02] jml: I saw your new article and want to ask about its title [14:03] damiro: it saves a delta [14:04] thats fine :-) [14:04] The deltas are optimised for text files, but work ok for binary files. [14:05] (Assuming that the versions aren't completely different, of course... some binary file formats tend to produce completely unrelated-looking bytes after minor edits) [14:07] in my case it will be media data, mostly png and wave.. [14:07] Hmmmmmm [14:07] bialix: yes it is from The Big Lebowski :) [14:07] I'm trying to roll back to an earlier revision. I have 79 revisions in branch. bzr up -r75; bzr revo => prints 79 [14:07] so... how do I see what the revno of the checkout is.. rather than the top in the branch? [14:11] LeoNerd: revno --tree [14:12] Ah [14:13] ok.. thank's a lot, spiv and IslandUsurper [14:23] damiro: you're welcome [14:31] anyone have a neat way with the API to find the earliest mainline revision to merge a specific revid? [14:32] branch.iter_merge_sorted [14:32] so I have revision A and revision B, and want to find the earliest revision in revision A's left-hand ancestry that has B in its ancestry [14:34] that looks overly expensive for this job [14:35] james_w: I'm not aware of anything better other than jams history db, at this ponit. [14:35] ok [14:37] it seems to me that if I walk through revision_history() and find the first revision to answer no to is_ancestor(B) I will have it === bialix_ is now known as bialix [14:40] [a for a in branch.iter_merge_sorted_revisions(start_revision_id=A, stop_revision_id=B, stop_rule='include', direction='forward') if a[1] == 0][0][0] by my reading of the docstring [14:41] james_w: is_ancestor is about as expensive as list(iter_merge_sorted_revisions) but you'd be calling it *per* ancestry point [14:41] ok [14:42] james_w: thumper recently landed code in lp to do precisely what you're wanting to do [14:42] james_w: something like that comprehension, yes [14:42] its too late for me to bend my head completely around though [15:23] pqm fails to send mail on failures ? [15:28] vila: I think there is a suspicion that the output exceeds some limit now [15:29] due to the extra information in the subunit stream [15:29] yeah spiv mentioned it a couple of hours ago, but *where* is it failing ? At the sending site ? At some intermediate one ? [15:30] james_w: are you still working on your ancestry check ? [15:30] I've got something coded now, working on tests [15:30] ok [15:30] my guess would be postfix on the pqm box [15:30] but it could be anywhere in between I guess [15:31] lifeless: hi [15:31] lifeless: are you debugging something with PQM? [15:31] jelmer: \0_ [15:31] jelmer: I think he said it in one of its mails :) [15:31] s/its/his/ [15:32] ah, I see now [15:32] Just saw a bunch of emails [15:32] yeah, me too, weird, especially since *I* didn't get mails for my last submissions which failed ;) [15:35] james_w: one of the losas could verify that for you [15:36] Ha, silly me, losa ! Gimme a losa ! [15:38] vila: hi let me look at you [15:38] heh [15:38] vila: look behind you! [15:38] Chex: Hi ! So, it seems pqm failed to send me an email after a failed subsmission [15:38] james_w: same wall as usual ;-) [15:39] Chex: twice in fact [15:39] vila: hmm, interesting. [15:39] Chex: no, scratch that, the second one has not failed yet, it's still running ! [15:40] Chex: but it's almost the same merge and already mentions an error at http://pqm.bazaar-vcs.org/ [15:40] so it *will* fail [15:40] vila: test_no_conflict_marker.py, yes? [15:40] vila: is yours? [15:41] Chex: no, Merge 2.1 into bzr.dev including fixes === mrevell_ is now known as mrevell [16:30] dang lifeless, you really know how to spam the review queue.... [16:31] morning vila [16:31] morning jam, yeah, let's hope he *is* awake :) [16:32] well, he apparently just set the thing back to Queued, and I don't think that would be a bot would it? [16:32] I just set it to WIP [16:32] james_w: well, it is cycling, and I don't think Lifeless is awake [16:33] jam: I don't think it's cycling, there are tiny differences in the error messages the last one being being about a module without exit defined [16:33] and now it's back from WIP to Approved [16:33] perhaps, but 20+ messages is a decent threshold if he isn't actively processing it [16:34] Main problem is that bots act as users [16:34] so you can't tell *who* is actually doing the action [16:34] I bet he is awake :) [16:36] Of course, having to manually subscribe to a branch so I can say I don't want email is a bit weird, too [16:36] And since I've commented on the mp, I don't even know if that will work [16:39] lifeless: go to bed and stop spamming my inbox :) [16:41] jam: you know when you're at the final stage of getting something done [16:45] jam: I'm done now; the frankenbeast is working [16:45] I was menaing to be asleep 2 hours back. argh. [16:45] jelmer: queue position - not new, but newly used. [16:47] lifeless: ah, ok [16:47] lifeless: what were you trying to get working? [16:47] lifeless: just trying to fix a PQM bug or is this new fancy stuff? === deryck is now known as deryck[lunch] [16:49] jelmer: he's working on a cron script [16:49] so you can mark a mp Queued [16:49] and it will land it for you [16:49] or block it, I assume [16:49] ah, neat === beuno is now known as beuno-lunch [16:51] it's great to finally see stuff happening in pqm again [17:19] he was awake, I won :) [17:25] ui.note() doesn't support unicode, does that ring a bell ? [17:28] not to me.. === IslandUsurper is now known as IslandUsurperAFK [17:35] Anyone have any experience/opinions re: bzr-eclipse vs qbzr-eclipse? Is one proj more-active / recommended than the other? [17:38] is there a trick to using svn+ssh:// on windows? I used the 2.1.1 standalone installer, and I keep getting: [Errno 2] Can't create tunnel: The system cannot find the file specified (on a pull) [17:38] Tak: it's having trouble finding the ssh executable [17:38] Tak: I'm not sure what the best fix is exactly [17:39] hmm - doesn't it use paramiko? [17:39] Tak: no, since bzr-svn just calls out to libsvn [17:39] Tak: and that's written in C and needs to call a SSH executable [17:40] oh, ok [17:41] trying http://agateau.wordpress.com/2007/07/03/windows-svnssh-and-the-subversion-command-line-client/ === deryck[lunch] is now known as deryck === IslandUsurperAFK is now known as IslandUsurper [18:22] jam: what encoding should ui.note() use IYHO ? [18:24] vila: trace.note uses utf-8 [18:25] ui.note() should take Unicode [18:25] and the ui_factory should determine what encoding to use [18:25] ideally, TextUIFactory would use sys.stderr.encoding [18:25] probably osutils.get_terminal_encoding() [18:25] however, we've historically had lots of problems with that stuff [18:25] so... meh [18:26] that's the suprising part in bug #563997 ... that we didn't encounter the problem sooner [18:26] Launchpad bug 563997 in bzr "ui.note doesn't support unicode" [High,Confirmed] https://launchpad.net/bugs/563997 [18:27] vila: we rarely use ui.note() vs trace.note() [18:27] and the latter has currently been hard-coded as utf-8 [18:27] ha, good point [18:27] *I'm* pretty surprised to see that ui.note() is going to stdout, rather than stderr === beuno-lunch is now known as beuno [18:31] jam: well, the problem will be the same [18:32] I was about to add a msg = msg.encode(osutils.get_terminal_encoding(), 'replace') but I realized that this isn't cached... and could be quite costly to call for each note() [18:35] vila: in other places we set up the output file at one point, and then use it repeatedly from there [18:37] yeah, I guess I could cache it __init__ anyway since different ui objects will be used, there is no way to change stdin/stdout/stderr (other than accessing the attributes dirrectly...) [18:55] jam: hmm, looks like the truth is elsewhere, bzrlib.tests.TextTestResult is using ui.note, but I see no good reason for this (may be to avoid calling ui.clear_term() explicitly...) [18:56] jam, vila: How do we cope with the lack of atomic renames in bzr exactly? [18:56] jelmer: osutils.fancy_rename() [18:56] generally, we fake it [19:01] How do I get a file back that has been removed from version control? [19:01] When I do `bzr cat -r` with an old revision it says its no longer under version control [19:02] When a file gets removed from bzr, are all traces gone after that? [19:02] try reverting that file to a good revision [19:02] I'm surprised cat didn't work though [19:03] I think cat may look at the current tree to find the file. [19:03] revert is the better answer anyway though. cat/add won't resurrect it, it'll make a new file. [19:05] I tried using `bzr cat -r someOldVersionThatWasGood` and it didn't work [19:05] It says its not versioned anymore [19:05] krisives-gearbox, use `bzr revert -r xxx filename` [19:07] IslandUsurper: I tried that too, it's saying this: [19:08] hello [19:08] bzr: ERROR: u'administrator/components/com_fpslideshow/configuration.php' is not present in revision stoysnet@hostedbycorephp.com-20100412210927-21s7b7c2ftm709um [19:08] does anyone know if dulwich 5.1+ is available anywhere? [19:08] Why is the revision name so long, I don't remember seeing that before [19:08] erm, 0.5.1 [19:08] all i can see is 0.5.0 [19:10] krisives-gearbox: Well, that's the name of the revision :) [19:10] krisives-gearbox: Are you sure the file did exist in that rev? [19:10] How can I see the name of the revision? [19:12] Adding --show-ids to log will show the revids. But you can use the revnos just as well; it doesn't matter for what you're doing. [19:16] I think this was caused by FTP and `bzr update`. I always use SFTP, can anyone give me a heads up on how FTP and `bzr update` work / [19:54] When I remove a file from version control, how can I make sure that file doesnt get deleted later when I do a pull/push ? [21:56] http://stackoverflow.com/questions/2648362/remove-files-from-bazaar [22:01] krisives-gearbox: this sounds like a bug, please file it at https://bugs.launchpad.net/bzr/+filebug [22:01] vila: Really? Not arguing, but it's a bug? [22:02] krisives-gearbox: well, at least the bzr behaviour doesn't match your workflow [22:02] Is it supposed to be default to have it delete the files/ [22:02] One can argue that you want your cake and eat it too (don't version it, but please keep the last version of the file in place) [22:03] yes it is, that's what you want generally: a versioned tree should be recreated as it is versioned and if you get new versions you want the tree to be updated [22:03] I can't think of a good way to address your workflow but may be others will have better ideas [22:04] krisives-gearbox: in the mean time, you should advertise how to restore this file to your users [22:05] krisives-gearbox: bzr revert -rxxx file [22:05] We're trying to version many clients, so that's not a possibility right now [22:05] Another problem is that `bzr revert -r SomeVersion file` says it's been removed from version control, so we end up having to do a hunt for the last version that it was versioned under (which could be 20+ revs ago) [22:06] krisives-gearbox: one thing I don't get is how would a new client start from a recent version ? [22:06] krisives-gearbox: where will the file be coming from ? [22:14] The scenario is that they have a lot of existing clients that don't have any kind of version control [22:15] We've version controlled the development and testing sites [22:15] To version the clients I'm copying the .bzr directory to the client site, which gives me a way to see what all the changes are when I do a `bzr status -V` or in text editor when I use `bzr commit` [22:16] ok [22:17] someday I'll learn how to sleep in after a late night [22:17] but not today [22:18] * vila is not sure to agree :) [22:19] thumper: ping [22:30] jelmer: i just encountered bug #413113 in bzr-svn 1.0.2 [22:30] Launchpad bug 413113 in subvertpy "SubversionException: ('Svndiff contains a too-large window', 185001)" [High,Fix released] https://launchpad.net/bugs/413113 [22:30] dash: what version of subvertpy/bzr-svn are you running? [22:30] subvertpy 0.6.8 [22:31] bzr-svn 1.0.2 [22:31] dash: see that bug report [22:31] dash: that bug was fixed in subvertpy 0.6.9 [22:31] jelmer: hup! i am blind [22:31] jelmer: i read that as bzr-svn 0.6.9 [22:31] thank you. ;) [22:31] ah, heh [22:35] jelmer: that works, of course [22:35] jelmer: btw thank you, bzr-svn has made my life significantly less frustrating at work [22:37] http://www.platocafe.co.nz/ [22:37] damn [22:37] up arrow [22:37] lifeless: pong (but on a call) [22:42] thumper: hey great. [22:42] thumper: who can set merge proposals to 'Queued' [22:43] thumper: also check out the latest commits to lp:pqm [23:05] dash: happy to hear it :-) [23:13] thumper: so, yo [23:13] lifeless: still on a call [23:13] ok [23:31] lifeless: I believe that the owner of the target branch can mark something queued, or the owner of the merge queue [23:32] lifeless: merge queues aren't exposed yet through either the web ui nor api yet [23:32] thumper: its definitely more than the target branch owner. [23:32] lifeless: if the proposal has been approved, then I think it is anyone with launchpad.Edit on the proposal [23:32] thumper: perhaps I'm in the merge queue owner group though; are there implicit queus for series ? [23:32] lifeless: I'd really have to take more of a look [23:33] thumper: I guess what I really mean is, 'how can I tell' ? [23:33] but both rockstar and I would like to see the feature finished off [23:33] lifeless: read the source is the only way [23:33] thumper: ok, where should I start [23:33] * lifeless fires up the lpdev vm [23:34] thumper: yes, I know its not finished and you want to finish it. [23:35] lifeless: if the proposal is not approved, only reviewers can queue it, if it is approved anyone who can set the status can queue it [23:35] lib/lp/code/model/branchmergeproposal [23:35] thumper: I'm very happy to dogfood and deal with glitches [23:36] thumper: all going well, pqm for bzr will be lp queue enabled today [23:36] cool [23:36] thumper: I just need to figure out if I'm opening a huge gaping security hole [23:36] lifeless: the whole is no bigger than pqm currently is [23:36] or whether the lp permissions model is close enough to what we do in the config file today. [23:37]