[09:08] oh, hi all ! [09:36] morning all [09:37] hi mgz, vila [09:38] _o/ [09:39] hi everybody! I'm trying to understand the "remove-branch" command, and fail to see its purpose. My goal is to "retire" some remote branch, after it was merged in trunk and thus not anymore "active"... [09:39] trying that command, I see it apparently deletes only the .bzr/branch subdir of the branch... [09:41] given that the remote branches are in a "shared" repo (for a given user), is it safe to simply "rm -rf" the single branch, or does that corrupt the shared repo in some way? [09:43] lelit: it's safe. [09:47] great, thanks. OOC, do you know the purpose of the remove-branch command? when is it useful? [09:57] lelit: not removing remote workingtrees with it is arguably a bug. mostly it rmbranch does just boil down to rm, the command exists so there's a consistent interface for different branch schemes [09:58] I see, thank you [11:13] I bet half these bzr-explorer file watcher bugs are just from accidentally including .bzr in the followed paths [11:13] which then clashes with bzr trying to do internal work there at the same time [11:15] mgz: be bold, bet on the other half ;) [11:24] the rest seems to be other misc locking/permission failures - some IDE holding files open, etc [11:26] woho! failures. [11:53] is there a way to get merge to not set the submit branch on things? [11:54] I do too much editing of .bzr/branch/branch.conf as it is, and I merge sideways more than up. [11:57] btw, a coworker yesterday asked me the difference between "submit-branch" and "push-branch", and I didn't find a satisfactory answer... [12:28] mgz: --no-remember [12:29] lelit: push_location is where push goes, submit_branch is where you merge from (the assumption is that it's where you *will* submit) [12:30] thnx [12:30] mgz: also, 'bzr config --remove submit_branch [12:30] mgz: or 'bzr config submit_branch=' [12:35] ah, yes, `bzr config` is a bit easier than editing stuff in .bzr for single changes, slower when you want to nuke a bunch of stuff though :) [12:36] an option to not do it in the first place would be nice, lots of merges aren't from a submit location [13:31] mgz: 'bzr merge --no-remember ../one-shot' ? [13:34] next time I'll try and remember no remember but I doubt I'll remember [13:34] okay, end of qbzr time and start of lunch time [13:34] .. which is why the default is --remember :-P [13:49] mgz: a fun one for you: try to make a test called 'test_base_dir' succeed [13:50] mgz: rats, the missing bit is also a spoiler :-/ The test should inherit from TestCaseInTempDir [14:01] a repeat of bug 581298 maybe? :) [14:01] Launchpad bug 581298 in Bazaar "bt.test__walkdirs_win32.TestWin32Finder.test_dir fails without ever being run" [Undecided,Fix released] https://launchpad.net/bugs/581298 [14:02] oooooh :) [14:02] indeed [14:36] right, time to work out what to do with trace === tchan1 is now known as tchan === Quintasan_ is now known as Quintasan [18:03] the libvirt/qemu-kvm UDD trees on LP seem to be hosed - attempts to branch from them give an error [18:04] http://paste.ubuntu.com/762973/ [18:04] is this the right place to look for help on that? [18:04] dannf: hi [18:04] dannf: this is the right place [18:05] jelmer: cool [18:05] dannf: this is bug 848064 [18:05] Launchpad bug 848064 in Ubuntu Distributed Development "Revision not present branching from udd-imported branches on lp" [Critical,Confirmed] https://launchpad.net/bugs/848064 [18:07] jelmer: sounds like reimporting might be an option? what does that entail? [19:51] hi all [20:17] hey poolie! [20:17] hi there [20:28] hi poolie, wgz [20:36] * wgz waves at GRiD [21:08] Hi, want to check something, just to be sure: If I create a symlink, add it to the working copy and then change my mind and 'bzr revert symlink'. Then it should not delete the symlink right? [21:08] (add --> not yet commit) [21:13] I'm asking because I think it's a bug in bzr [21:24] dvheumen: No, we have special handling for files when reverting, but not for other types. If you want to unversion the symlink without deleting it, "bzr remove --keep" will do that. [21:25] abentley, then you don't consider this undesired behavior? [21:25] dvheumen: correct. [21:25] hmm... okay ... [21:26] btw, do you mean remove or revert? [21:26] dvheumen: I mean remove. [21:27] so, in the case of revert? [21:27] it seems strange to me to delete something that hasn't been under control in the first place [21:28] dvheumen: Revert tries to return to to your previous state. It doesn't consider how you got there. [21:28] yeah exactly, so why delete a symlink that was 'originally' there before I added it to the working copy [21:29] dvheumen: Because the previous state is the last-committed state, and that didn't have a symlink. [21:29] dvheumen: We do the same with directories. [21:30] but you make an exception for files then, doesn't that seem strange? [21:31] dvheumen: Even with files, the exception is based on filetype, not based on whether you added them without committing. [21:32] dvheumen: And we make that exception because deleting a file can cost the user a lot of data, whereas directories and symlinks don't contain much data in and of themselves. [21:32] hmmm... okay, in that case it's not a bug :P [21:32] (although I'm not completely sold on the reason ;-) [21:33] (yet) [21:33] thanks :) [21:36] dvheumen: The more junk you leave in the way, the more you open yourself up to conflicts later on when tree updates create an entity with the same name. [21:37] abentley, yeah, that's true. However, this symlink probably has some meaning and when I revert I would do this with a thought such as "on second thought, no I don't want to do this versioning operations". And it wouldn't occur to me that I'm actually deleting a file, changing a directory structure. [21:38] so I'm accidentally touching something that I wouldn't expect [21:38] although, maybe I should do some more reading, since it *is* reported that the symlink gets deleted [21:39] dvheumen: Sure. But there are tradeoffs here, and there isn't *much* meaning in the symlink. [21:39] yeah, I know :) [21:40] I should just get used to this behavior [21:42] anyways, you're just in time ... I hadn't yet submitted the bug report :P [21:42] dvheumen: You can also use shelve --all as an alternative to revert. That will allow you to correct any surprising behaviour. [21:42] I'll keep that in mind [22:09] hey poolie, welcome back [22:13] hi there, thanks === jelmer_ is now known as jelmer [22:41] bzr checkout; edit stuff... bzr commit --local {because the laptop was offline} [22:41] How do I now push it upstream? bzr push claims no location known or specified. I know I -can- copypasta from bzr info but that feels awkward and hackish [22:44] Ahhh.. bzr push :bound [22:44] * LeoNerd read bzr help location-aliases [23:20] hi folks. [23:20] is there any way to provide secure access to a bzr server other than via SSH? [23:21] Noldorin: over http/https [23:22] or, alternatively, if you don't require a smart server you can also use sftp/ftp, smb, ... [23:24] jelmer sftp is still ssh... but yes the other options sound appealing. how does https speed compare to smart server? [23:24] (with ssh) [23:25] Noldorin_: the smart server can be used over HTTPS as well, though it requires some setup [23:25] ah right [23:25] jelmer, but not ftp? [23:26] Noldorin_: right, it would be pretty hard to tunnel something custom over ftp :-) [23:26] yeah heh [23:26] i could imagine! [23:27] jelmer, hmm will have a look, thanks for tip [23:27] be back in a bit [23:27] Noldorin__: ssh should be simplest to setup though (hardly any setup at all), any reason you're not using that? [23:28] jelmer, alas, windows server = ssh (almost) impossible [23:28] unless some has some good tips for it [23:28] tried a lot, but always some sort of error. [23:28] hmm [23:30] openssh for windows just isn't maintained :-( [23:30] maybe there are decent commercial solutions. who knows [23:30] ah, hmm [23:30] I don't have any experience with SSH servers on Windows [23:31] yeah. not sure many in the world do :-P [23:31] you use openssh sshd on linux though yes? [23:32] Noldorin__: yep [23:34] jelmer, maybe cygwin environment then...hard for windows services though [23:34] hmm [23:35] brb restarting [23:58] jelmer, back [23:58] hi Noldorin [23:58] hi [23:58] did you have any thoughts while i was gone? [23:59] I had plenty, but nothing about SSH on Windows I'm afraid.. [23:59] heh [23:59] fair enough