[09:08] <vila> oh, hi all !
[09:36] <mgz> morning all
[09:37] <jelmer> hi mgz, vila
[09:38] <vila> _o/
[09:39] <lelit> 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] <lelit> trying that command, I see it apparently deletes only the .bzr/branch subdir of the branch...
[09:41] <lelit> 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] <mgz> lelit: it's safe.
[09:47] <lelit> great, thanks. OOC, do you know the purpose of the remove-branch command? when is it useful?
[09:57] <mgz> 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] <lelit> I see, thank you
[11:13] <mgz> I bet half these bzr-explorer file watcher bugs are just from accidentally including .bzr in the followed paths
[11:13] <mgz> which then clashes with bzr trying to do internal work there at the same time
[11:15] <vila> mgz: be bold, bet on the other half ;)
[11:24] <mgz> the rest seems to be other misc locking/permission failures - some IDE holding files open, etc
[11:26] <mgz> woho! failures.
[11:53] <mgz> is there a way to get merge to not set the submit branch on things?
[11:54] <mgz> I do too much editing of .bzr/branch/branch.conf as it is, and I merge sideways more than up.
[11:57] <lelit> btw, a coworker yesterday asked me the difference between "submit-branch" and "push-branch", and I didn't find a satisfactory answer...
[12:28] <vila> mgz: --no-remember
[12:29] <vila> 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] <lelit> thnx
[12:30] <vila> mgz: also, 'bzr config --remove submit_branch
[12:30] <vila> mgz: or 'bzr config submit_branch=<here, and nowhere else from now on>'
[12:35] <mgz> 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] <mgz> an option to not do it in the first place would be nice, lots of merges aren't from a submit location
[13:31] <vila> mgz: 'bzr merge --no-remember ../one-shot' ?
[13:34] <mgz> next time I'll try and remember no remember but I doubt I'll remember
[13:34] <mgz> okay, end of qbzr time and start of lunch time
[13:34] <vila> .. which is why the default is --remember :-P
[13:49] <vila> mgz: a fun one for you: try to make a test called 'test_base_dir' succeed
[13:50] <vila> mgz: rats, the missing bit is also a spoiler :-/ The test should inherit from TestCaseInTempDir
[14:01] <wgz> a repeat of bug 581298 maybe? :)
[14:02] <vila> oooooh :)
[14:02] <vila> indeed
[14:36] <mgz> right, time to work out what to do with trace
[18:03] <dannf> the libvirt/qemu-kvm UDD trees on LP seem to be hosed - attempts to branch from them give an error
[18:04] <dannf> http://paste.ubuntu.com/762973/
[18:04] <dannf> is this the right place to look for help on that?
[18:04] <jelmer> dannf: hi
[18:04] <jelmer> dannf: this is the right place
[18:05] <dannf> jelmer: cool
[18:05] <jelmer> dannf: this is bug 848064
[18:07] <dannf> jelmer: sounds like reimporting might be an option? what does that entail?
[19:51] <poolie> hi all
[20:17] <wgz> hey poolie!
[20:17] <poolie> hi there
[20:28] <GRiD> hi poolie, wgz
[20:36]  * wgz waves at GRiD
[21:08] <dvheumen> 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] <dvheumen> (add --> not yet commit)
[21:13] <dvheumen> I'm asking because I think it's a bug in bzr
[21:24] <abentley> 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] <dvheumen> abentley, then you don't consider this undesired behavior?
[21:25] <abentley> dvheumen: correct.
[21:25] <dvheumen> hmm... okay ...
[21:26] <dvheumen> btw, do you mean remove or revert?
[21:26] <abentley> dvheumen: I mean remove.
[21:27] <dvheumen> so, in the case of revert?
[21:27] <dvheumen> it seems strange to me to delete something that hasn't been under control in the first place
[21:28] <abentley> dvheumen: Revert tries to return to to your previous state.   It doesn't consider how you got there.
[21:28] <dvheumen> yeah exactly, so why delete a symlink that was 'originally' there before I added it to the working copy
[21:29] <abentley> dvheumen: Because the previous state is the last-committed state, and that didn't have a symlink.
[21:29] <abentley> dvheumen: We do the same with directories.
[21:30] <dvheumen> but you make an exception for files then, doesn't that seem strange?
[21:31] <abentley> dvheumen: Even with files, the exception is based on filetype, not based on whether you added them without committing.
[21:32] <abentley> 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] <dvheumen> hmmm... okay, in that case it's not a bug :P
[21:32] <dvheumen> (although I'm not completely sold on the reason ;-)
[21:33] <dvheumen> (yet)
[21:33] <dvheumen> thanks :)
[21:36] <abentley> 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] <dvheumen> 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] <dvheumen> so I'm accidentally touching something that I wouldn't expect
[21:38] <dvheumen> although, maybe I should do some more reading, since it *is* reported that the symlink gets deleted
[21:39] <abentley> dvheumen: Sure.  But there are tradeoffs here, and there isn't *much* meaning in the symlink.
[21:39] <dvheumen> yeah, I know :)
[21:40] <dvheumen> I should just get used to this behavior
[21:42] <dvheumen> anyways, you're just in time ... I hadn't yet submitted the bug report :P
[21:42] <abentley> dvheumen: You can also use shelve --all as an alternative to revert.  That will allow you to correct any surprising behaviour.
[21:42] <dvheumen> I'll keep that in mind
[22:09] <jelmer_> hey poolie, welcome back
[22:13] <poolie> hi there, thanks
[22:41] <LeoNerd> bzr checkout; edit stuff... bzr commit --local {because the laptop was offline}
[22:41] <LeoNerd> 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] <LeoNerd> Ahhh.. bzr push :bound
[22:44]  * LeoNerd read  bzr help location-aliases
[23:20] <Noldorin_> hi folks.
[23:20] <Noldorin_> is there any way to provide secure access to a bzr server other than via SSH?
[23:21] <jelmer> Noldorin: over http/https
[23:22] <jelmer> or, alternatively, if you don't require a smart server you can also use sftp/ftp, smb, ...
[23:24] <Noldorin__> jelmer sftp is still ssh... but yes the other options sound appealing. how does https speed compare to smart server?
[23:24] <Noldorin__> (with ssh)
[23:25] <jelmer> Noldorin_: the smart server can be used over HTTPS as well, though it requires some setup
[23:25] <Noldorin__> ah right
[23:25] <Noldorin__> jelmer, but not ftp?
[23:26] <jelmer> Noldorin_: right, it would be pretty hard to tunnel something custom over ftp :-)
[23:26] <Noldorin__> yeah heh
[23:26] <Noldorin__> i could imagine!
[23:27] <Noldorin__> jelmer, hmm will have a look, thanks for tip
[23:27] <Noldorin__> be back in a bit
[23:27] <jelmer> Noldorin__: ssh should be simplest to setup though (hardly any setup at all), any reason you're not using that?
[23:28] <Noldorin__> jelmer, alas, windows server = ssh (almost) impossible
[23:28] <Noldorin__> unless some has some good tips for it
[23:28] <Noldorin__> tried a lot, but always some sort of error.
[23:28] <Noldorin__> hmm
[23:30] <Noldorin__> openssh for windows just isn't maintained :-(
[23:30] <Noldorin__> maybe there are decent commercial solutions. who knows
[23:30] <jelmer> ah, hmm
[23:30] <jelmer> I don't have any experience with SSH servers on Windows
[23:31] <Noldorin__> yeah. not sure many in the world do :-P
[23:31] <Noldorin__> you use openssh sshd on linux though yes?
[23:32] <jelmer> Noldorin__: yep
[23:34] <Noldorin__> jelmer, maybe cygwin environment then...hard for windows services though
[23:34] <Noldorin__> hmm
[23:35] <Noldorin__> brb restarting
[23:58] <Noldorin> jelmer, back
[23:58] <jelmer> hi Noldorin
[23:58] <Noldorin> hi
[23:58] <Noldorin> did you have any thoughts while i was gone?
[23:59] <jelmer> I had plenty, but nothing about SSH on Windows I'm afraid..
[23:59] <Noldorin> heh
[23:59] <Noldorin> fair enough