[00:00] I think it would be an incompatible change, or at least a whole lot of shoe-horning to get optimal gc => gc via get_record_stream. [00:02] lifeless: I guess I've felt like you've been optimizing the knit => gc case, rather than the gc => gc case. And the former is transient until everyone has upgraded, while the latter is an on-going issue. [00:06] jam: I've been hammering on the interface that is used [00:07] we need gc->gc to work when the source is actually a RemoteRepository [00:07] lifeless: I suppose I also haven't seen any visibility of your work. I don't know if you just aren't committing, or if you aren't sending emails [00:08] Certainly I don't see a public URL to get your latest code. [00:08] ~lifeless/+junk/bzr-groupcompress on launchpad [00:08] and my btree-graphindex bzr branch [00:09] which has outstanding uncommitted work, because I need to fix this api [00:09] I haven't been able to spend time on the core code for a couple weeks now [00:10] helping with 1.6 stuff, analysing nasty bugs, and thinking about the interface problems [00:11] so I think you're seeing 'robert has not been working on this' [00:11] rather than 'robert has been obsessing about knit->gc' [00:14] mwhudson, have any idea how/where I can upload the 1.6 tarball in LP? https://edge.launchpad.net/loggerhead/+download isn't very helpful [00:15] beuno: i think maybe you go to the release page [00:15] beuno: which you perhaps need to create [00:16] mwhudson, ah, I see. Ok, I have to go now, but I'll release 1.6 with NEWS, announcements, etc when I come back (or tomorrow morning), unless you can think of something else we're missing [00:17] jam: before you go, what I need to understand is if you think a hint is _wrong_ or just premature [00:18] jam: if you think its wrong I'll head back to drawing boards, if you think its premature I'll accept we have a different order on the same TODO list [00:18] beuno: awesome === mw is now known as mw|out [03:45] lifeless: just premature, not wrong, I thought I made that somewhat clear. [03:45] sorry about th delay [03:45] jam: it was getting pretty angsty, I wanted to be sure [03:45] no worries about the delay; life does come first :) [03:54] jam: do you have an opinion on lexer and cc toolchain? [03:55] jam: I'm currently trying antlr3 [03:55] lifeless: I do not [04:03] lifeless: what are you trying to parse? [04:04] dirstate [04:04] initially that is [04:04] seems a bit overboard, but if you feel it is merited [04:05] As far as one I came across a while ago: http://spirit.sourceforge.net/ [04:05] it is C++ using templates [04:05] to allow you to write EBNF, I guess [04:05] boost is a very nice advanced C++ library [04:05] not necessarily something you want to use in this context [04:16] yah [04:16] so if we do C++, I'd grab boost, its nice [04:17] Honkin' big. [04:17] but I think plain C is probably best at this point [04:19] lifeless: sure, the initial docs for antlr only describe java and c++ output [04:19] * spiv doesn't like Fridays. [04:19] though it seems they have since implemented several output languages [04:21] http://www.antlr.org/api/C/ [04:21] spiv: heh [04:25] if you had to categorize bzr commands, how would you? [04:25] transfer, edit, info? [04:27] Huh, importing paste is either taking 0.0037 seconds, or 9.5. That makes starting Loggerhead a little slow... [04:27] Peng_: that seems like a bit of variation. [04:28] Yeah. Do we get to pick which it is? 8-} [04:28] lifeless: yeah, the problem is that on the download page, they say you can use the binaries for C++, C# or python, when they really mean C... [04:30] I will also say I have a hard time finding online examples [04:34] Peng_: out of cache? === abadger19991 is now known as abadger1999 [04:39] lifeless: Yeah, probably. [04:41] it's not like paste does all that much when you import it [04:41] mwhudson: 'python' [04:42] yeah yeah [04:44] python, yeah yeah yeah, python, yeah yeah yeah [04:44] so I played with freeze [05:00] lifeless: in a packet trace, are you only interested in the few frames before and after the error? [05:01] markh: I'm not interested in them at all; I want you to look at it ;) [05:01] heh :) [05:01] markh: we're looking for retransmissions, tcp errors etc [05:02] Ideally, you'd probably want at least the last few packets before it goes off in the weeds. [05:02] and to see what happens after [05:02] if it gives up I think it will send a FIN [05:03] RST more likely [05:03] fullermd: yeah mea culpa [05:03] EMEMORY [05:03] Of course, it IS Windows; so it might send just about anything ;) [05:10] jam: whats up with NEWS [05:11] jam: we seem to be jumping around with sections, I thought we had a fixed set these days ? [05:12] lifeless: I see the same ones IN DEVELOPMENT as elsewhere, what would you have expected? [05:13] lifeless: there has been some motion because of things that were in dev that got merged into a release candidate. [05:13] I tried to keep them in the same sort order, though. [05:13] I only ask because I'm running into conflict-after conflict :P [05:13] jam: also, did you know that buffer() is a zero-copy tool ? [05:13] lifeless: Is that because we started a new IN DEVELOPMENT? [05:14] lifeless: yes, but buffer() doesn't make the code more obvious, etc. [05:14] jam: As we work on memory, I expect we'll want more of it [05:17] I'm not very familar with debugging network traces. The last packet I see before the timeout is from launchpad and apparently carrying http payload. The first I see after the timeout is also from launchpad, with the TCP "F" flag set, which apparently means "end of data". [05:18] I'm using a windows network tool and I'm not sure how to export the data in any meaningful way [05:18] Well, F would be FIN, which means it's shutting down the connection in an orderly fashion ("Done", rather than RST which means more like "broken, WTF?!?") [05:19] You don't see any packets from you in the middle, though? [05:19] right [05:19] nope - I'm filtering by "source=launchpads ip or dest == launchpads ip" [05:19] I don't see how it could FIN unless it had at least seen your ACK of that last packet... [05:19] does the sequence number match ? [05:20] fullermd: I think you can FIN on shutdown() regardless of ack-state [05:20] so [05:20] * fullermd reached for Stevens. [05:20] I think we should check what the apache front-end has its timeout set to [05:20] * lifeless bets 15 minutes [05:21] spm: ping [05:21] lifeless: pong [05:21] Assuming your ACK did get through, then yeah, it sounds like HTTP keepalive. LP sent all its data, and considers that you've gotten it, and after 15 minutes of no activity, decides you're gone and closes the session. [05:21] spm: whats the persistent connection timeout configured on bazaar.launchpad.net [05:21] 15 minute keepalive timeout sounds insanely long, though. [05:21] fullermd: not really [05:21] what pastbin do you guys use? [05:21] pastebin [05:22] markh: any that works [05:23] http://pastebin.com/m6aed84b0 - but no column headers :( 2nd col is "packet number", 3rd is "time offset", "eden" is my pc [05:23] spm: we have a situation where we are seeing some http data sent to a bzr session [05:23] spm: then nothing for 15 minutes [05:23] spm: then a FIN [05:23] lifeless: hmm. not good. [05:23] spm: working theory is that packets are going AWOL [05:24] spm: and then apache is timing out the socket gracefully [05:24] spm: finding out the configured timeont on b.l.n will help [05:24] lifeless: sounds reasonable... [05:25] lifeless: sure. just getting... [05:25] if its different we can look at other things [05:25] if its not configured, it willbe the default [05:26] lifeless: looks to be default [05:26] spm: thanks [05:27] Default:KeepAliveTimeout 15 [05:27] Syntax:KeepAliveTimeout seconds [05:27] It's 5 here. But either way, it's a long cry from 15 minutes. [05:27] * lamont mutters about &%)^%^*_ tar.gz packaging of bzr snapshots, again [05:27] KeepAlive is different [05:27] isn't it? [05:27] 1) orig.tar.gz without debian/; 2) drop debian/.bzr from the source package [05:27] KeepAlive is boolean [05:27] a timeout though [05:28] lamont: i'm sure you should be asleep [05:28] lamont: bzr itself? [05:28] if it has the connection open, that is how long before it will close it even if the client doesnt IIUC [05:28] lamont: you have confused me [05:28] markh: No, KeepAlive is just a flag for whether or not persistent connections are allowed. [05:28] lifeless: see lauchpad.net/~ppa-bzr-beta/ [05:28] ]+archiuve [05:28] yes - [05:28] markh: KeepAliveTimeout is the time after which it closes even if the client doesn't. [05:28] and if it is used and the connection remains open, the server has a timeout [05:28] lamont: bzr upstream does not have debian in it [05:29] lamont: but the packaging rules are a bzr branch [05:29] the package in the ppa doesn't _HAVE_ an upstream tarball [05:29] fullermd: yeah, I think that is what I'm saying :) [05:29] which is a different timeout than we are looking for? [05:29] lifeless: which, specifically, is my complaint [05:29] lamont: uploaded as a native package? [05:29] yes [05:29] (I don't think there IS a timeout for max length of a persistent session, short of MaxKeepAliveRequests * (KeepAliveTimeout * .9999999) [05:29] OTOH, at least 1.6rc2 has dapper source for me :-) [05:29] lamont: file a bug [05:29] lamont: the folk doing these uploads are not DD's [05:30] yeah [05:30] I'll do it once I'm awake again, as mwhudson so aptly points out [05:30] and on that note, bed. [05:31] still [05:31] 1/60th of the time out is still damn suspicious [05:32] hi, how do i make a minor edit in an already commited revision, without another commit? [05:33] bvk: uncommit [05:34] Anyway. I'm pretty certain a FIN won't be set if there's outstanding un-ACK'd data, no matter what. shutdown(2) will send the queued data and wait for it to be ACK'd before doing it's half-close. [05:35] AfC: thanks, i will try it out [05:35] bvk: (followed by a new commit, of course) [05:36] bvk: (assuming, a) that you are trying to fix the most recent revision, and b) that you haven't sent it anywhere public) [05:38] AfC: it seems, i cannot go down more than a recent commit and make a fix :-( [05:39] Barring really heroic and unportable measures, I don't think there's any way for userland to 'take back' send(2)'t data; once it goes down there, TCP will reset the connection without any more intervention if it can't get through... [05:40] markh: just been looking at that network trace pastebin. those first two packets (4188/89) appear to be identical? Which seems a tad broken. [05:40] AfC: say, i have revisions 1,2 and want to make a minor edit in 1 (but not in 2) revision 2 also needs to be uncommitted [05:41] shall I go back a few packets? [05:41] bvk: yes, which is why you should just be making a fix and committing revision 3. [05:42] AfC: is there anything like mercurial patch queues? where i can do hg qpop; hg qpop; edit; hg qrefresh; hg qpush; hg qpush ? [05:42] markh: yeah... something just seems really odd... I'd expect to see more "stuff" happening. retries whatever. [05:42] markh: If you can use something like Wireshark, you can do things like show a trace of the HTTP session, which could be helpful in seeing if it really is "all there". [05:42] those 2 packets look identical here too [05:44] Mmm. That trace looks all sorts of messy... [05:44] bvk: there is the 'loom' plugin [05:44] http://pastebin.com/m78da686f has from the GET request [05:44] I'll look into wireshark... [05:45] Look at those 4th and 5th lines again. [05:45] First, the 4th line is launchpack ACK'ing your packet in the 5th line. So the order is messed up. [05:45] And secondly, those are from a different session than the first 2 lines (can't tell about the 3rd); the local port is different. [05:46] mwhudson: i tried loom plugin, but i couldn't get that how to do it right :-( loom doesn't have anything equivalent to hg qrefresh :( [05:47] mwhudson: i still need to make a commit for minor fixes and it is recorded as another revision [05:47] i don't know what qrefresh does, so can't really answer that :) [05:48] mwhudson: its what commit in aloom thread does [05:48] bvk: in loom you just do a commit on that thread [05:48] mwhudson: qrefresh updates the current working patch (in a queue of patches). one patch acts like one revision, so multiple qrefreshes on a single patch will not result in multiple revisions [05:49] I think only one bzr was running in that trace - I was being careful to wait while the 15 minutes expires and not doo anything else with bzr [05:49] I'll see how I go with wireshard [05:49] k [05:50] bvk: looms map revisions into a stack rather than replacing revisions [05:50] bvk: the stack has the delta each revision needs when submitted upstream [05:51] But yeah, that FIN 15 minutes and 10 seconds later is from a different TCP session (local port 60013 instead of 60012), so it's no relation to the other packets. [05:52] That first connection apparently disappears totally after that line 7 packet. Which is absurd; you're running locally, you should be able to see your ACK of it no matter what, even if the other end doesn't. [05:52] lifeless: um...if i go down-thread, do some edits and did up-thread, will my top thread gets the edits merged? [05:52] so, we were looking at the wrong machine in the DC [05:52] bvk: yes, as a pending merge like normal bzr merges [05:53] bvk: diff -r thread: at any point shows you the overall pending diff [05:53] lifeless: so, i have to do one more commit in all up-threads from the point of edits? [05:54] fullermd: agreed - good catch on that. which also begs the "what is actually open" question... [05:54] bvk: yes, there are some plans to streamline this [05:54] lifeless: ok [05:54] (of course, it's an assumption that that HTTP data packet is part of the 60012 connection, since it doesn't show ports or sequence numbers or whatever on those packets, but I think it's a reasonably good one) [05:55] markh: might be worthwhile seeing how many, if any?, connections you have open to 91.189.90.161; netstat -an | fgrep 91.189.90.161 [05:56] lifeless: one more question, when i do a merge from up-thread, all its revisions are automatically logged in the commit message, can i avoid that with a simple merge notes? [05:56] none apparently :) I'm installing wireshark now [05:56] bvk: they are not logged in the commit message for me; why do you say they are ? [05:58] lifeless: i saw all revisions logged with some indentation :-( [05:58] fullermd: yeah, the timing is too tight. but still ... coincidence is possible. :-) [05:58] bvk: thats display [05:58] bvk: try e.g. bzr log --short [05:59] copying commit messages around like that would be horrible duplication [06:00] I'm pretty clueless with this :( fullermd - any clues about the syntax for the wireshark filter I'd need? [06:00] or spm of course :) [06:00] "host 91.189.90.161 and port 80" should do it [06:01] (should show both directions) [06:01] markh: just grab the lot - post filtering with wireshark is a doddle. or ^^ :-) [06:01] it says thats a syntax error [06:01] * markh looks at help [06:03] lifeless: ok, short is not displaying them :-) [06:04] markh: are you applying that filter as you capture, or post capture? the eg fullermd gave is "as you capture"? The post capture filters are very different syntax. [06:05] um - in the toolbar "filter" box :) - haven't started capturing yet [06:05] Ah! :-) [06:05] No not that one. :-) [06:05] "start a new live capture" [06:06] ... or "capture options"; should then see a "capture filter" - put the filter in there. [06:09] The latter is what I always do (make sure you choose the right interface) [06:10] ok, running. Now to retry a few times until it fails... [06:18] a few "dupe ack" messages are flying by, but its still working... [06:19] ahh - here we go :) bb in 15 :) [06:22] markh: :-) Once you close the sniffing; go looking for the http GET request that timed out - it should be fairly obvious; select that line; right click; "Follow TCP Stream" - will filter packets to only that connection. [06:22] nice :) [06:23] I'd save it right off too; that way you have a copy around to work with. [06:43] fullermd/spm: so I've got a capture - but struggling to get a similar text format out for the selected packets. What's the best way for you to see the data? [06:43] upload a .scap somewhere? [06:44] markh: Well, you can try filtering down to just that session, then saving that out to a pcap file, and seeing how big that is. [06:44] markh: sure - works for me [06:44] bbs [06:44] If it's not huge, we can just grab that and poke at it. [06:44] (or if the whole capture isn't too huge, that would work too, with less effort) [06:48] fullermd/spm: http://starship.python.net/crew/mhammond/bzr-hang-2.zip (151,340 bytes) - it should be from the most recent GET (a few seconds and many packets before the hang), and a dozen or so packets after. [06:57] OK, that's a lot of dupe ACK's in a bunch there. Couple times. Weird. [06:57] * markh doesn't know what happened to his isp then. [06:59] Lot of partial packets there; your MTU is higher than somewhere along the path, which is causing a lot of fragmentation. [06:59] That shouldn't break anything, but certainly exposes more edges. And probably messes with your performance a bit. [06:59] quite possibly my very old dsl modem [07:00] If we go to packet 687, which is the last one before the pause, right-click and 'Follow TCP Stream' gives a text dump of the session. [07:00] There's two things to note. [07:00] The first, is that looking at the very end, it's obviously in the middle of a line, which confirms that you're not actually getting all the expected data. [07:01] The second, is that there IS a proxy; see the HTTP response header: [07:01] Via: 1.0 proxy3.mel.dft.com.au:80 (squid/2.6.STABLE18) [07:02] yeah, my isp I believe [07:03] So, that's suspicious. HTTP breakage unrelated to proxies happens, but not near as often as related. [07:04] lifeless may know more as to whether there's something particular about that version that might be tripped us up. [07:05] australian ISP's as a rule have an intercepting squid [07:05] squid had a known, serious bug with range requests [07:05] heh - well there you go :) [07:05] in that version? [07:07] yes [07:07] .19 fixes it [07:07] but they should 2.7 or 3 anyhow [07:07] http://www.squid-cache.org/Versions/v2/2.6/changesets/11996.patch [07:07] bugger - here goes another support request that will end up in the same bucket my request for them to upgrade their SpamAssassin did :( [07:08] also [07:08] http://www.squid-cache.org/bugs/show_bug.cgi?id=2329 [07:08] www.squid-cache.org bug 2329 in src "Range header is ignored for TCP_HIT" [Normal,Resolved: duplicate] [07:08] which is fixed in .20 [07:09] (actually, I could be full of crap on my first point above; I guess the range could just end right in the middle of that line) [07:09] fullermd: single ranges can, multi ranges will be multipart wrapped [07:09] Australian ISPs run proxies? Ew. [07:10] It's multi-part wrapped. 2 ranges. [07:10] fullermd: so cutting off part way == incomplete [07:10] I forgot that it was ranged, so I assumed it would have a full index, which wouldn't fail in middle of the line. [07:10] The range is a little weird, though... [07:10] Range: bytes=33100-123726,124238-190665 [07:10] thats GraphIndex [07:10] We really care about saving 500 bytes in the middle, when we're pulling >150k? :p [07:10] no [07:11] we want a few hundred bytes from 150000+ [07:11] and its remote so we expand it to 64K [07:11] we also want some bytes from a couple of lower spots, apparently [07:12] Yeah, it just seems weird to me that they expand to those blocks, but don't just collapse it into a single range. [07:12] that squid bug appears to only happen for cached content? [07:12] * fullermd does a quickie test of the range [07:13] markh: the second bug yes [07:13] markh: but note that the first bug will cause the second to show [07:18] Oh, I see what you mean. I missed that it was lacking the MIME boundary marker. [07:18] So I was right, for the wrong reason 8-} [07:20] markh: I'm not convinced squid is the root cause thouh [07:21] markh: you are seeing anomalous behaviour [07:21] Yeah. There's enough weirdness in there to go around. [07:22] a quick question: is bzr-fastimport format identical to git-fastimport format? [07:22] All the dupe ACK's, in several clusters through the trace, are locally generated, rapid-fire. [07:22] xshelf: bzr-fastimport read git-fastexport if thats what you're asking [07:22] That may or may not be related to the near-total fragmentation. [07:23] I think there's some SACKtion going on, but I don't know SACK well enough to say much about it without a lot more digging than I have time for tonite :| [07:23] lifeless: i was looking at reusing git-p4 for bzr [07:24] xshelf: yes, I believe someone is working on that [07:24] there is stuff on the list about this [07:24] lifeless: i read it in the list, let me followup with that person [07:46] lifeless: hi. [07:46] jml: bzr+http? :D [07:46] Peng_: working on it! [07:47] Cool. [07:56] jml: hi [07:56] lifeless: so, tomorrow. [07:56] lifeless: we're missing a *time* [07:57] and a place [07:57] I've been trying to grab Lynne, no luck [07:57] lifeless: Kensington is the place [07:57] details details details; how do I get there? [08:03] markh: is there mtrr for windows? [08:23] no idea! [08:24] I see rio.py has: if isinstance(value, str):\n value = unicode(value) - that is always going to be suspect isn't it? If the string is utf8 or anything else that's non-ascii, we are doomed [08:25] some russian dude is hitting it in 1.5, and it looks like he still might in 1.6 [08:27] http://beerpla.net/2008/05/12/a-better-diff-or-what-to-do-when-gnu-diff-runs-out-of-memory-diff-memory-exhausted/ [08:28] agreed [08:28] is there a bug? [08:31] https://bugs.launchpad.net/bzr/+bug/256550 [08:31] Launchpad bug 256550 in bzr "locking fails with non-ascii characters in host/username/something (russian Vista)" [High,Triaged] [08:31] yep [08:31] oops :) [08:31] * markh answered the bot :) [08:32] the problem is not rio, the problem is using non-ascii bytestrings for hostnames [08:32] one path I can see is _auto_user_id() calls socket.gethostname(), which returns a string and may be non-ascii in that case [08:32] yes :) [08:32] personally I'd just decode is using the user's locale [08:33] on windows the encoding would be 'mbcs' (which is also filesystemencoding) - but yeah [08:33] hard path to test - monkeypatching maybe? [08:33] no, that's the filesystem encoding [08:33] it would be cp-something [08:34] windows is likely to return a string that went via WideCharToMBCS (or however it is spelt), in which case "mbcs" would be the appropriate encoding to use IIUC [08:35] the same value directly from the api via unicode would also be an option [08:37] win32api.GetComputerNameEx(0) returns unicode :) [08:39] but - rio is still potentially broken in the future. ISTM it should probably throw an exception for a string [08:39] as even a utf8 string would blow it up today [08:39] well, is does, UnicodeDecodeError :) [08:39] :) but only when it actually contains non-ascii [08:40] it should raise an exception *every* time it gets a string, as it means one day a Unicode error will happen that is hard to reproduce :) [08:41] yeah, I suspect that would break a lot of bzrlib code [08:41] well, it could be argued that code is already broken for some users [08:41] true [08:52] beer-oclock! [09:06] rio probably wants to be asserting on bytestrings rather than decoding [09:21] Hmm [09:21] Will bzr have something like this: http://www.gnome.org/~federico/news-2008-08.html#12 and http://treitter.livejournal.com/7769.html ? [09:21] interactive rebasing/stacking patches [09:23] * AfC writes uws a shell script [09:23] :) [09:25] AfC: Eh, how would that work? [09:25] AfC: This is about merging multiple commits into one [09:25] so that the history is cleaner when merging into mainline [09:25] [Ok, switching back to reality: I know a goodly number of people around here respect (and in some cases, including my own, absolutely worship) the UI that was presented by Darcs. Nothing to do with patch commutation vs tree snapshot issues; but the console UI was bloody brilliant in its interactiveness and consistency] [09:27] uws: well, given that rebase is ultimately just a wrapper around `bzr merge -r X..Y ../theirs` (for X not in mine) [09:27] uws: it's eminently scriptable [09:27] uws: yes [09:28] uws: there is a bug open on rebase -i [09:28] (ok, so rebase has nice logic for moving forward and backwards / continuing as conflicts arise) [09:28] uws: it has somethoughts on how to make it happen [09:28] lifeless: will that also make it possible to "collapse" multiple commits into one? E.g. a real patch + 2 subsequent typo fixes [09:28] uws: sure [09:29] uws: I mean, its basically uncommit -r -3; commit [09:29] uws: and then rebase replay after that [09:30] uws: note that there is a way to do all that rebase does in terms of presenting things without sacrificing history; for the case where you need to evolve a patch-branch rather than simply fake up work done [09:31] lifeless: ...which is? [09:32] * AfC guesses Robert's loom concept [09:33] Something that helps merging stuff into a branch chunks would also do the job right? [09:33] so that if history is like this: [09:34] add-feature-1, fix-typo, fix-typo [09:34] add-feature-2, fix-typo, fix-another-typo [09:34] i.e. 6 commits [09:34] that you can create a branch (preferably in place) that is like this: [09:34] add-feature-1 (add-feature-1, fix-typo, fix-typo), add-feature-2 (add-feature-2, fix-typo, fix-another-typo) [09:35] where the parenthesized commits are merged revisions [09:35] uws: this is going to sound silly, but why not just take a branch at point 0 [09:35] something like "bzr collapse -r 1:3" which will give you an editor with all commit message [09:36] so you can assemble a new commit messte from these [09:36] uws: then merge from feature-1+fix-typo+fix-typo, [09:36] uws: then merge from feature-3+fix-typo [09:36] AfC: Yeah, that's the same net effect. [09:36] you'll end up with two left hand side revisions (merges, as it happens) that you can write up to your heart's content. [09:36] but it's cumbersome [09:36] More cumbersome that screwing around with rebase and history erasure? [09:37] No, what I described a few lines back doesn't change history, does it? [09:37] it just "groups" a few revisions into a merge, and then does the same again [09:37] so that a "bzr log" will list only the 2 groups at the top levle [09:37] [as an aside, I have a slightly different problem, which is that the left hand edge merges are NOT what are significant in our project, and I'm getting rather tired of writing the same detailed log message again and again as features get merged up] [09:38] uws: {shrug} [09:38] uws: that is exactly how Bazaar operates today [09:38] uws: so I guess I'm a bit vague on which part you consider cumbersom [09:38] e* [09:38] AfC: Well, I branch a project [09:38] (one possible point that's missing: you can do a merge even if there is no divergence) [09:38] (instead of pulling) [09:39] AfC: then I start hacking [09:39] commit new feature, fix a syntax error [09:39] yup [09:39] but when my work goes back into mainline I don't want the typo fix to show up so prominently [09:40] I want to present my branch as a few self-contained revisions (which may be merge revisions containing also the tiny typo fixes) [09:40] right now it seems I can only do this with a 2nd personal "helper" branch in which I merge selectively [09:40] uws: well, you either cherrypick, thereby losing that history completely, or you merge it, and hope that most people don't pay much attention to non-left-hand-edge revisions. (`bzr log` is so biased; `bzr viz` is not) [09:41] I don't like cherrypicking that much (for the reasons you stated) [09:42] uws: is the source branch a [bzr-svn] checkout in this case? [09:42] if it is not, [09:42] then it's already capable of being the staging area for you to create the merges that are "cleaner" [09:42] if it is, then really you need a temporary 2nd branch to do the work in before bringing it back to the checkout [09:43] * AfC is ignoring the --local capabilities, which he doesn't know anything about unfortunately [09:43] AfC: Yes it is [09:43] I thought so [09:43] In that case, look at it this way [09:43] AfC: --local is just committing without having stuff in the bound branch [09:44] the bzr-svn branch [checkout == slaved to upstream] really wants to be kept pristine as a copy of upstream [09:44] next non-local commit will just push the whole bunch on top of the bound branch [09:44] well there you go [09:44] AfC: I have a trunk branch, which I don't hack on (it doesn't have a workign tree) [09:44] then I have my own branch [09:44] I keep trunk/ up to date [09:45]

CRACK