=== ubot5` is now known as ubot5 [03:28] I'm trying to use bzr to keep track of changes I make to /etc on my Ubuntu system. The problem is that I got a glob of changes that I would like to split in to a few different commits. The nice thing is that the changes that should be in different commits are in different files. Is there a way to do this? [03:30] bzr commit path [path...] [03:31] SoftwareExplorer: You should also look into using etckeeper for this-- it was designed for maintaining /etc in bzr. [03:31] lifeless: Thanks! [03:32] abentley: Cool, another toy to try :) [07:33] hi all [09:17] mgz, jelmer: this is what I did in the end: [09:17] (cd ../tree-with-toxic-file/; bzr diff -r1384..1385) | patch -p0; bzr commit --author "Original author " -m"$(cd ../tree-with-toxic-file; bzr log -r1385 | grep '^ ')" [09:17] repeated multiple times in a shell loop. [09:17] fortunately there weren't any merges to worry about, that makes it much worse. [09:39] morning === RickCogley_ is now known as RickCogley [10:05] mgz: aha, I just said something to you before you logged on :) [10:11] ah, but I have it in the buffer here [10:12] glad that worked, but we really do need a proper way of doing that [10:13] enough people run into it that they shouldn't all need to do their own hacks. [10:25] wgz: yeah. also, for the record, my hack is wrong because it doesn't account for added files. [10:25] wgz: I should have added "bzr add $(bzr unknowns)" to each step [10:26] quicksilver: not to mention renames... [10:26] wgz: and most importantly, my method totally fails to record merges correctly. I've done that before and it was a lot more hard work. Our local wiki (where I work) has a long page on how you might fix this kind of stuff [10:26] with various approachs which don't work. [10:26] bzr fast-export and bzr rebase are listed as two of the ones which apparently don't work :) [10:27] vila: yes indeed. renames like merges. [10:27] fortunately this was a fairly short piece of history and it was mostly just changes. I was just pleased to preserve the commit messages and atomicity. [10:27] * vila nods and agrees with wgz about better supporting that kind of operations [10:28] ok, reading my notes from last time [10:28] last time I used 'bzr replay' [10:28] that's pretty much the same as the diff/patch thing but better. [10:28] and for merges I used shelve. [10:28] (taht is, uncommit, shelve, manually copy shelf to dest tree, unshelve) [10:29] +1 on moving shelves from one tree to another (with some care for the needed revisions) [10:29] but shelve only worked for simple merges [10:29] it failed on a fiddly one with multiple conflicts and renames and stuff [10:29] and I never worked out *why* it failed [10:30] fortunately I was able to work around that by, essentially, manually redoing that merge from the revid involved, which wasn't a "toxic" revid so it was OK. [10:30] worth a bug report if you can reproduce but shelving a merge... won't track the merged parent I think (which may be an acceptable limitation) [10:31] vila: I wrote a pretty detailed post about it to the list last time [10:31] it was mostly warnocked. Too much to digest, I fear. [10:31] yeah, I was about to mention this rang a bell [10:32] you helped me last time, yes [10:32] yeah, and bug reports are better to track middle/long terms issues, posting to the mailing list is still valuable though, thanks for that [10:32] https://lists.ubuntu.com/archives/bazaar/2010q1/066738.html [10:32] the problem was I didn't understand bzr well enough to be clear what a useful bug report was [10:32] I tried to explain in enough detail for other people to understand [10:35] yup, the issue is also that you were using 2.0.3 and some of the things you refer to sound like bugs that were fixed in later version so it was a bit hard to split that into proper bugs [10:35] understood [10:36] I appreciate the difficulties and I've love to be more helpful but I always hit these problems when I'm on tight release schedules myself :( [10:36] some memory issues have been solved, there is now a add.maximum_file_size config option (defaulting to 20MB) which may have avoid the issue entirely [10:36] I'm now using 2.1.0 [10:36] what should I be using? [10:36] 2.4.2 would be nice. [10:37] but the core issues you highlight in that post are still relevent. [10:37] 2.4 at least, 2.5b6 has just been made available and is the last beta before 2.5 becomes the new stable [10:38] I have a conservative tendency not to upgrade core tools if they aren't broken. [10:38] and now I have a criss-cross merge and I don't know why :-( [10:41] how can I track down where the criss-cross is and break this merge down more sensibly? [10:41] qlog makes pretties [10:43] * quicksilver inverstiages installing qbzr === RickCogley_ is now known as RickCogley [10:50] * quicksilver is in a maze of twisty branches all alike [10:55] quicksilver: that's where 'bzr qlog trunk branch1 branch2 branch3' really helps [10:58] if I have a criss-cross trying to merge A and B then each of A and B must have independently merged C, right? [10:58] and the solution is to go via C [10:58] if I can locate C. [10:59] criss-cross merges are generally just a warning, unless you encounter bad merge results, you can probably just ignore them [11:00] and if you encounter bad merge results, fixing them once is also generally enough [11:00] if you do encounter them frequently, you may want to investigate your workflow though [11:01] * quicksilver nods [11:01] quite bad conflicts [11:02] legit or spurious ? [11:02] I thought I might be able to improve things by unpicking [11:05] looks like the same change applied independently in A and B in some cases [11:18] vila: I was mostly intellectually curious as to how we'd got into this situation and if I could simplify the conflicts by unpicking. It's probably a rabbit-hole I should avoid. [12:05] bzr: ERROR: Unable to determine your name [12:06] eh? how could bzr suddenly forget my name? [12:06] where is this normally stored? [12:06] ah, the bzr version upgrade must have lost it [12:07] ...it should really find the same config file [12:08] upgraded from 2.1.0 to 2.4.2 [12:08] if you run `bzr version` and `bzr config` it should have the same location and contents before and after (probably a bit late to check now) [12:08] Bazaar configuration: /Users/jules/.bazaar [12:09] that directory is empty except for my ignore file [12:09] hey [12:09] I was talking with a git user the other day [12:09] and the way they described interactive commit (incl. diff hunk splitting) sounded really nice [12:10] Does bzr have a diff hunk splitting thingy? [12:10] And does it have an interactive commit? (I use shelve a lot) [12:10] shelve splits by hunks [12:10] you know that if you use it :) [12:10] quicksilver: really? [12:10] hm. and do you have an existing file in %APPDATA%/bazaar/2.0/ instead? [12:10] I thought it did [12:11] you can hit 'e' in shelve if you have an editor configured [12:11] quicksilver: as in, can you take an existing hunk and split that up with shelve? [12:11] it's like, the least discoverable thing ever. [12:11] mgz: interesting, will try that out. [12:12] mgz: there are a couple of places that %APPDATA% might resolve to on a Mac. I'm poking around. [12:12] I think it needs to actually be as in `bzr config editor=` rather than just EDITOR= [12:12] quicksilver: whoops, mistook that for win 7 for some reason [12:12] the osx logic shouldn't have changed [12:13] it's bascially BZR_HOME or ~/.bazaar [12:13] so, if you had config in your home dir before bazaar should still see it [12:13] this is peculiar [12:13] I set up bzr about 7 years ago, I don't remember how I told it who I was :) [12:14] probably just by typing bzr whoami without worrying about it [12:14] although I can't remember if I made som eeffort to distinguish work repos from non-work repos [12:14] yeah, or maybe it just worked? [12:14] I'd be suprised if you had no config at all though [12:14] newer bzrs are a little stricter about how they get your identity [12:15] ah you know what, I never did set it up I think [12:15] old commits show my user ID as jules@machine-name.localdomain [12:15] not with a real email [12:16] ah, yes, that's what the newer versions are trying to avoid [12:16] never bothered me personally since it was obviously me [12:16] but I can see people would prefer a real email address [12:17] would be nice to set whoami for a whole shared repo rather than one branch at a time [12:18] yup. [12:18] you can set a sensible global value though. [12:19] having a mix of different identities for different projects on the same machine is currently somewhat painful though [12:23] I've been compiling since vila convinced me to try qlog at 10:55 [12:23] it's still working on Qt [12:23] I hate source distribution :P [12:24] eheh, surely there's an easier way to get qt there? [12:24] you're using a platform where you're not expected to do things for yourself. [12:25] mgz: dunno. I usually find macports is the best way to get open source software [12:25] apparently 'brew' is the new kid on the block. [12:25] but they both compile from source. [12:25] why not just run gentoo in a vm... [12:26] not sure that solves the source problem :) [12:26] seems like a masochistic approach [12:26] but I guess trying to do free software packaging on a mac means that's the kind of people they are [12:27] i am doing 'bzr commit' and my editor is launched. i am about to write a commit message and dont remember what i did so i open another terminal and type bzr status too see what i actually did [12:27] then bzr complains about bzr: ERROR: Could not acquire lock "/path/to/file" [12:27] yeah. [12:28] that's why the default commit messages reminds you what has changed at the bottom? [12:28] antonh: bug 98836 [12:28] ...bot? [12:29] quicksilver, yes only what files has changed, it gives no info about the diff [12:29] at any rate, that's a known issue with one bit of bzr, but it's not an easy change [12:29] antonh: yes. I now have the habit to always run diff first, and then commit. [12:29] C-x V = and then C-x V c [12:30] then I can compose my commit message browsing the diff in the other window [12:30] mgz: I'll be your bot! https://bugs.launchpad.net/bzr/+bug/98836 [12:31] thanks bot! [12:33] isn't it possible to perform a write lock on the file and let other processes have read access to the file? [12:34] isn't 'bzr status' a read-only operation? [12:34] not portably using the simplistic OS locks bzr is currently using [12:34] logically some way of differentiating read and write locks would go some way to solving the problem [12:35] okay, so there is only one kind of lock at the moment. and that lock covers up for both read and write [12:36] antonh: read the bug for the messy details, but basically the fancy stat cache can need updating whenever it looks at the tree [12:36] which is why it needs write access [12:37] so, entering the commit messsage shouldn't hold a lock, and st shouldn't really need to write lock, but that's how things work currently [12:38] yeah [12:38] if it was written in C i might have looked at it right away [12:39] it's really an issue with the design of dirstate, rather than something that's just a code problem, hence why it's stuck around as a problem [12:40] well I think you could scrap the lcok on starting commit couldn't you? [12:40] or collect the message first, at least [12:41] i guess your solution is the easiest quicksilver [12:42] actually it isn't 'bzr status' i want to do, it's 'bzr diff' but i think you realised that :) [12:44] antonh: the easy thing for you to do is just `bzr alias ci="commit -p"` or similar [12:44] so you always have the diff [12:45] oh cool [12:47] Newbie question: In Bazaar, is there any difference between "bzr mv ..." and "bzr rm ...; bzr add ..."? [12:49] kise: yes, that would add a completely new file [12:49] kise: if you 'bzr rm', then 'bzr add' you can use 'bzr mv --auto' to make it detect renames [12:50] jelmer: Thanks. Ok, then let me explain a problem I have. [12:50] I had a folder named "extra" with many subfolders and did the following: [12:50] 1) I rearranged rearranged them manually into "extra/cpp" and "extra/python". [12:50] 2)"bzr add" [12:50] Now Bazaar shows all the subfolders as "removed" and then "added". [12:50] I thought it would be better if they appeared as "moved" but don't know how to do it. [12:50] "bzr mv --auto" does not detect anything. [12:50] Any suggestions? [12:51] kise: hmm, are there more changes to the files than just their move? [12:51] No [12:51] I'm not sure why 'bzr mv --auto' doesn't work then [12:51] `bzr mv --after` will let you fix up stuff now [12:52] jelmer: 'bzr mv --after' means I have to do it for every subfolder I moved manually? [12:52] kise: yes [12:52] if there are hundreds that might be annoying, but if you didn't also rename the dirs it's amienable to scripting [12:53] bash one liner someone? :) [12:53] I see. Thanks for the suggestion. Will try my hand at Python :) [12:55] Sorry, a related question. While trying to use the "--after" switch I found this: [12:55] bzr mv xtra/unused-cpp xtra/cpp/unused-cpp --after [12:55] bzr: ERROR: Could not move to unused-cpp: xtra/cpp/unused-cpp is not versioned. [12:55] Do I need to add first all directories with "add --no-recurse"? [12:56] what does switching --after to --auto do in that case? [12:56] kise: yep [12:58] Uhm, I see. Anyway tried switching --after to --auto and bzr complained: [12:58] $ bzr mv xtra/unused-cpp xtra/cpp/unused-cpp --auto [12:58] bzr: ERROR: Only one path may be specified to --auto. [12:58] Seems like I will have to do it through scripting. [12:59] Thank you very much, jelmer and mgz ;) [12:59] it's a bit odd that 'bzr mv --auto' doesn't work thoughj [13:00] It has happened to me several times. T_T I don't know why either. I use Bazaar 2.4. [13:00] Never anyone had this experience? [13:01] kise: 'bzr mv --auto' seems to work fine for me [13:01] kise: I don't use it often though, usually I just use 'bzr mv' when I move files [13:02] I see. Thanks anyway! ;) [13:02] kise: if you hit this again, please file a bug [13:02] Ok [14:19] vila: qbzr finally installed :) [14:19] quicksilver: \o/ [14:22] you know I hate GUI tools [14:22] but I can see some neat things here [14:22] what are the colours in qblame? "freshness" of the change? [14:23] hue is who, intensity is how recently [14:24] * quicksilver nods [14:24] what would be better, of course, is an emacs mode with the same functionality :) but this is cool. [14:52] hmm no bzr qmerge --preview [14:55] see bug 415232 [14:56] or the bug linked from there for more. [15:02] quicksilver: AIUI emacs provides something (but we had feature requests to make it faster) [15:02] quicksilver: the default vc mode is where this is defined (IIRC) [15:03] vila: well I use dvc for quite a lot but it doesn't have sepcific support for merge --preview [15:03] vila: however it's simple enough to do M-! bzr merge --preview ../other-branch [15:03] err, sorry, I thought you were talking about annotate [15:03] vila: and then M-x diff-mode in that buffer [15:03] yup [15:03] I use that Heavily [15:04] bonus points for C-x C-q to put it in read-only mode [15:04] which makes the keybindings more useful. [15:04] hmm [15:04] but that means C-c C-s (split-hunk) does not work anymore ? [15:07] didn't know that one [16:01] quicksilver: very handy to revert part of a change [16:09] vila: yes I must admit I generally do that by hand [16:09] vila: and then re-check the diff to see I did it right. [16:10] Yeah, I did that before I discover it, I never looked back ;) Of course it works for *applying* part of a change too (if you M-x cd to the right directory) [17:11] http://search.cpan.org/dist/VCI/ looks interesting [17:11] but I can't see that it's data model knows what a 'merge' is. [17:11] although it mostly supports VCSes which understand merging. [17:36] does anyone know offhand if there is a way to turn a revid into a loggerhead URL? [17:37] /branch-name/changes/34.1.2 is a valid URL for a dotted revision number [17:38] /branch-name/changes/revid:blah doesn't work though === maxb is now known as Guest79372 [18:00] ah well it turns out we're using a version of loggerhead which has a bug on that kind of URL anyway [18:00] c'est la vie [18:24] halo? [18:25] hey I had a general security question [18:26] I don't feel comfortable with out bzr stores my password in plaintext, so I modified the bzrlib/transport/http/_urllib2_wrappers.py :: get_user_password to grab the password from a file on the system [18:27] the file I made is a c program that when executed, checks the md5 of the bzrlib/transport/http/_urllib2_wrappers.pyc file, and if it matches the one that was given at the creation of the file, it prints out the password [18:27] does anyone see anything glaringly wrong with this approach? [18:30] oh, that's supposed to say "comfortable with how*" [18:34] tronhammer: I take it you're using https? [18:34] yeah [18:35] also, count out c decompilers of coarse, those aren't a concern [18:36] more issued with lunch time attacks [18:36] there are some neater password stores that integrate with some OS things === verterok` is now known as verterok [18:36] but that depends on you using an OS with one of them === deryck is now known as deryck[lunch] [18:36] hm, that's a good point, could use keyring for lion [18:37] keychain* [18:42] tronhammer: http://www.szakmeister.net/blog/2010/mar/9/bzr-keychain/ [18:43] awesome, great find! [18:43] thanks [19:15] d:\repos\emacs-trunk>bzr pull [19:15] Using saved parent location: bzr+ssh://damd@bzr.savannah.gnu.org/emacs/trunk/ [19:15] bzr: ERROR: Unable to connect to SSH host bzr.savannah.gnu.org; [Errno 10013] An attempt was made to access a socket in a way forbidden by its access permissions [19:15] how do i fix this? :| [19:19] damd||: can you pastebin the corresponding traceback from .bzr.log? `bzr --version` will tell you where to find the log file [19:19] !pastebin [19:20] hmm [19:20] !paste [19:20] meh [19:21] i'm attempting to upgrade bzr, but hold on if you have time, thanks! [19:25] here is the log: http://pastebin.com/raw.php?i=nYnKvQeM [19:30] brb === deryck[lunch] is now known as deryck [19:31] damd: that error seems to come from somewhere underlying bzr (either the ssh provider or the os) [19:32] damd: googling for the "An attempt ..." bit comes up with some hits [19:32] yeah, i figured... i'm using pageant to serve the keys, i'm just guessing that bzr knows that i want plink to take care of SSH [19:32] damd: yeah [19:33] damd: do you have a firewall that could cause this maybe? [19:34] no, i don't have a firewall, unless "microsoft security essentials" provides one [19:34] damd: it does afaik (or builtin to windows itself) [19:34] apparently i had the windows default firewall turned on, but turning it off didn't help [19:35] turning off real-time protection in security essentials didn't help either [19:36] damd: the other thing that comes up in google hits is that something else is already using the port the application tries to bind to [19:36] but that doesn't make much sense in this case [19:37] i'll try restarting the computer... :P [19:42] damd: did that work? [19:42] haven't tried just yet, hold on [19:43] i'm afraid it didn't :/ [19:43] ok [19:44] it's really weird, because it worked the last time i tried it, which was a few months ago [19:44] i really haven't touched bzr since [19:44] damd: right, might not be bzr itself that changed though [19:45] you're right [19:45] damd: you mentioned you tried to upgrade it now? [19:45] yeah, i uninstalled bzr 2.3.1 (if i recall correctly) and installed the current 2.3.x stable [19:45] 2.3.4 i think it was [19:45] i used the standalone installer [19:46] damd: not that I think it would solve it, but any reason not to use 2.4? (Or a 2.5 beta if you want to try that) [19:47] when i tried to start the 2.4 stable installer, nothing happened, when i tried to start it from total commander, total commander just hanged [19:47] * LarstiQ blinks [19:48] so did i :P [19:49] damd: well, that's a reason :) [19:49] :) [19:49] damd: could you maybe try a different ssh provider? [19:50] i'm not sure which one that would be, i've only ever used the putty suite [19:51] paramiko is bundled with the standalone bzr installer I believe [19:51] * LarstiQ looks up how to tell bzr to use it [19:51] my first guess would be BZR_SSH [19:52] yeah [19:53] maybe we should just try BZR_SSH=paramiko instead of me reading the code [19:53] right, 'paramiko' or 'none' [19:53] i can't find paramiko on my system [19:53] brb [19:54] damd: it's a python implementation, would be in with the bzr executable afaik [19:54] oh [19:54] well, same error [19:54] d:\repos\emacs>set BZR_SSH [19:54] BZR_SSH=paramiko [19:56] bah [19:57] damd: can you ssh in to rule out any problems with putty? [19:57] or well [19:58] problems indepedent of bzr [19:58] 11 [19:58] woops [19:59] in putty i get "network error: permission denied" [20:00] damd: can we get more verbosity from putty? [20:00] i have no idea to be honest [20:04] damd: everything I can dig up keeps pointing at firewalls :/ [20:06] yeah, thanks a lot for the effort though [20:07] you've done way more than i hoped for [20:07] damd: np. I wish I could solve it [20:08] luckily it's not that big of a deal [20:08] damd: ok then :) === mbarnett` is now known as mbarnett [20:46] damd: it occurs to me that perhaps it is a roundabout way of saying the equivalent of the openssh "Permission denied (publickey)." [21:38] Hi all. can bzr import{dsc,tar} import only the debian/ directory from a package? [22:22] hmm, is it normal that I see bzr 2.5b leaving locks all over the place when I Ctrl+C it? [22:22] win32 here [22:23] not expected no [22:23] then I'm seeing it do that pretty much every time [22:25] file a bug?