[00:00] abentley: so previewtree will still need an inventory at some point without more diff refactoring? [00:05] No, I mean I hope that PreviewTree won't need an inventory, but until it's finished, we can't be sure. [00:07] abentley: so, my diff suggestion, do you think its baked enough ? [00:10] Yeah. The main thing it's silent on is how to handle kind changes, but I've got my own ideas. [00:10] abentley: oh, hmm kind isn't in the signature is it? [00:11] Well, I was going to put it there anyhow. [00:11] though if each Diff is contructed with the trees, at the start of TreeDiffer [00:12] you don't need to extend the signature; cross-kind diff could just be a wildcard at the end of the [Diff, Diff, Diff..] list [00:12] abentley: fair enough [00:12] * mwhudson goes to bed [00:14] lifeless: Sure, but the larger issue for me is, what should CrossKindDiffer do? [00:15] My current idea is that it represents it as an add + delete, and uses the existing list of differs to do it. [00:17] oh, in the UI ? [00:20] Well, the output. [00:21] So if you change a symlink to a file, it shows deletion of a symlink, and a unified diff that adds a file. [00:21] so here's a corner case [00:21] wjhat about subtree -> directory [00:21] (with the same contents under both) [00:22] but other than that I think it makes sense as you propose; presumably just call diff twice, once as a delete once as an add [00:22] I think the nested-trees code hides tree references from diffs, and presents the referenced directory instead. [00:23] k [00:24] There's room for improvement, but that's good enough for nested-trees to go beta. [00:25] statik: have you actually started programming in erlang? or are you just interested in it? [00:26] New bug: #164436 in bzr "permissions tests need to be parameterised too" [Medium,Triaged] https://launchpad.net/bugs/164436 === mw is now known as mw|out\ [00:37] lifeless, hi, === me_too is now known as too_short === too_short is now known as me_too [00:51] poolie: oh, had you pung before I rung ? [00:51] mtaylor: erlang is quite nice [01:00] that would be the ultimate tool [01:00] a distributed vcs that can run distributed [01:04] :D [01:10] ah well, g'night [01:11] good night :) [01:30] hmm, somebody sent me a .patch file that is a bzr bundle [01:30] I haven't merged this kind of thing before [01:30] any pointer to docs of how to do this? [01:31] (can I merge it into my tree keeping his metadata?) [01:31] warren: You can, by and large, treat the file as a branch. (i.e. bzr pull bundle.patch, bzr merge bundle.patch) [01:32] Odd_Bloke, ah [01:33] Odd_Bloke, for future reference how do I create this kind of bundle myself? [01:33] warren: 'bzr send' is the command you want to look at. To create the file, use 'bzr send -o bundle.patch'. [01:34] There are craftier ways to use it, but I haven't fully plumbed their depths. [01:39] (lunch) [01:39] warren: what platform are you on? [01:40] abentley, Fedora [01:41] if you have xdg-utils installed, bzr send will automatically launch your preferred mail client, with the bundle as an attachment and everything. [01:42] cool [02:32] ** launchpad is down for maintenance - upgrade to the next version [02:32] poolie: in this time of night ... :) [02:34] i mean, for an upgrade to the next version [02:34] it's midday here... [02:34] i think it's designed to correspond with the lowest daily usage - US and EU nighttime [02:35] poolie: It's okay. I'm amazed you aussies can stand on your heads all day... [02:37] poolie: patch mailed [02:38] poolie: its not 'done', but this is a reasonable snapshot of progress; I think the vast ermaining bulk is the smart server verb === cprov is now known as cprov-ZzZ === Verterok is now known as Verterok_ [03:07] Is it possible for me to have one file in my repository that sort of mirrors some single file from someone elses repository of a completely separate project? [03:13] floam, sorry, no [03:13] well, [03:14] what i suggest you do is make it a symlink to a file in a checkout of their project [03:14] poolie: you can set up a branch with that one file merged, and other files will just conflict / could do partial merges all the time [03:14] that too [03:15] reading your patch [03:15] thanks [03:15] I'm folding now [03:15] floam: btw, what you're calling a "repository" we call a "working tree". [03:16] abentley: sorry, I've used cvs/svn up until three months ago [03:16] We use "repository" more in the CVS sense. [03:16] I assume the heart in the right place with the nomenclature wrong is better than the other way around :) [03:17] Sure. [03:18] folding? === abentle1 is now known as abentley [04:03] lifeless: I've been looking at an erlang project, but I'm looking around for motivation to actually learn erlang :) [04:05] lifeless: do you know anything about extending erlang with c libraries? (like if I already had one and wanted to wrap it) [04:31] lifeless: ping === Verterok is now known as Verterok_ [06:45] New bug: #164443 in bzr "can't branch bzr.dev from codehost over bzr+ssh" [Critical,Confirmed] https://launchpad.net/bugs/164443 [06:45] New bug: #164447 in bzr "bzrlib.info.describe_format should be a BzrDirFormat method." [Medium,Triaged] https://launchpad.net/bugs/164447 [08:01] New bug: #164450 in bzr "should show a message when pushing(overwriting?) tags" [Low,Confirmed] https://launchpad.net/bugs/164450 [08:11] New bug: #164453 in bzr "bzr using way too much memory for large file fetch" [Undecided,New] https://launchpad.net/bugs/164453 === mtaylor is now known as mtaylor|zzz [08:57] abentley: pong [08:57] abentley: I'm guessing you are asleep at this point, but if it was re Differ's, I've replied - I think it's looking good. [09:01] thumper, ping? [09:02] poolie: pong [09:02] thumper, do you want to come to this call? [09:02] whose number? [09:02] conference centre? [09:03] I'm there [09:19] Acro: I wasn't, and I'm going to class now again, but leave a message and I'll try to get back to you [09:35] New bug: #164466 in bzr "rename packs from knitpack-experimental " [Undecided,New] https://launchpad.net/bugs/164466 === cprov-ZzZ is now known as cprov [10:07] Eeek! [10:07] I punched up http://bazaar.launchpad.net/~bzr/bzr-gtk/trunk and it says "Not Found The requested URL /00/00/05/32 was not found on this server." [10:12] yes, that sucks [10:14] That'll teach ya. [10:17] fullermd: :) [10:30] mwhudson: whats the problem? missing / ? [10:31] lifeless: yeah, you get internally redirected to a url that you can't access, or something [10:31] mwhudson: that should be trivial to fix; [10:31] ... pretty please? [10:32] lifeless: it's an apache config issue, and i really don't know much about that [10:32] lifeless: file an RT? [10:40] Hello, is Qbzr a complete GUI for bzr ? giving the possibility of add, commit, create branch,... ? [10:41] and other question is : how to lauch it ? [10:52] mwhudson: you need a redirect that matches the non/ - ...$ -> .../ [10:52] mwhudson: its maintained by the lp-bzr folk as part of the codehosting config [10:52] theSoftMan: I'm sorry, I haven't used it myself, but yes I understand it to allow those operations [10:56] lifeless: so redirect ~blah/blah/blah to ~/blah/blah/blah/ before considering anything else? [10:58] mwhudson: yes [11:00] New bug: #164476 in bzr "packs should be the default format" [Undecided,New] https://launchpad.net/bugs/164476 [11:04] lifeless : i have made the installation on my windows system but i can launch it ? ( thanks for you previous answer ) === mrevell is now known as mrevell-lunch === mrevell-lunch is now known as mrevell === mw|out\ is now known as mw [14:26] hi folks - quick question probably. I tried my first merge (woo!) and it was OK except while resolving some conflicts i had the case where the working tree had deleted the files and the merge source had made changes since the base ... [14:27] except that I didn't understand what it was trying to tell me and so marked them as resolved because i knew the files had been deleted [14:28] How can I get the .BASE and .OTHER files back for those items (I can remember which files they were), or how can I check the changes in the merge source against the base that was chosen, given that I don't know what the base chosen was? [14:37] Maybe something with remerge? === cprov is now known as cprov-lunch [14:51] fullermd: I was wondering that too, but didn't want to try it without knowing what it might do :) [14:52] I'm doing it manually and learning how bzr diff and bzr log work properly, so it's all good [14:52] Well, it's unlikely to make demons fly out of your nose ;) [14:52] au contraire :) [14:52] he [15:05] * Peng strangles bzr. [15:05] Ack! You squeeze all the vowels out! [15:07] * Peng strangles rubygems too. [15:09] I renamed foo/ to bar/. Bzr thinks everything in foo was removed and everything in bar is unknown. :( [15:09] Isn't that what you'd expect? [15:10] Noo. [15:10] The directory was renamed. [15:10] but how would bzr know? [15:10] As in 'bzr mv'. [15:10] Well, yeah. But if you didn't tell bzr about it... [15:10] Yes I did. [15:10] on, `bzr mv`? [15:11] * fullermd blinks. [15:11] Well, it wasn't done by 'bzr mv' [15:11] But I ran 'bzr mv' afterwards, and it does know about the rename. [15:11] I think I give up. [15:11] maybe you wanted `bzr mv --after`? [15:11] dato: I might've done that. [15:11] Or just manually mv it back, then bzr mv it again [15:11] Did you have the trailing slash on bar? [15:12] "mv foo bar" oh oops I forgot; "mv bar foo; bzr mv foo bar" [15:12] Yah. That can be simpler when you're dealing with dirs. [15:12] @_@ [15:14] Okay, I give up. [15:14] How do I bzr rm a directory that I've already rm -rfed? [15:14] bzr will mark it as deleted automaticcally [15:14] I don't think you have to... [15:14] Oh, that's right. I forgot. [15:14] Hmm. [15:14] I think something else is screwy. [15:15] This would be the week for it. [15:15] Oh, never mind. The something else was user error. [15:15] Forgot I was in a different directory. [15:16] Hmm. [15:16] Part of this whole mess was probably user error because of that. Not all of it, though. === cprov-lunch is now known as cprov [16:23] how to remove the changes of a specific revision? I'd like to get rid of rev 83, but this doesn't work: bzr merge . --r-83..-84 [16:24] bzr merge -r 83..82 [16:25] says nothing to do [16:28] dato: ah, thx, made a mistake! [16:29] dato: I tried 83..84 ... === cfbolz_ is now known as cfbolz [18:50] hello [18:52] is it dangerous to have a directory /a managed as a tree by bzr and another directory /a/b/c managed as another tree by bzr? [18:53] (/a/b/c would be on the ignore list of /a) [18:53] I don't think it's dangerous. [18:54] gioele: no that's fine. [19:13] thanks for the info === cprov is now known as cprov-away [19:28] i'm currently pushing a 93MB branch to LP, it's running since once hour and I don't see much progress, still at Fetch phase 0/4 [19:28] how can I check if anything is still happening? [19:29] TeTeT: ~/.bzr.log might have something [19:31] james_w: states 'fetch up to rev {spindler@...}' [19:31] james_w: and before that 'Using fetch logic to copy between KnitRepository(....)' [19:32] I thought it might say what it was doing as it worked, but it doesn't. [19:32] james_w: just finished :) [19:32] \o/ [19:32] TeTeT: did you ever get bzr-builddeb working for you? [19:33] james_w: I honestly haven't tried, the packages I patched were not in bazaar anywhere [19:33] james_w: but I'll give it a whirl on a package for training I'm supposed to do [19:33] that's cool. I was being pretty useless trying to help you anyway, so I can't blame you. [19:35] you were most helpful, it just took a while to figure out where the problem was [19:37] well, if you need any help you know where to find me. [19:37] thanks for the offer :) [19:39] 'lo [19:41] hi lifeless [19:49] hmm, I've merged a branch, it added some revisions, great. How do I get the log message and the diff of the new (but not yet committed) revisions in chronological order ?. Something like svn log|diff -rBASE:HEAD. [19:50] woei: if I understand what you mean 'bzr diff' should give you the diff. 'bzr status' will show a summary of each merged revision. [19:51] If you want the full log then that is a bit harder, one easy way that might not work would be 'bzr missing --theirs-only .../otherbranch' [19:51] .oO( bzr commit; poke; bzr uncommit ;) [19:52] There will be a way to get the log with the log command, but my brain fails me once again. [19:52] I'm looking for something like gitk, where you can see the log and the diff of what happened at each commit [19:52] bzr diff does give me the diff, but it gives me the diff of all the revisions I just merged [19:54] when getting revision 3, 4, 5, I'd like to see the log of rev.3, the patch of rev.3, the log of rev.4, patch of rev.4, etc. [19:55] woei: after you've committed the merge, it's easy to do that with bzr log and bzr diff, or visually with `bzr viz` (from bzr-gtk) [19:55] woei: maybe you're looking for bzr gtk (olive) [19:56] woei: without committing the merge, I don't think you can, at least I wouldn't know how. [19:56] ok, so I'd branch a working copy, merge from upstream, use a graphical tool to go over each patch, and then merge that pulled branch back to the real working copy [19:59] woei: that would work. [19:59] woei: there is a bug to allow you to access the merged revisions, but no-one has worked on it yet. [19:59] hmm, and is there an easy way to refer to the revision prior to the last merge ? So bzr log and bzr diff only shows that interval ? [19:59] also bzr-gtk doesn't deal with merged in stuff at all. [20:00] woei: the last merge in which direction? [20:00] the stuff I pulled from upstream [20:00] and then committed [20:00] prior to merging it back to the real working area [20:01] so you want to see the stuff that you did in your branch since the last time you merged from the other branch? [20:01] after committing, bzr log does show the new revisions indented, but how do I tell it to show only those revisions with bzr log ? [20:01] woei: try bzr log -r -1 [20:02] it will show them still indented, but *only* them. if I understood correctly. [20:03] no, I made a branch to merge in changes from upstream. I did a bzr merge. I'd like to see the log and patch for each commit. That's not possible (yet) on the command line. Okay, so I commit that merge (from upstream). How can I get just the log (and diff) from the point where I branched from my working copy (to receive new revisions from upstream), and the head of what's in the (now synchronized) branch ? [20:04] dato: excellent, bzr log -r -1 does just that [20:04] but bzr diff -r -1 does not [20:04] for the diff, bzr diff -c -1 will give you the whole diff [20:05] or bzr diff -r -2..-1 [20:05] dato: ok, great [20:05] woei: bzr-gtk will now be able to give you diff for each commit. For the command line you can use bzr diff -c x.y or bzr diff -c revid:xxx [20:06] ok, I'm starting to get the picture on why I needed to commit [20:08] woei: also, it's not strictly necessary that you make a separate branch and merge there; you could merge in your branch, commit, and if for some reason you don't like the result, do `bzr uncommit` [20:08] and that extra branch to receive new revisions is not really needed, if you use bzr commit; bzr viz; bzr uncommit [20:08] dato: exactly :) [20:08] :) [20:09] ok, thanks all for pointers [20:15] New bug: #164567 in bzr "FTP push does not work without specifying password" [Undecided,New] https://launchpad.net/bugs/164567 [20:56] abentley: ping [21:00] odd, I seem to be missing emails on bazaar@lists.canonical.com :-( [21:40] is there a way use a GUI of some sort to go through a diff, and accept or reject chunks? [21:45] keir: at commit time ? [21:46] so, what i have done, is checked in an external library into my tree, and made several changes [21:46] but now upstream has moved forward [21:46] so what i've done is just copied upstream over top of my working tree [21:46] when i do diff, my changes show up as -'d [21:46] i want to revert just those chunks, then check in the changes [21:46] do you know of 'bzr shelve' ? === Verterok_ is now known as Verterok [21:47] i thought that is just for uncommitted changes? [21:47] in my case, i committed my changes ages ago [21:47] these are uncommitted changes :) [21:47] you have an uncommitted reversal of your change [21:47] oh, i see [21:47] now, the slight problem, is that these changes are close in proximity to mine [21:48] ok [21:48] keir: for some other time, why don't you apply the new version in a separate branch, and merge that? [21:48] so in multiple places, the hunks show up as a single hunk, with an add and a remove [21:48] heres a different and more scalable approach [21:48] branch -r upstream [21:48] cd upstream [21:48] ah yes, i see [21:48] unpack upstream stuff; bzr add; bzr commit [21:48] cd your-branch [21:48] bzr merge upstream [21:48] yes, ok. [21:49] wait, but i only want to merge the particular changes to the extern/ lib; not the other changes [21:49] so isn't this a cherry pick? [21:49] no [21:50] what other changes will be in that branch than those to lib from upstrea? [21:50] hmm [21:50] sorry, thinko, i got it === cfbolz is now known as verwirrt [21:54] dist vc is so nice :) [21:59] i'm itching to implement the faster index layer... stupid RL [21:59] yah [21:59] same [21:59] :) [22:00] an aside: why is it that bzr 'detects' deletions? [22:00] there is a bug [22:00] rather than svn's behaviour [22:00] it should be a flag like -A to automatically add and delete new paths [22:00] and by default error on deletes [22:01] yeah, i totally agree. though there is a case that it is the 'wrong' way to use a vc, i like in svn that if i do something silly, i can just delete and svn up [22:01] i know that's what revert is for [22:01] yet somehow i prefer delet and update [22:02] its really very strange for me that svn update restores files rather than preserving your changes - its inconsistent. [22:03] on a completely logical level, i agree [22:03] yet somehow, i feel like the vc is my 'barrier against stupidity'... if i go and delete stuff, without informing bzr, i probably didn't mean it [22:03] And lord knows preserving the broken behaviour of previous generations of tools is not the primary goal around here [22:04] On the other hand, if I delete stuff, I do mean it... [22:04] fullermd: alias commit=commit -A ;) [22:05] (when that exists) [22:05] But just because a file exists, doesn't mean I want to add it. [22:05] fullermd, i feel the same way about deletes :) [22:05] yeah, I'm not sure why lifeless mentioned additions for commit -A [22:05] perhaps commit -D [22:05] yeah [22:06] or bzr delete --missing [22:06] A for automatic [22:06] commit --automatic [22:06] lifeless, but it may be the case that you want to delete missing files, but not add unversioned files [22:07] keir: so the question is [22:07] is it worth having two flags [22:08] the main use case for commit --automatic is automated scripts [22:08] lifeless, aah, i see [22:08] but bzr rm --missing/--gone etc is a good way to have the equivalent of 'bzr add' [22:08] OTOH why not have 'bzr rm' do what bzr add does :) [22:09] but in reverse - rm everything that is not here [22:09] lifeless, exactly, that's what i meant by bzr delete --missing. i guess there is no bzr delete. heh [22:09] abentley: patch reviewed [22:10] does bzr internally support a status which is 'file is missing from WT' without having the 'delete at commit' bit set? [22:11] I don't think the delete bit is set until commit runs. [22:11] so status just shows it as a pending delete? [22:11] Yah. Put a file back on that name, and it'll just show up changed (or unchanged, if the file's the same). [22:12] but it would involve extending WT model to allow a new 'state' for deleted files which is missing, but not deleted? [22:12] You lost me... [22:13] i'm trying to think of how hard it is to implement the following: [22:13] 1) deleting a file in local repo does not mean it will be deleted at commit [22:13] 2) files which are to be deleted must be explicitcly bzr rm'd [22:14] 3) bzr st supports showing either explicitly deleted, or missing but not deleted, states [22:14] 4) bzr rm --missing does what you expect [22:15] i don't know anything about the WT's data model so that's why i'm asking these qns [22:15] I imagine 1/2 are just changes in commit, and 3 is just a change in status. The file isn't _deleted_, as putting it back will show. It just says it's deleted. [22:16] this would make rm consistent with add [22:17] would a patch to do this be rejected immediately because it changes behaviour? [22:17] Rejected? Doubt it. But it probably calls for a list discussion. [22:18] alrighty. [22:27] keir: 1) I would not like unless you mean 'will error at commit'; 2) would be good as long as there is an option for ocommit to get deletes back. 3) is already done I thought, 4) would be nice [22:27] I'd send an RFC, get some consensus, then patch [22:27] there is a bug already as I mentioned [22:34] abentley: ping, is there a inventory delta to iter_changes adapter around somewhere ? [22:35] abentley: I'd like to make bzr-email use the inventory delta generated by commit [22:40] hi guys [22:41] I've been happily push changes to my branch on LP [22:41] lifeless, ok. i'll probably wait.. realistically, if i'm going to do bzr hacking i should write the index layer [22:41] today I merged with someone, did some chages, pushed them successfuly, did some more changes....now I get an error that the branch has DIVERGED? [22:41] what is going on? [22:42] it suggests trying a merge then a push [22:42] but who do i merge with....my own older branch? [22:42] it doesnt make sense [22:43] cbx33: did you do the second set of changes in your branch ? [22:43] yes [22:43] what command gives you the error ? [22:43] bzr push [22:43] * fullermd suggests checking 'missing'. [22:43] it committed fine [22:45] cbx33: as fullermd says, what does 'bzr missing URLYOUPUSHTO' do ? [22:45] i was missing a merge [22:45] with myself [22:45] ok fixed [22:46] but not sure why;) [22:46] did you push there from more than one place ? [22:46] hmmm [22:46] possibly [22:46] yes that may have been it [22:46] thanks lifeless [22:56] morning all [22:57] hi [22:58] hi [22:58] call in 2m? [22:58] yes [23:00] lifeless, igc: ping [23:04] lifeless: I don't think we have an adaptor like that. [23:06] jelmer: pong [23:12] abentley: ok