[00:00] exporting from the content of the branch doesn't provide you that, so merge-upstream uses pristine-tar to make it possible [00:00] james_w: Oh - ok [00:00] Weird. bzr branch lp:ubuntu/ downloads *tarballs*? [00:02] They're versioned! What the hell? [00:03] james_w: Thanks for the help. [00:03] beta-ppa now building new bzr-svn [00:04] james_w: so, er, I must admit I'm surprised to see you tracking binary tarballs with bazaar, instead of sources. Doesn't that defeat the whole point? [00:05] AfC: we aren't [00:05] james_w: of branches to be shared between distros? [00:05] you may have picked a package where the packager decided that tarballs is what they wish to put in their source packages [00:06] james_w: um [00:06] james_w: so it's freetype [->libfreetype6] [00:06] james_w: and it says [00:06] Committer: Bazaar Package Importer [00:07] each time it merges a series of tarballs, and then replaces them [00:07] That you? [00:07] yes, so you chose one such package [00:07] it's a script run by me [00:08] I guess I don't understand why there are any such packages. [00:08] Because we didn't invent packaging branches years ago ;) [00:08] I really thought I'd be getting a branch full of sources, not full of tarballs. [00:09] spiv: right, but someone did invent the idea of using Bazaar to manipulate Debian packages in the not to recent past. You remember, when Bazaar was started, right? [00:09] O HAI, I see you have packaging that is designed to work with tarballs, I'm going to automatically rewrite it to work with unpacked tarballs so that you get a nice surprise next time you look at it! [00:09] spiv: My understanding [clearly wrong] was that the whole point was to have a branch of upstream that you would then apply revisions to to make a debian package. [00:09] AfC: If I'm understanding correctly, in this case the 'source' package contains a tarball. The bzr import of that is just reflecting that reality. === webchick|afk is now known as webchick [00:10] spiv: ah [00:10] spiv: I see [00:11] spiv, james_w: I didn't know such things existed, actually. [00:11] I'm from the Gentoo world, where the first thing that happens with a released tarball is that it is unpacked, so that people can then diff and patch against it. [00:11] It's probably because they wanted to merge the three separate .tar.bz2's into a single source package. [00:12] That would now be supported with the new 3.0 deb-src format, but that's very new. [00:12] Anyway, I guess this isn't what I was hoping for. My understanding from years ago was that we would have bzr revisions showing the packaging changes to a baseline of (upstream's) sources [which would be either upstream vcs or upstream tarball unpacked[ [00:13] bla: Rejected: bzr-svn_1.0.2-2~bazaar1~karmic1.dsc: format '3.0 (quilt)' is not permitted in karmic. [00:13] hello igc [00:13] AfC: and packages like this are why we didn't already have those bzr revisions years ago ;) [00:14] AfC: you do for the majority of package [00:14] So can you suggest a package that does behave properly (so I can compare, and not go away with the wrong idea)? [00:17] bzr? [00:19] james_w: There must be non bzr related packages for which we have a branch that shares the history with upstream? [00:22] there aren't many at the moment [00:22] we are focusing on getting every package available in some form first, then looking to improve the history of ones where we can [00:28] james_w: lp:ubuntu/qbzr dose not share its history. Can I fix that? [00:28] GaryvdM: yes and no [00:29] it's straightforward to join the history, but the file-ids also differ, so when you do everything in the tree conflicts [00:29] there isn't really a neat way to deal with that right now [00:31] james_w: So I can't give launchpad an instruction to can that branch, and start fresh using file [00:31] not easily [00:31] ... file-ids from branch x [00:32] Will that become easier in the future? [00:35] yes [00:35] james_w: :-) [00:36] I ran into that problem a few times in the past, too. [00:37] And yeah, hopefully it will become easy (read: possible for mere mortals) in the future. :-) [01:08] spiv, is the news auto-merger installed in pqm now? [01:08] GaryvdM, re [01:08] hi jelmer [01:08] Hi jelmer. [01:08] GaryvdM, you need a new entry for the ppa anyway because of the version string [01:09] GaryvdM, but generally you would keep the debian entries as well [01:09] hi poolie [01:09] poolie, does the pqm run 2.1 yet? [01:10] poolie: I don't know, but it would be nice to have :) [01:10] jelmer: Oh ok - need to re do them because I messed up the debian/control files. :-( [01:11] poolie: it would require bzr 2.1 and a small config tweak in bazaar.conf I guess. [01:11] poolie: do you know if someone was already looking into arranging that, or should I file an RT? [01:11] i don't know that anyone else is [01:11] it might be nice [01:12] the upgrade will probably be easier when 2.1 is packaged and available [01:12] at least in lucid [01:12] morning poolie and spiv [01:12] hello jam, and no, it's just after midday [01:12] I guess that's what I get for coming back late [01:13] anyway, just stopping by to say hello, I'll probably be back with the family in a couple mins [01:13] k [01:13] thanks for the reviews [01:13] jam: early afternoon :) [01:18] Ok, I'll wait until there's a 2.1 package then. [01:33] Drat, I sent a branch to PQM with the commit message for a different branch (both approved for 2.1, thankfully). === jamesh_ is now known as jamesh [01:34] I'm definitely looking forward to a command that take an lp merge proposal and send it to PQM with the source branch, target branch and commit message in that proposal. [01:40] I'm mostly looking forward to the fix for bug 109114. [01:40] Launchpad bug 109114 in bzr "[master] bzr holds whole files in memory; raises MemoryError on large files" [Medium,Triaged] https://launchpad.net/bugs/109114 [01:42] spiv, you can ask spm to kill the job [01:42] Hmm, that's a thought [01:42] spm: ping? Would you mind killing my "now playing" job on bzr's pqm? [01:43] good thing the tests aren't too fast ;) [02:07] Night all [02:19] Kilroo: noone is working on that at the moment. [02:19] I had gathered that. [02:20] Fact remains, it's the only thing not directly concerning either bzr-eclipse or bzr-svn that is having a negative effect on me. And the problems with them I can work around. [02:20] Kilroo: do you have multi-GB files? [02:20] Yes. [02:21] Not by choice, but until they stop piling projects on me long enough for me to propose a solid plan for moving to a more reasonable versioning plan, I have to work with the subversion repositories we have. [02:23] Two of those I can't pull the revision where they added the whole blasted main site at once. And one that otherwise ought to be pretty clean I can't work with because my supervisor had to get a file to an accessible location while he was at a convention and the only way he could think of to do it at the time was to commit a 1.5gb zip archive to a subversion repository. [02:24] I'm not even sure exactly how he accomplished it or why. [02:24] I'm actually kind of hoping that the hassle of purging it from the history of the repository helps my case for redoing our system. [02:27] :) [03:46] Is there how to merge only certain revisions? [03:50] You mean to cherry pick? You pass -rfrom..to [03:51] This won't keep the log history though. [03:52] what does it mean keep log history? that's the intention [03:53] It squashes down to a single commit, which contains the diff. [03:53] I have uncommitted a few revisions, so the old history in the feature branch became outdated and pointless [03:53] single commit? but I said certain revision*S* [03:53] * RenatoSilva is using rebase [03:54] Yes. It'll take the changes from certain revisions and apply them as a diff. [03:54] As far as I'm aware there's no way to (easily) take a sequence of commits for which the first commit does not have its parent in the branch and merge them as a series of commits. [03:55] You pass -rfrom..to to what? [03:56] bzr merge -r -1 didn't work, the other revs are there [03:56] RenatoSilva: -rSTART_REV..END_REV [03:56] RenatoSilva: it's a range [03:56] jelmer: don't suppose you want to package a newer bzr-search? we're getting lots of dups for fixed bugs [03:58] spiv: ah ok, but bzr merge d -r -2..-1 gives no pending merge in bzr qlog [03:59] spiv: maybe the conflicts? lms [03:59] RenatoSilva: if you're trying to merge the changes of just one revision, try -c REV rather than -r. [03:59] RenatoSilva: just because it's more convenient [04:01] RenatoSilva: but if merge of -2..-1 gives "Nothing to do.", then I that revision is already part of the branch [04:01] spiv: ok, but will it also --forget-merges automatically like in -r? [04:01] * RenatoSilva trying [04:01] RenatoSilva: yes [04:01] RenatoSilva: if -2 isn't already merged, in your example, then there won't be pending merges. [04:01] because you are doing a cherrypick, it lives outside the merge graph. [04:04] cherrypick? anyway, I have checked, it does forget the merge in both cases, this seems fine as I would --forget them anyway [04:04] * RenatoSilva realizes how uncommit may be annoying sometimes [04:05] "cherrypick" basically means "take just part of a branch's history, not the full branch" [04:06] i.e. what you're doing here. [04:09] so, I will make a hack (fb = feature branch): cp -r trunk fb_new; cd fb_new; bzr merge ../fb -c -1; bzr commit -m "Same message."; rm -r ../fb [04:09] * igc lunch [04:09] it's like a rebase :) [04:10] RenatoSilva: in the sense that the original history is generally no longer part of the new history, yes. [04:15] spiv: did I told you about the bzr search bug? I realized that it's all about inspecting bzr log -p, so I wrote a tool for that. I'm pretty satisfied. [04:16] spiv: usage is something like bzr log -p | greprev why_this_method_was_deleted, I used it today, very nice [04:16] * helpful [04:17] RenatoSilva: about bzr-search [04:17] RenatoSilva: it doesn't do log -p internally, it prebuilds indices to answer questions much faster than log -p [04:18] RenatoSilva: so I'm glad you're happy, and the bug is there in case someone chooses to implement it. [04:18] lifeless: I understand that bzr-search may be much more faster specially for big trees, but I'm pretty satisfied, specially because I can use a free regex, and because I get the revnos not ids [04:19] lifeless: I think implementing that bug would be just about replacing non-friendly the rev ids with the numbers. [04:19] RenatoSilva: well the unique thing I got out of your comments was seeing a diff [04:20] (of course there are the search string issue, but that's registered at another bug as you have reported there) (I just did not get the new title 'show hits as diffs') [04:20] I'm fairly sure there is a bug, or TODO at least, to show numbers (but that is also pending a revno oracle, something bzr branches need in general) [04:20] RenatoSilva: your script shows a diff doesn't it ? [04:22] lifeless: it gives you a clue. It shows the line of the rev's diff containing a match, and the file name, and the rev number. With this last, you bzr qlog and look at that rev to get more details (specially, read the commit comment) [04:23] revno oracle? you mean you cant just pick up the revno? ok [04:23] thats correct, calculating revnos means accessing all the information for the branch, and is often quite slow [04:24] RenatoSilva: ah cool, I'm glad that you found a way to do what you wanted :) [04:24] all info == loop the commits? oO [04:24] RenatoSilva: I'm fine with showing a diff, I'm just noting that bzr-search does not show a diff, and you want it to. [04:25] I thought revnos were stored as commit metadata, along with the long ids [04:26] nope [04:26] they are dynamic and can potentially change completely [04:26] lifeless: iirc it does the same, it shows the line of the diff containing the match, the problem is that the output is a bit weird (just a matter of formatting), and mainly, that we don't have the revnos [04:26] e.g. 'uncommit', 'push --overwrite' do this [04:26] RenatoSilva: no, bzr-search does *not* show a diff [04:26] lifeless: ah ok I didn't know that [04:27] lifeless: not the entire diff [04:27] not a diff at all, it doesn't access the old version of the file. [04:27] lifeless: weird, I was pretty sure I got some matches like + sadasdaad match [04:28] lifeless: I linked an example in the bug, let me check [04:28] it shows the first line in the new version of the file that matches any search term searched for [04:29] http://pastie.org/815629.txt [04:30] yes, not diffs [04:30] just lines extracted from the files [04:30] they're all from current revision for all files? [04:31] or from old revisions? maybe I misunderstood this comment? "bzr search searches the diff between revisions already." [04:31] what it searches and what it shows are separate [04:32] it builds an index from the file diffs. the index points at (revision, file) [04:32] it shows by reading in (revision, file) and looking in that for what you searched for [04:33] hence it shows matches in old file versions? [04:34] yes [04:34] the revision is printed at the left of the output [04:34] lifeless: there's possibly a valid bug here along the lines of "document what bzr-search indexes in a way that end users will comprehend"? [04:34] spiv: perhaps. Or make it more powerful so it doesn't matter. [04:34] or perhaps just s/comprehend/discover/ ;) [04:34] lifeless: right [04:35] lifeless: but in the meantime while it's not quite as awesome as google, document it ;P [04:35] spiv: I mean, this conversation is about it a) not searching via literal strings (a subset of full regex) and b) the output being fugly [04:35] s/conversation/bug report/ [04:36] (I'm not trying to imply anything much about the priority of documenting the status quo vs. improving it) [04:36] FWIW, I generally consider bug reports to be conversations :) [04:36] vs the conversation on IRC :) [04:37] lifeless: well I'm very sorry but I can't really understand you pretty well. It simply seems to me that, if there was a revno rather than that rev id (and besides the output being a bit weird), it would give me the info I want. If not, then I'm sorry [04:38] RenatoSilva: it can currently show a line that was not altered by the commit [04:38] lifeless: I'm jsut lost with that bug at the moment. I have no idea what 'hits as diffs' mean :( [04:38] it means show the results as diffs [04:38] not as summaries from the committed documents [04:38] I don't know how to phrase that differently I guess. [04:38] a hit is a search hit, its something returned from your search. [04:38] a diff is a description of a change between two things [04:39] bzr-search currently shows hits as summaries *of the new things*, not as *a difference between things* [04:39] lifeless: ok just know that I'm confused, and I'll probably leave that bug, I'm sorry :( [04:40] I'm satisfied that I know what you want. [04:40] And I've described it in a way that I and other bzr-search devs will understand. [04:40] I think you'd need to read the code to understand whats going on >< [04:40] lifeless: so if one wants more details in the future from the bug reporter, I'll not be there because I don't get the bug idea anymore :( [04:41] lifeless: ok ok thanks, it's just to let you know in case if you find it weird that I unsubscribe or so [04:41] thats fine [04:41] you've communicated what you wanted well using the filter script you wrote [04:42] ok [04:45] thank you very much guys [05:09] spiv is https://bugs.edge.launchpad.net/bzr/+bug/421845 really high? [05:09] Ubuntu bug 421845 in bzr "bzr check fails on valid stacked repository isolated from fallbacks." [Medium,Confirmed] [05:10] actually nm, i already downgraded it [05:10] revert that if you disagree [05:14] poolie: hmm [05:14] poolie: I don' [05:14] I don't feel strongly about it, but I tend to think that bugs that stop 'bzr check' from being a reliable way to determine the health of a repo are serious. [05:15] But at the same time, it is a bit of a niche situation. [05:16] ok [05:16] i'm doing a bit of a roundup of bugs with patches [05:16] you could turn yours into a known failure [05:16] but... [05:16] that doesn't actually fix it [05:16] so it's probably not worthwhile [05:17] But it would shift it off the "bugs with patches" queue ;) [05:18] :) [05:19] spiv do you think the malloc patch is safe for 2.0? [05:19] I think so, but it might be nice to give it some time in trunk first, just in case. [05:20] ok [05:24] there's some potential for waste in letting things age in trunk [05:24] though i also kind of like the ieda [05:24] idea [05:39] jelmer: are you awake perchance? [07:31] spiv, still here? [07:43] hi all ! [07:44] wow, I was about to nudge core devs to land their approved patches and... https://code.edge.launchpad.net/bzr/+activereviews is almost empty, yeah for telepathy ! [07:47] hi vila [07:47] yeah! [07:47] and, i think [07:47] less +patches bugs than when we started [07:47] maybe no +high ones? [07:48] I haven't looked at +patches yet, but +workinprogress is reasonably short too [07:50] those aren't real urls [07:50] yet [07:50] they should be [07:50] poolie: sure, but we understand each other here [07:51] yes [07:58] jelmer: ping [07:58] poolie: actually, there is a +patches one now Ithink [07:58] it was announced at portland [07:59] maybe its only for ubuntu, in which case a nudge to Jorge might be useful [07:59] not deployed yet i believe [07:59] continuous deployments come on down [08:01] * igc dinner [08:08] k, i need to finish https://bugs.edge.launchpad.net/bzr/+bug/368931 then stop [08:08] Ubuntu bug 368931 in bzr "Rename may fail when file and directory have the same name differing by case" [High,In progress] [08:18] poolie, lifeless : I replied on https://code.edge.launchpad.net/~vila/bzr/move-test-servers/+merge/18960 , we can discuss it here and now if you will [08:19] spiv, igc, jam, everybody who is interested too ^ [08:20] mwhudson: ping [08:25] vila, can you summarize where it's actually up to? [08:25] i'm broadly + on just merging it before perfecting it [08:26] hey vila [08:26] poolie: test servers are out of the bzrlib.transport hierarchy, tests are passing [08:26] Does that include MemoryServer? [08:27] spiv: hey happy father ! :D [08:27] It would be a shame to move that twice, and thus cause Launchpad to have to update their code to match twice. [08:27] spiv: yes, but not ChrootServer and PathFilteringServer which *are* used are true servers (MemoryServer isn't) [08:27] MemoryServer is a real server. [08:28] they do use MemoryServer [08:28] in lib/lp/codehosting/vfs/branchfs.py [08:29] poolie: outside of tests ? [08:29] Yes. [08:29] hmm [08:29] it seems strange but they do call it [08:29] vila istm that if you import transport.memory it is reasonable to get MemoryServer too [08:30] we mostly want to avoid it for real protocols [08:30] poolie: that was the root cause of needing testools when using sftp... [08:30] let me try [08:30] memoryserver was? [08:31] poolie: no, leaving a test server in the bzrlib.transport hierarchy [08:31] right [08:31] MemoryServer doesn't have much risk of depending on external dependencies. [08:31] i think we should move that one [08:32] right [08:32] and also, if you are using a memorytransport you must necessarily also use an in process memory server [08:34] poolie: nice catch, let me look at the fallouts [08:48] well it was spiv really [08:48] i would not have guessed lp used it [08:49] spiv: nice catch to you then ;) [08:51] spiv: By the way, Marie an I noticed that your Vincent's mother is called Mary while her (Marie's) father is called Vincent, which kind of make sense since we leave roughly at the other side of the planet... but I wonder how *they* will name their children (except I think I just don't want to know, that's far too close to playing with the quantum universe equilibrium)) )) (just to be sure) [08:52] vila, can you send a pp mail before you go? [08:52] Pah, lousy quantumn universe equilibrium. What'd it ever do for me? [08:53] poolie: Some sort of summary you mean ? [08:53] poolie: or a 'I'm done, next is poolie' kind of ? [08:54] vila: I've made my case for names on the bug, whatever poolie goes with is pragmatically fine. [08:54] lifeless: ok [08:54] vila: (But I'm not convinced by .git and .ftp being siblings :)) [08:55] well, I'm not convinced we need to reserve for .git until we implement it ;) [08:55] we have .smart.server [08:55] heya all [08:55] I'd rather see .git.server [08:55] hi lifeless [08:55] and similar for CVS etc, than have it adjavent to the VFS servers [08:55] hi bialix [08:55] lifeless: IIUC you're admin of bzr ML [08:55] bialix: one of manyt [08:55] I have problems posting to ML via gmane [08:55] bialix: hmm [08:56] at least it was true yesterday [08:56] we're not that sort of admin really. what sort of symptoms do you see? [08:56] (we only have web UI clicky clicky admin access) [08:56] yesterday my mails were not reach ML. [08:56] vila: "I'm done, we got lots of things finished, please keep the balls in the air" [08:57] poolie: k [08:57] okay, it seems jam fixed something yesterday when I'm whinning about this [08:57] bialix: your mails are not in the clicky admin interface :-( [08:57] unless they now got through [08:57] hi poolie, vila [08:57] vila, say something inspiring/exciting [08:57] poolie: :D [08:57] it is really good that we're getting on top of these things :) [08:57] bialix: hello spammer [08:57] * vila hides [08:57] ok, today is better day, at least couple of my answers reached ML actually [08:58] lifeless: poolie: sorry for disturb, I hope now it's sorted [08:58] np [08:58] let us know [08:58] if you have troubles [08:58] vila: :-D [08:58] i should really go [08:59] * bialix likes jokes of vila, no need to hide [09:10] hey [09:10] hi gerard_ [09:13] igc: ping? === mrevell is now known as mrevell-lunch === mrevell-lunch is now known as mrevell [14:06] nice lp/bzr article on ars [14:10] Tak: url ? [14:12] http://arstechnica.com/business/2010/02/an-introduction-to-collaborative-development-with-launchpad.ars [14:12] hmm, fresh :D [14:13] rubbs, Tak : thanks [14:13] np [14:14] I haven't read it all, but it seems pretty good [14:15] hi abentley, today I've encountered strange problem with shelving part of hunk with the editor [14:15] bug https://bugs.launchpad.net/bugs/520461 [14:15] Ubuntu bug 520461 in bzr "problem of partially shelve changes from 1 hunk with editor" [Low,Confirmed] [14:15] abentley: am I'm doing something really wrong this is just unsupported use case? [14:16] abentley: am I'm doing something really wrong *or* this is just unsupported use case? [14:16] rubbs: there is qbzr! :-) [14:16] bialix: have a break, read the above url, there talking about you :D [14:16] rats, too slow [14:17] vila: I saw the pictures [14:17] bialix, I don't understand. [14:17] bialix: I pushed your emails through the admin, yes they were trapped as potential spam [14:17] morning vila [14:17] bialix, you are actually editing a patch? [14:17] abentley: what exactly [14:17] morning jam ! [14:17] abentley: yes [14:17] morning jam! thanks! [14:18] that article links to "quickly" i didn't know that existed. That's pretty nice. [14:18] abentley: if you will look on my files in the zip you can see the end result of new file which I've edited and saved [14:19] I've tried several attempts with no luck [14:19] bialix, it doesn't sound like an unsupported use case. As long as you're saving the new version, not the old version. [14:20] bialix, I don't really have time to investigate right now. [14:20] the old version is read-only, I can't edit it [14:20] ok [14:27] hahaha - "Please stop working on this. You could be taking the jobs of programmers by offering this for free." [14:32] Tak: where is that from? [14:32] oh, it's one of the comments on the article: http://arstechnica.com/business/2010/02/an-introduction-to-collaborative-development-with-launchpad.ars/3?comments=1&comment_id=156008433041 [14:34] ah... obviously a troll [14:51] Hi there, I'm going to struggle to make my question concise, but I'll have a go... [14:51] lifeless, ends up the db changes needed for +patches won't land until 1 March. [14:51] i have a no-tree repository, which I'm endeavoring to use via light-weight checkouts when necessary. [14:52] however, 1 or two folders that I would consider "branches" (have the .bzr directory in them, and happily support checking out, with revisions then showing up in bzr-explorer) don't seem to want to merge [14:54] bzr: ERROR: No WorkingTree exists for "file:///H:/My%20Documents/Projects/FreescaleMPCCA/trunk/.bzr/checkout/". [14:54] I feel I haven't given quite enough information to make a proper question but I'm not sure what to give... [14:56] I don't know if I can help solve, but I can help clarify for others here. (help get to the bottom of the problem). [14:57] sure thing [14:57] thread_au: When in doubt, pastebin a copy/paste of a terminal window showing exact commands that you ran and what they printed [14:57] so you are using bzr-explorer with two tree less branches you wish to merge. [14:57] I'm mainly using tortoise-bzr with bzr-explorer just to keep an eye on what it considers in the shared repo [14:59] at the time of the merge are their working trees present? [15:00] only in the checkout === salgado is now known as salgado-lunch [15:00] (trunk at this point contains no revisions however) [15:01] well, it has one now, as I added one in case that was the problem [15:01] I have one treeless repo, within which I created a folder "trunk", which I ran "init" on. Then used "branch" to create a branch called "beginning". To perform work I created a lightweight checkout from beginning, which seems to commit fine. bzr-explorer reports that there are "changes not in parent branch" (as expected) [15:02] in my head I should then run "merge" from trunk folder to propagate teh changes there. [15:02] You run 'merge' from inside the/a working tree for the branch you want to merge into. [15:02] so lightweight checkout from trunk [15:02] and then merge to there? [15:03] sounds reasonable [15:04] it seems i was led astray by a bugreport i was just reading if that's the case [15:04] Being as how merge sets up information to be committed, it would be difficult to do it without a WT ;) [15:04] but bzr is magic! :P [15:04] (I was reading this https://bugs.launchpad.net/bzr/+bug/91614) [15:04] Ubuntu bug 91614 in bzr "Error messages should not include internal filenames below bzrdir" [Wishlist,Confirmed] [15:05] which seemed to say that trees were not necessary, but that was for a pull [15:05] nice bot function btw [15:06] Right, pull just moves existing revisions around, so there's no need for a tree. [15:06] Merge set up pending info to be committed, so that has to go SOMEwhere. [15:11] (just squirrelling away...) [15:20] jam: thanks a lot for your answers re: annotate, re:push/pull/1.9/1.14, lots of food for thought! [15:32] thanks fullermd and rubbs [15:32] the merge worked (well... attempted) which gave me more stuff to figure out that i have been working [15:32] and the command line feels a lot tighter I think now I'm using it [15:33] thread_au: glad you found help. sorry I couldn't help more myself. [15:34] you asked the right question actually [15:34] regarding trees [15:34] meh, dumb luck on my part ;) [15:34] so much terminology to get my head around [15:34] it's hard at first, but working through it for a few weeks will really help. [15:35] and once you get it, it's almost like a light turns on. it becomes much more easy after that [15:35] stuff like "push vs send" and "pull vs update" [15:35] (I think i have pull vs update sorted :) [15:35] at the moment, trying to figure how push/submit/send/parent branches are meant to be set up/related [15:35] yeah, those are hard, because the differentiation isn't within the term itself, which I think makes it the hardest. [15:37] and why I couldn't merge to trunk without putting in -r0..-1 [15:37]