Re: [Monotone-devel] the changelog editor branch is ready for review
On Sun, Apr 11, 2010 at 12:38 PM, Thomas Keller wrote: > > If there is text in _MTN/log then it is displayed in the changelog > section. > > Ah, didn't thought of this - nice! > > > We could choose to omit this section unless there is something in > _MTN/log. > > Yes, I'd say so. > Done. > > I've been wondering about a line following the instructions like: > > > > *** REMOVE THIS LINE TO CANCEL THE COMMIT *** > I've also cleaned up the instructions a bit and added this explicit cancel line. > Usually you can cancel the commit simply by not entering a commit > message. I'm not sure we need to have another way of cancelling a commit > If there is text in _MTN/log then there will be a commit message that you need to remove. The original text will be preserved in _MTN/log but I only know that from looking at the code. I would expect people to be reluctant to remove their entire message to cancel the commit and hope that their message was preserved somewhere. > The problem I have with %F is that it simply expands to the ISO Y-m-d > format which is not at all localized. Maybe we misunderstood each other > here, I thought ahead already and headed towards condition-like code > which sets %F in some locales and %x in others... this was the thing I > wanted to prevent. > No worries. I've left the default formats as they are on mainline and they work fine here, as long as the dates are between 1969 and 2068. > > Trimming is probably required if we choose to left align the headers > anyway > > so I should probably just do that. > > Right. > Done. > The right-aligned version seems to be the better choice. > Oops. I had the left aligned version done before your message. Let me know if you think we should change it. I have a very slight preference for the left aligned version now. In emacs shell-mode there is some colorization done by default and the left aligned headers are colored differently that other output lines. This doesn't seem to work with the right aligned versions. I'm not stuck on this and will change if you have a strong preference the other way. Hrm, I haven't thought of the "comment" cert at all, is this a much used > feature after all? If not I'd probably don't care about it and would > display it like any other cert value we have. > I'm not quite sure what you mean by this. Comment certs are much like changelog certs, for the few that appear in the monotone database anyway and are quite likely to be multi-line comments so displaying them like the Date/Author/Branch certs doesn't make a lot of sense. > The log output already uses "---" as revision separators, so it might be > better to find a different separator for this then. > > Wrt the double comment / changelog values - I solved this in recent > guitone versions twofold: At first I group a list of cert pairs by > signer, so its clearer which set of certs have been added by which > signer (while this of course gives the user no temporal or any other > information, we'd need the long discussed cert flag day for that > purpose). Secondly if there is more than one changelog cert (and I only > handle changelog certs special here, completly forgot about comment > certs) from one signer, I group both under one "Changelog" entry and > separate both by a horizontal line - pretty much what you propose here. > What log will do at the moment is produce multiple ChangeLog: entries with the header preceeding each one. > Right, there is only one small nitpick I have with a syntax like > "Changes:" - this pretty much then looks like a cert and in total like > the continuation of the header section. To make it clearer that this is > not the case I thought adding another separator line might be a good > idea, but I'm open for other ideas here. > I'm not sure that representing the changes similar to the certs is good or bad. The latest version is using "ChangeSet:" as the header for these summaries but I'm still open to suggestions. I think we shouldn't make it too smart - it should be enough if it looks > for the four most used certs - Date, Author, Branch and Changelog - and > checks their syntax and single existance (to prevent the buffer > duplication issue). Then, if it finds other Key: Value pairs in the > header area, it should probably just read and add them as additional > certs. Maybe its even a good idea to follow some of the basic rules of > RFC2822 here, esp. when it comes to newline handling? (Of course we do > not expect full CRLF's and 7bit ascii here... but basically giving the > user something which looks and reacts familiar.) > At the moment I'd rather not get too far into this. Would we read a Foobar: header and generate a "foobar" cert after converting the header to lowercase? > On a completly unrelated note: one thing I haven't had in mind yet is > how the new functionality reacts on branch changing - I've edited > _MTN/options and set a new branch. mtn status told me that nicely > (though I wonder where the additiona
Re: [Monotone-devel] Time for a release
Zbigniew Zagórski wrote: Hi! 2010/3/8 Timothy Brownawell mailto:tbrow...@prjek.net>> empty_environment needs to copy in all the DLLs that the monotone executable uses. It has a hardcoded list, which I'm guessing isn't quite right for your environment. Do you know if Windows has a (non-gui) 'ldd' equivalent that we could use to get the list right? I've faced this problem last time and result is that the only known tool - depends.exe [1] has also CLI interface. It's a little awkward so i've made simple wrapper [2] that makes readable "ldd" greppable output. [1] http://www.dependencywalker.com/ [2] http://pastebin.com/wxreDxFu Thanks! The empty_enviroment test will use this now for windows/mingw, but currently not cygwin (just because I don't have Cygwin set up to test it with). This apparently is included with Visual Studio, and should work automatically in that case without needing to add things to %PATH%. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] the changelog editor branch is ready for review
Am 11.04.10 05:32, schrieb Derek Scherger: > On Sat, Apr 10, 2010 at 1:28 PM, Thomas Keller wrote: >> >> While I appreciate this unification, I think the "ChangeLog:" display in >> mtn status is bogus and should be removed, no? > > If there is text in _MTN/log then it is displayed in the changelog section. Ah, didn't thought of this - nice! > We could choose to omit this section unless there is something in _MTN/log. Yes, I'd say so. >> I agree that as long as the changed data (well, at least the changelog >> entry itself) is preserved somehow, we don't really need a magic line. > > I've been wondering about a line following the instructions like: > > *** REMOVE THIS LINE TO CANCEL THE COMMIT *** > > just to make it completely obvious as to how you cancel a commit although > that is a bit obnoxious. Usually you can cancel the commit simply by not entering a commit message. I'm not sure we need to have another way of cancelling a commit - after all its fairly easy to undo a commit even after it happened by triggering kill_rev_locally (an über feature would be to have kill_rev_locally store the log message in _MTN/log, but I think this is too much :)) >> Well, I think this is actually a locale bug and we should not work >> around that with custom code. Instead it should be noted in the >> documentation for the changelog editing feature that in some locales >> issues like this exist and that the user can change the default format >> "%x %X" via the get_date_format_spec hook. > > There's no custom code to deal with this. I was just wondering if %F would > be a better default than %x which can have issues in some locales. I'm fine > with leaving things as they are and mentioning it in the docs too. The problem I have with %F is that it simply expands to the ISO Y-m-d format which is not at all localized. Maybe we misunderstood each other here, I thought ahead already and headed towards condition-like code which sets %F in some locales and %x in others... this was the thing I wanted to prevent. >> While playing around I've noticed (positively) that whitespace around >> the ChangeLog entry is stripped off, but I also noticed that the space >> after the colon of an entry needed to be preserved in order to let it >> not bail out. > > It's fairly pedantic at the moment and I've been wondering whether trimming > whitespace off of the localized cert headers would be a good idea. Currently > it looks for exact matches of the localized headers, spaces and all. Well, if translators add additional whitespaces at the end of a cert key this should be considered a bug. > Trimming is probably required if we choose to left align the headers anyway > so I should probably just do that. Right. >> This is a little criticism I have - right now the overall text layout >> could be improved because it looks a bit clumsy and is hard to grasp - >> properly indenting the cert keys could already help. > > Agreed. So do we want the headers left aligned like this: > > Revision: acadeb019c234418924525f9c4387b03e2ce35bc > Parent:89e8ee147a8555cd26ff2a39023d488ad0fe4b72 > Author:de...@echologic.com > Date: Sat Apr 10 12:10:52 AM 2010 -0600 > Branch: net.venge.monotone.experiment.changelog-editor > > ChangeLog: > > or right aligned like this: > > Revision: acadeb019c234418924525f9c4387b03e2ce35bc >Parent: 89e8ee147a8555cd26ff2a39023d488ad0fe4b72 >Author: de...@echologic.com > Date: Sat Apr 10 12:10:52 AM 2010 -0600 > Branch: net.venge.monotone.experiment.changelog-editor The right-aligned version seems to be the better choice. > ChangeLog: > > Note that I've added a line before the ChangeLog: header because it's longer > than the others and looks odd otherwise. Multiple ChangeLog: and Comment: > headers would presumably each have blank lines around them. Hrm, I haven't thought of the "comment" cert at all, is this a much used feature after all? If not I'd probably don't care about it and would display it like any other cert value we have. >> What about separating the end of the changelog section from the changes >> section with another "" line? As I already mentioned the changelog >> is cleaned off of leading and trailing whitespaces and the layout is >> fixed for the other certs anyways, what about removing the ChangeLog: > > Would another line of "---" be ok in the log output as well? Keeping the > output from status, commit and log consistent if possible seems like a nice > quality to me. Omitting the ChangeLog: header completely is ok, except that > there may be multiple changelog certs and clearly indicating this is > probably good. Ditto for Comment certs. The log output already uses "---" as revision separators, so it might be better to find a different separator for this then. Wrt the double comment / changelog values - I solved this in recent guitone versions twofold: At first I group a list of cert pairs by signer, so its clearer which set of certs have been added by
