Re: Mtn project...
On Tue, Apr 6, 2021 at 12:05 AM Lapo Luchini wrote: > On 2021-04-06 01:13, grarpamp wrote: > >> I know the project is being still for a long time, but I think an 1.2 > >> release that officially supports Botan2 would be in order > > > > Put the monotone project up on github, all of the... > > code clone / export, website, wiki, ticket dump, releases, etc. > > Graydon did upload an old version, but it's very old and doesn't have > issues. > (TBH it's described as "historical snapshot" in the about) > > Uploading a new one shouldn't be difficult. > If it helps, I've got a slightly more recent copy of the monotone repo on github here https://github.com/dscherger/monotone There's some instructions on how it was created using mtn git_export as well. I'm not sure how Graydon created his snapshot, it doesn't look like git_export existed when it was done. Cheers, Derek
Re: [Monotone-devel] interoperating with git
It's nice to hear that the exporter is working for people. Cheers, Derek On Fri, Nov 23, 2018 at 8:30 AM Lapo Luchini wrote: > Stephen Leake wrote: > >>> A better option with monotone and git is to export the monotone db to a > >>> git repository. I have not done this yet, but others have reported > >>> success. Search this mailing list archive. > >> > >> That seems like a one-time activity, perhaps not what I want for an > >> ongoing development. Or is there something I need to know about that I > >> don't? > > > > It's ongoing; you can update the git repository with new commits from > > the monotone db. > > Yep, I'm doing this for my "public" opensource projects, like asn1js: > > Take a look here: > https://github.com/lapo-luchini/asn1js/blob/master/mirror_to_github.sh > > -- > Lapo Luchini - http://lapo.it/ > > > ___ > Monotone-devel mailing list > Monotone-devel@nongnu.org > https://lists.nongnu.org/mailman/listinfo/monotone-devel > ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Monotone on Github?
I have a slightly older export here as well https://github.com/dscherger/monotone but I'm not keeping it up to date. both have been exported via the git export feature. The problem with > that is: incremental updates are not supported. > I'm not entirely sure this is true, I haven't looked at this stuff in a very long time but when I originally implemented the git export feature I think I did allow for incremental updates and the docs seem to indicate that this might actually work. See here http://www.monotone.ca/docs/VCS.html#VCS The --import-marks and --export-marks options are similar to those documented in git-fast-export(1) and git-fast-import(1). These may be used for incremental exports and may also be useful for repository verification. The marks-file is read on startup if --import-marks is specified and all marked revs are excluded from the export. The marks-file is written on completion if --export-marks is specified and will contain marks for all revs that were exported in addition to any marks that were read on startup. It is safe to use the same file for both --import-marks and --export-marks but different files may also be used. No idea if this would support what you're after or not but there's a chance. Cheers, Derek ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] changelog editor issues
On Fri, Sep 10, 2010 at 3:11 PM, Francis Russell fran...@unchartedbackwaters.co.uk wrote: Stephen Leake wrote: The first draft is now pushed. I think it does everything everyone asked for; give it a try. Hi, I took a quick look and it's certainly an improvement over the previous template. Thanks for all the work. These are my comments: - There's a missing space between Date: and the date. - I think something is seriously wrong if we actually need to tell users where to place their commit message. The only person who I can imagine who would need this message is a complete first-time user who has never touched any form of version control before. In this case I'm pretty sure they'd be using the tutorial. I'd consider deleting that line entirely. Alternatively, the next comment replaces it. - subversion and mercurial handle aborting commits by checking to see if the message was empty. Perhaps the REMOVE and Enter a lines could be replaced by: -- Enter a commit message or leave empty to abort -- and check to see if the white-space trimmed changelog has any characters. I think that is still superior to that whole line deletion thing as it requires less effort to abort. Also, it has far fewer capitals :). One thing to keep in mind is that you can enter text in _MTN/log and it will appear in this section of the template. If you want to abort a commit when you have stuff in _MTN/log you will have to remove the entire message, unless there is something like this line. Cheers, Derek ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] changelog editor issues
On Sun, Sep 5, 2010 at 1:37 AM, Stephen Leake stephen_le...@stephe-leake.org wrote: There was discussion of whitespace trimming; with this format, only trailing blank lines need to be trimmed from the commit comment. Possibly a hook to do user controllable message cleanup might be good, although that may be overkill. The one thing I was hoping to be able to avoid was that any trailing blank lines would appear in the committed message. I use emacs fill-paragraph often enough and wrapping the old MTN: prefixed text into my messages happened on too many occasions. There was a suggestion that the signing key could be different from the author; this is possible on the command line, but not in this editor format. Isn't the signing key the key that is used to sign the author, date, branch and changelog certs? The Author line is just for setting the textual value of the author cert so it is possible in this format. (i.e. the Author: Date: Branch: and Changelog: lines in this format are equivalent to the --author, --date, --branch and --message options to the commit command) There was a suggestion to allow editing the changelist section, to exclude files from commit (similar to the --exclude command line option). That is complicated; let's leave that for later, or at least in a separate discussion. Agreed. I propose that we adopt this format, with the addition of a 'key: ' line under the 'Author: ' line; any objections? I'm not sure about adding a key line, unless you intend for it to set the key used to sign all of the other certs as the --key option does now. I think I would prefer to have the headers actually be headers even if there are fewer of them but it does seem that almost no one else shares this preference so I'm going to have to let it go. Derek; do you have time to work on this? I can do it if not. I keep meaning to get to it but never seem to be able to and I don't want to hold things up so if you have time please go ahead. Cheers, Derek ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] nvm.options
2010/8/14 Timothy Brownawell tbrow...@prjek.net This is changed now. --verbosity is gone, --reallyquiet and --debug are deprecated, and there's a new --verbose / -v You rock! Cheers, Derek ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] 0.48 rants
On Mon, Jul 19, 2010 at 8:47 AM, Ethan Blanton e...@psg.com wrote: Well, I, for one, would like to clarify that I didn't intend my comments to be wholly negative; I think maybe you grokked that from the first time, but let me say it anyway. ;-) I *like* the editable Good to hear! headers, and I think they're a net benefit. I don't like the prose preceding the commit, for two reasons: 1) The new format is just complicated enough that you *have to read it*, and I'm so used to ignoring VCS boilerplate (it's pretty common for VCSes to dump some sort of instructions that can be safely ignored unless, for example, you want to abort a commit) that I did so. Agreed, and once you've read it *once* you probably never need to see it again. 2) The first blank line in the commit is within the boilerplate, but adding the commit message there is invalid. There was a bug which additionally caused any text added there to be lost forever, but I think maybe tommyd fixed that(?). I would have no objections whatsoever to either: a) An RFC-822ish header block followed by one blank line, followed by the commit message, followed by a magic separator and the boilerplate text which I can then safely ignore. ;-) I think I prefer this approach so I'll probably start by changing things in this direction unless there's a general preference for (b) below. b) The commit message leading things off, followed by a magic separator and the metadata, followed by boilerplate I can safely ignore. I agree with the various comments running around that +14 (or whatever) is easy enough. I think it's important to not *surprise people*, though, and the current format is surprising. I haven't checked the hook list, but if there's not a get editor or get commit editor options hook, after these changes there probably should I don't think there's a proper hook for this at the moment but that's something else I'll add when I get started on this. be; that allows one to set the monotone commit editor to include additional arguments to, say, one's mail editor. (Which, in my case, also has a +n to skip RFC822-style headers, and is different from $EDITOR.) I may get to this over the next couple of weeks while I'm on vacation but I may not have connectivity to be able to push any changes. I may not get to it until after I'm back too so don't expect to see any changes (from me) for a couple of weeks at least. Cheers, Derek ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] 0.48 rants
Starting a series of replies... On Sat, Jul 17, 2010 at 1:40 AM, CooSoft Support supp...@coosoft.plus.comwrote: I'm not currently using 0.48 and from what I hear nor will I. I to want comments to go in unmolested and not have white space stripped out. For me that is a must. I've found that I have commits with random amounts of trailing whitespace (newlines) and that's the entire reason that for the trimming. I think Lapo mentioned that he had similar concerns about how much whitespace would precede or follow his commit message and the basic idea was to allow people to stop worrying about such things. Point taken though, perhaps this trimming should be restricted to leading/trailing newlines and perhaps it should also be configurable by a hook so that can be controlled. Why are date and author changeable? Surely these should be immutable (apart from one could specify an alternate key on which to perform the checkin - I assume that the same restriction applies when changing the author in the changelog (i.e. you have to have a private key for that user in your keys directory). They're changeable in the editor exactly because they are changeable on the command line with --date, --author and --branch arguments and for no other reason. I also agree that the changelog that the user enters should go at the top. When working with GUIs you quickly learn that trying to slow a user down and make him/her think about the consequences of what they are about to do is mostly a waste of time as they simply get used to clicking on that extra button or in this case scrolling down x lines... There was *absolutely* no intent of slowing anyone down with this. It was about allowing review and changes and unifying the various randomly different output formats. Configuring your EDITOR with +N should allow the leading lines to be skipped. Cheers, Derek ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] 0.48 rants
On Sat, Jul 17, 2010 at 3:03 PM, Aaron W. Hsu arcf...@sacrideo.us wrote: Hey Everyone, With all the negative responses regarding the new changelog editor, I just thought I would weigh in with something a little more positive. I actually do like the changes, on a whole, and think that we shouldn't just revert to the old behavior. Thanks! It has been mildly depressing to see the predominantly negative response. Things will obviously be changed to some degree in the next version although I'm not sure what the changes will be yet. Cheers, Derek ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] 0.48 rants
On Sat, Jul 17, 2010 at 5:05 PM, Thomas Keller m...@thomaskeller.biz wrote: So we _could_ extend the commit editor to do this, by providing fields that are the file args (allowing Unix shell wildcards would be best) and the --exclude arg. If somebody would work on that, I'd rather let the user directly change the changeset in the editor, but not the possible command line restrictions which led to the changeset. I agree with your concern here the idea of only removing more things from the changeset in the editor and even then I'm not sure it would be a good thing. You could presumably still create invalid changesets by removing the addition of a required parent directory, or by removing a rename operation and including an addition that was predicated on the removed rename. For the moment I'd like to settle on a more acceptable format (or less offensive depending on your perspective) that can hopefully maintain the ability to edit things and keep the formats as similar as possible. Cheers, Derek ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] 0.48 rants
On Sun, Jul 18, 2010 at 12:11 AM, J Decker d3c...@gmail.com wrote: Personally I always do my commits with ... -m my message ... so I doubt this even affects me in the least. Correct. If you use -m, or edit the _MTN/log file or use --message-file you shouldn't be affected by the new changelog editor. Though, I do concur with the vein of complaints, all other revisioning control allow (expect?) that additional comments are put at the top of the file. How do you specify the cursor position when using notepad.exe? Probably you don't but if you're using notepad.exe then surely you're well accustomed to pain and this shouldn't be much of a burden. ;) I haven't even seen a changelog example, I'd assume that it mostly starts with MTN: Author: Some author text etc... these should be pretty easy to identify in any location, and I doubt that the exactness of 'must be on 10th line' or 'must be after X and before ZZ' would really be required No, it's actually quite particular about lines existing in the proper places so that the changelog message can be found in the middle of the output. This is certainly different from most/all other VCS tools and maybe it's a crazy idea. Cheers, Derek ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] 0.48 rants
On Tue, Jul 13, 2010 at 9:22 PM, Tero Koskinen tero.koski...@iki.fi wrote: I also dislike the new commit message format. While I can jump down 14 lines, I think the jump is an usability issue and the behaviour should be reverted back to previous version. Many editors (emacs, vi, nano at least) support a +N option which will move the cursor to the Nth line upon opening a file. Setting EDITOR=emacsclient +14 for example will put the cursor right where it needs to be and avoid having to manually position it before typing. This might be better done as a lua hook in the next version. Obviously this doesn't fix the various issues people are experiencing but it may help in the short term. It doesn't really surprise me that we're now hearing opinions on the new changelog editor, I had the feeling that things were too silent when we were discussing this and there's no doubt that this feature is in some sense an experiment and has a good chance of annoying or surprising people. For those who didn't follow the discussion during development there were two things this change was attempting to do, in order of priority: 1. Deal with the issue of oops, I forgot to specify a --branch option for this commit and now I have to start over which is now handled by being able to see and change the branch you're committing to while editing the commit message. 2. Unify the output from status, commit and log as much as possible (perhaps this has gone too far). Previously status would display various things about the current workspace that included the list of changed files, branch information etc. in a completely haphazard (i.e. not like log) way and commit wouldn't display anything. By displaying the revision as it will look after it has been committed you get a chance to preview your commit and fix things you're not happy with. I agree that all of the instructions and various possible BIG HAIRY WARNINGS are pretty damn ugly and doing something with them would be good. Ethan's proposal to keep the headers and move all the instructions and such below where the message is to go seems reasonable. Conditionally displaying fewer headers in status and commit is also an option, not removing leading/trailing whitespace can be changed, etc. Cheers, Derek ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] What's up with 'warning: including missing parent'?
On Mon, Jun 14, 2010 at 12:02 PM, Jack Lloyd ll...@randombit.net wrote: I think this is new in 0.48: $ mtn ci readme.txt doc/log.txt configure.py -m Tick to 1.9.9-dev mtn: warning: including missing parent '' mtn: warning: including missing parent 'doc' [...] Kind of obnoxious; I can understand if there was a change in the directory, or if the directory wasn't checked in, but that wasn't the case here. This is indeed new with 0.48. The restriction semantics were changed slightly to include parent directories of explicitly included files. Previously the commit above would have failed saying that the parents were required but not included. This warning doesn't need to be permanent of course so if there's some general sentiment that it should be removed it certainly can be. Cheers, Derek ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] checking for stray characters when parsing dates
I made a slight change to the date parsing code in ff193643616656b62a465d043676e3faf83418b7 to re-add the check for stray characters following the date that aren't matched by the specified format. I also added a simple check for this condition to the associated unit tests to make it clear what the problem is. I assume that this was removed inadvertently in a8147b11ee2d598835a4e1cec0e9782e4388e679 when the fixes for the lack of strptime (or anything seemingly equivalent) in win32 went in. Thanks for dealing with the win32 side of this Stephen, please let me know if that check was removed intentionally. Cheers, Derek ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Time for a release
On Thu, Jun 3, 2010 at 5:45 PM, Thomas Keller m...@thomaskeller.biz wrote: I've just talked with Thomas Moschny on IRC and I listened again to his and other people's concerns about switching too fast to 1.0. I think the concerns are reasonable, so we've discussed this issue and concluded the following: * The next version of monotone will be named 0.99 and will be the last version before the final 1.0.0 is out I agree with the general concern that we've had a few branches land lately. I wouldn't be surprised in the least to hear some screaming when people start using the new changelog editor functionality for example. Also, restrictions have been changed a bit, diff has also changed slightly, etc. Hopefully these changes are all good and generally liked, but the idea of changing a bunch of behaviour and then releasing 1.0 shortly afterwards seems a bit questionable. Cheers, Derek ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Time for a release
On Thu, Jun 3, 2010 at 5:03 AM, Thomas Keller m...@thomaskeller.biz wrote: 206 diffing_a_file_within_revision_outside_a_workspaceFAIL (line 52) 301 logging_a_file_within_revision_outside_a_workspaceFAIL (line 22) Both tests fail with restriction includes unknown path on foo2 / foo1. This is still an open issue. I'd like to see the detailed tester.log files for these but I have no idea how to get them. If someone can point me in the right direction I'll take a look. Cheers, Derek ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Time for a release
On Sun, May 30, 2010 at 5:01 PM, Thomas Keller m...@thomaskeller.biz wrote: 4) For me on Mac OS X all tests run through, even one unexpectedly (log_--diff) - Derek, should this test be un-xfailed? Indeed it should. I'll clean that up tonight. Cheers, Derek ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] [bug #17499] can't commit files in newly created dir
Update of bug #17499 (project monotone): Open/Closed: In Test = Closed ___ Reply to this item at: http://savannah.nongnu.org/bugs/?17499 ___ Message sent via/by Savannah http://savannah.nongnu.org/ ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] [bug #20447] mtn diff filename fails inside of a renamed directory
Update of bug #20447 (project monotone): Open/Closed: In Test = Closed mtn version --full: C:\dev\fortamtn --full-version monotone 0.35 (base revision: f92dd754bf5c1e6eddc9c462b8d68691cfeb7f8b) Running on : Windows NT/2000/XP/2003 (5.1, build 2600, Service Pack 2) on ia32 (level 6, rev 3846) C++ compiler: GNU C++ version 3.4.2 (mingw-special) C++ standard library: GNU libstdc++ version 20040907 Boost version : 1_33_1 Changes since base revision: format_version 1 new_manifest [33fa9f84dee6ec2e1bde81b607a067befbe2fc3e] old_revision [f92dd754bf5c1e6eddc9c462b8d68691cfeb7f8b] patch Makefile.am from [ecc00e0b8e9b5350157a1922e430ade4508d31bd] to [a52adc6a23a4bedf2d636a6c3e91cd46ce900a35] = C:devfortamtn --full-version monotone 0.35 (base revision: f92dd754bf5c1e6eddc9c462b8d68691cfeb7f8b) Running on : Windows NT/2000/XP/2003 (5.1, build 2600, Service Pack 2) on ia32 (level 6, rev 3846) C++ compiler: GNU C++ version 3.4.2 (mingw-special) C++ standard library: GNU libstdc++ version 20040907 Boost version : 1_33_1 Changes since base revision: format_version 1 new_manifest [33fa9f84dee6ec2e1bde81b607a067befbe2fc3e] old_revision [f92dd754bf5c1e6eddc9c462b8d68691cfeb7f8b] patch Makefile.am from [ecc00e0b8e9b5350157a1922e430ade4508d31bd] to [a52adc6a23a4bedf2d636a6c3e91cd46ce900a35] ___ Reply to this item at: http://savannah.nongnu.org/bugs/?20447 ___ Message sent via/by Savannah http://savannah.nongnu.org/ ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] [bug #22044] diff fails for files that have been moved and patched
Update of bug #22044 (project monotone): Open/Closed: In Test = Closed ___ Reply to this item at: http://savannah.nongnu.org/bugs/?22044 ___ Message sent via/by Savannah http://savannah.nongnu.org/ ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Release time
On Thu, May 27, 2010 at 9:54 AM, Derek Scherger de...@echologic.com wrote: As I've announced earlier I'd like to start the machinery for the next monotone release now that the database management branch has landed. So if you have anything you'd also really like to see in the next monotone version, please finish it up and merge it into mainline (I remember we still have a couple of open bugfest branches, right Derek and Richard?), I've got a bit left to do on the diff branch but I should be able to have that complete and landed in the next few days. This has been merged. Cheers, Derek ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Release time
On Fri, May 28, 2010 at 1:30 AM, Thomas Keller m...@thomaskeller.biz wrote: I agree that continueing the current versioning scheme, just with a prefixed 1., won't make much sense any longer, but I'm against complicating this too much. A new easy rule for now could be: 1) if a release only consists of bug fixes or has small, not BC-breaking improvements (esp. in respect to automate), raise the patch release 2) if a release has bigger improvements or breaks BC, raise the minor version 3) if a major flag day introduces major new things or we've rewritten 90% of monotone (:)), raise the major number. I think that pretty much agrees with http://apr.apache.org/versioning.htmlwhich is referenced by various other projects. Cheers, Derek ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Release time
On Thu, May 27, 2010 at 1:38 AM, Thomas Keller m...@thomaskeller.biz wrote: Hi all! As I've announced earlier I'd like to start the machinery for the next monotone release now that the database management branch has landed. So if you have anything you'd also really like to see in the next monotone version, please finish it up and merge it into mainline (I remember we still have a couple of open bugfest branches, right Derek and Richard?), I've got a bit left to do on the diff branch but I should be able to have that complete and landed in the next few days. Cheers, Derek ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: Command name separator [Was: Re: [Monotone-devel] Please review nvm.experiment.database-management]
On Wed, May 26, 2010 at 11:20 AM, Thomas Keller m...@thomaskeller.biz wrote: Whatever we come up with here, its a bit out of the scope of this branch - lets get this merged at first and make the other change later :) Agreed, based on your following comment. ;) And it just came into my mind a second after I hit the Send button that the above commands are the first which would use the dashed schema - I'll change that in the branch shortly. Sorry for being nuts... That's all I was really getting at. I don't have any problem with leaving the automate commands as they are personally. Another thought would be to allow either style, maybe replace dashes with underscores and use the result as the command name that gets looked up or vice-versa. Cheers, Derek ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] strptime not in MinGW time.h
On Thu, May 20, 2010 at 5:04 AM, Stephen Leake stephen_le...@stephe-leake.org wrote: It's currently dying with some mysterious C messages: These do _not_ look easy to fix. So I'm looking at where strptime is used, to see what the impact of this is. It's used in three places: get_log_message_interactively, if date_fmt is not empty status, to check that date_fmt is compatible with get_log_message_interactively commit, to check that date_fmt is compatible with something (I'm not sure what) With the new changelog editor you may edit the Date: header as part of a commit, strptime is used to parse the date from the commit editor. The format is deemed to be acceptable if the current date is unchanged after being formatted and parsed with it. date_fmt is set by the user, via a command line option or hook_get_date_format_spec. So this is in support of user-configurable date formats. ... used in the changelog editor, as far as I know nothing else uses strptime to parse dates. How important is that? Perhaps we could simply say user-configurable date formats not available on Win32. I'm ok with that. Or editing the Date: header is unsupported on Win32 But it looks like some parts of monotone need to parse dates stored in certs, which may be in some user-configurable format? That seems like a bad idea in the first place (so I hope I'm wrong). These are all stored as ISO 8601 dates -MM-DDTHH:MM:SS possibly also with millisecond values in them, I'm not sure of that. The date_t class is able to parse this format natively without using strptime. Cheers, Derek ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] strptime not in MinGW time.h
On Wed, May 19, 2010 at 3:56 AM, Stephen Leake stephen_le...@stephe-leake.org wrote: Various web links hint that strptime is in glibc, so I don't understand why it's not in MinGW. FWIW man strptime here says: SYNOPSIS #define _XOPEN_SOURCE /* glibc2 needs this */ #include time.h Any chance that fixes it? Cheers, Derek ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] strptime not in MinGW time.h
On Tue, May 18, 2010 at 2:49 AM, Stephen Leake stephen_le...@stephe-leake.org wrote: which identifies 'strptime' as an XSI; X/Open System Interfaces Extension. So apparently MinGW doesn't support that. Annotate says 'strptime' was added recently, as part of the changelog-editor work: Uh oh. Can this be rewritten using more standard libraries? Do you have any in mind? Date formatting and parsing seems to be quite a ghetto. Boost maybe? This sounds like maybe mingw missed it. Maybe it will appear in a future release? http://www.mail-archive.com/bug-gnu...@gnu.org/msg17739.html We could possibly copy an strptime implementation into our win32 directory I suppose. Cheers, Derek ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: new restrictions branch for including required parents
On Tue, May 18, 2010 at 3:40 PM, Thomas Keller m...@thomaskeller.biz wrote:
Ok here we go - code looks very good overall, some minor questions:
1)
+case restricted_path::required:
+case restricted_path::excluded_required:
+ if (path_depth == 0)
+{
+ L(FL(implicit include of nid %d path '%s') %
current % fp);
+ return true;
+}
+ else
+{
+ return false;
+}
+ return true;
If I followed the code correctly this logic is basically there to avoid
the exclusion of the root directory '', right? Would it make sense to
give this special node the correct node / path status right from the
start and therefor move this logic upwards? Also, the last return true
can never be reached, it should probably be
This is so that only the required parents are included but not all of their
contents. Another way to think of this is that for implicit includes the
depth is always 0 so that we don't end up inadvertently including more than
we want to.
The last stray return true; shouldn't be there. I've removed it.
2) The test case restricted_diff_bug should get a better name, its no
longer a bug :)
Done.
Other than that I think its ready to get merged - I suspect Stephe has
to make his undrop command equally use explicit_includes, just like
revert, right?
Yes that's probably correct. I haven't actually looked at that code to see
what it shares with revert, but it probably needs a similar restriction
change. Ideally there will be a test that fails (with too much getting
reverted) until it isn't including parents. It looks like undrop has not
been merged yet so we can fix it before it gets merged.
I've merged the restriction changes in so we can see what needs to be done
to undrop and I'll move on to the diff branch from the bugfest.
Cheers,
Derek
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: new restrictions branch for including required parents
On Mon, May 17, 2010 at 2:26 AM, Thomas Keller m...@thomaskeller.biz wrote: Ok, as long as you have documented that for the revert command, everything should be fine. A short note in NEWS shouldn't hurt as well. Done and ready to merge. Any objections? Cheers, Derek ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] time for a release?
On Mon, May 17, 2010 at 2:33 AM, Thomas Keller m...@thomaskeller.biz wrote: \2) I'd like to get my nvm.experiment.database-management branch ready and merged in as well, so the change I did earlier to mtn setup (which now creates a database if none is given) is changed to create a database in the default location or use the default database there. The code compiles already and partially works, but I had to do a couple of non-related changes to make database objects easier constructable and other things, which make mtn currently crash badly. I'll commit my current state tonight, so others have time to look at it. Maybe I'm on a wrong path there. I had a quick look over your changes and they seem fairly reasonable. A few minor things: We seem to be using lots of redundant std:: prefixes in various .cc files (not just in your changes) where we also have using std::foo declarations to avoid needing the std:: prefixes throughout the implementation. Do people have a general preference for explicit prefixes? Personally I much prefer a using declaration and less cluttered sources, iterators are already bad enough, sprinkling them with std:: makes them worse! ;) Some of your changelog comments use very long lines and are somewhat hard to read without a tool that does automatic, but careful, wrapping (viewing these in emacs diff-mode is not particularly pleasant). Can you try and wrap these at some reasonable length please? Based on all the shenanigans with .mtn extensions it seems like maybe the path handling code could use a more formal concept of extension. A shared_ptr for the lazy_rng would probably be better than a raw pointer. We should probably have a :memory: constant somewhere, rather than multiple string instances. I don't think you want to set the foo_given flags when reading options from the options file do you? Isn't the point of these to know whether the user specified such an option on the command line? Cheers, Derek ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] [bug #15994] Invariant 'fetching nonexistent entry from children' violated
Update of bug #15994 (project monotone): Assigned to:None = dscherger ___ Reply to this item at: http://savannah.nongnu.org/bugs/?15994 ___ Message sent via/by Savannah http://savannah.nongnu.org/ ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] [bug #17499] can't commit files in newly created dir
Update of bug #17499 (project monotone): Assigned to:None = dscherger ___ Reply to this item at: http://savannah.nongnu.org/bugs/?17499 ___ Message sent via/by Savannah http://savannah.nongnu.org/ ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] [bug #22044] diff fails for files that have been moved and patched
Update of bug #22044 (project monotone): Status:None = Duplicate Assigned to:None = dscherger ___ Reply to this item at: http://savannah.nongnu.org/bugs/?22044 ___ Message sent via/by Savannah http://savannah.nongnu.org/ ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: new restrictions branch for including required parents
On Sat, May 15, 2010 at 11:41 AM, Derek Scherger de...@echologic.comwrote: I've started a new branch net.venge.monotone.restrictions.implicit-includes that changes the restrictions code to always include the parents of explicitly included nodes. This turned out to be a relatively simple change and I've updated the restriction unit-tests so that they are all passing. It's now a matter of updating the lua tests and dealing with the fallout from that. After an initial look over things it doesn't look like it should be too difficult to do. Then it's just a matter of agreeing that the new semantics are an improvement over the current semantics. This is now finished and ready for review. The one case where implicit includes don't seem to make sense is for revert, where you might want to revert a file but not a rename of the directory that contains it. The restriction that revert uses doesn't apply the new implicit include rules but all other cases do. I've assigned a few more bugs to myself related to this, all of which can probably be closed once this is merged. There were a few xfailed test cases that are now passing as well. Cheers, Derek ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] bugfest analysis - final points
On Sun, May 16, 2010 at 3:51 PM, Thomas Keller m...@thomaskeller.biz wrote: Am 16.05.10 11:19, schrieb Stephen Leake: Thomas Keller m...@thomaskeller.biz writes: For the others: If you think your branch is ready for the final merge, give me a note if you want to get it reviewed another time, otherwise just merge it. For net.venge.monotone.bugfest-2010.13604-stephen_leake, I've removed the --recursive option from 'undrop'. So I think this is ready to merge. net.venge.monotone.restrictions.implicit-includes will change what 'revert' does with some restrictions; since 'undrop' shares core code with 'revert', there's no need to wait for that branch. I haven't followed your conversation with Derek further - just to get a ok from you both: undrop is still needed even after the new restriction code landed, right? I don't think the changes to the restriction code have any effect on this so yes, as far as I understand it, undrop is still needed. Cheers, Derek ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] [bug #22044] diff fails for files that have been moved and patched
Update of bug #22044 (project monotone): Open/Closed:Open = In Test ___ Reply to this item at: http://savannah.nongnu.org/bugs/?22044 ___ Message sent via/by Savannah http://savannah.nongnu.org/ ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] [bug #15994] Invariant 'fetching nonexistent entry from children' violated
Update of bug #15994 (project monotone): Status:None = Fixed ___ Reply to this item at: http://savannah.nongnu.org/bugs/?15994 ___ Message sent via/by Savannah http://savannah.nongnu.org/ ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] [bug #20447] mtn diff filename fails inside of a renamed directory
Update of bug #20447 (project monotone): Status:None = Fixed Open/Closed:Open = In Test mtn version --full: C:\dev\fortamtn --full-version monotone 0.35 (base revision: f92dd754bf5c1e6eddc9c462b8d68691cfeb7f8b) Running on : Windows NT/2000/XP/2003 (5.1, build 2600, Service Pack 2) on ia32 (level 6, rev 3846) C++ compiler: GNU C++ version 3.4.2 (mingw-special) C++ standard library: GNU libstdc++ version 20040907 Boost version : 1_33_1 Changes since base revision: format_version 1 new_manifest [33fa9f84dee6ec2e1bde81b607a067befbe2fc3e] old_revision [f92dd754bf5c1e6eddc9c462b8d68691cfeb7f8b] patch Makefile.am from [ecc00e0b8e9b5350157a1922e430ade4508d31bd] to [a52adc6a23a4bedf2d636a6c3e91cd46ce900a35] = C:devfortamtn --full-version monotone 0.35 (base revision: f92dd754bf5c1e6eddc9c462b8d68691cfeb7f8b) Running on : Windows NT/2000/XP/2003 (5.1, build 2600, Service Pack 2) on ia32 (level 6, rev 3846) C++ compiler: GNU C++ version 3.4.2 (mingw-special) C++ standard library: GNU libstdc++ version 20040907 Boost version : 1_33_1 Changes since base revision: format_version 1 new_manifest [33fa9f84dee6ec2e1bde81b607a067befbe2fc3e] old_revision [f92dd754bf5c1e6eddc9c462b8d68691cfeb7f8b] patch Makefile.am from [ecc00e0b8e9b5350157a1922e430ade4508d31bd] to [a52adc6a23a4bedf2d636a6c3e91cd46ce900a35] ___ Reply to this item at: http://savannah.nongnu.org/bugs/?20447 ___ Message sent via/by Savannah http://savannah.nongnu.org/ ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] [bug #15994] Invariant 'fetching nonexistent entry from children' violated
Update of bug #15994 (project monotone): Open/Closed:Open = In Test ___ Reply to this item at: http://savannah.nongnu.org/bugs/?15994 ___ Message sent via/by Savannah http://savannah.nongnu.org/ ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] [bug #17499] can't commit files in newly created dir
Update of bug #17499 (project monotone): Status:None = Fixed Open/Closed:Open = In Test ___ Reply to this item at: http://savannah.nongnu.org/bugs/?17499 ___ Message sent via/by Savannah http://savannah.nongnu.org/ ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] [bug #12773] show which branch a tag belongs to
Update of bug #12773 (project monotone): Open/Closed: In Test = Closed ___ Reply to this item at: http://savannah.nongnu.org/bugs/?12773 ___ Message sent via/by Savannah http://savannah.nongnu.org/ ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] changelog-editor branch merged
I've merged the changelog-editor branch back to mainline. If you're running from current builds you'll now see much more detail in your editor when committing and it will look very similar to the output of status and log. Cheers, Derek (fingers crossed) ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] new restrictions branch for including required parents
I've started a new branch net.venge.monotone.restrictions.implicit-includes that changes the restrictions code to always include the parents of explicitly included nodes. This turned out to be a relatively simple change and I've updated the restriction unit-tests so that they are all passing. It's now a matter of updating the lua tests and dealing with the fallout from that. After an initial look over things it doesn't look like it should be too difficult to do. Then it's just a matter of agreeing that the new semantics are an improvement over the current semantics. For example, this should now work: $ mtn add a/b/c $ mtn commit a/b/c This will also work: $ mtn add a/b/c $ mtn commit a/b/c --exclude a/b because explicit excludes are overridden by implicit includes of required parents. The implicit includes only apply to the parent directories themselves, not any of their children (i.e. non-recursively). If this works out landing the bugfest-2010.20447-dscherger branch should be straightforward. Cheers, Derek ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] bugfest analysis - final points
On Mon, May 10, 2010 at 3:53 PM, Thomas Keller m...@thomaskeller.bizwrote: * #20447: mtn diff filename fails inside of a renamed directory - net.venge.monotone.bugfest-2010.20447-dscherger - @Derek: whats your plan here? Is this reviewable? Patch looks ok, if you add tests for the new diff behaviour (/dev/null in adds and file removals) and check the patch(1) compatibility, I'll reward that with an 8. I've added a bunch of tests and noticed that there are several xfailed diff tests that are related to the same problem of a restriction excluding parents of a file. Seeing all these I'm pretty much convinced that making a change so that parent nodes get included is the right thing to do, or is at least better than what we're doing now. I don't think this should be too hard to do so I may have a look at it in the not-too-distant future. I'd like to get the changelog branch wrapped up first though. Note that you based this work on the code of #12273 - so only merge it into mainline afterwards when you had the time to manage the shortening of the ls tags output there :) Fixed, tested and merged. We can think about adding a --verbose option for things like this any time. Cheers, Derek ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: [bug #29835] 'update -b' fails where 'update -r h:b' succeeds
2010/5/12 Stephen Leake stephen_le...@stephe-leake.org Zbigniew Zagórski invalid.nore...@gnu.org writes: Follow-up Comment #2, bug #29835 (project monotone): (slept with that problem and ... ) 1. forget current patch, it's broken in regards to error/empty branches handling. I am preparing one new. Second, more important issue is that this changes how update works. Current update worked in two modes: 1. with -r - updates to _anything_ 2. with branch (implicit or not) - updates only to descendants of current revision This patch changed update so it would work like this: 1. with -r - updates to _anything_ 2. with branch (implicit or not) updates to - descendants of current revision OR - any head of specified branch (if merged) (equivalent to -rh:branch) Question: do we want to unify this behaviour? That is the point of my bug report. What is the rationale for the original behavior? Possibly so that you can update to the head on the side of a fork that you already happen to be on regardless of whether the branch is merged or not. Possibly because update -r (to arbitrary revision) was developed after update (to descendant head) which did something like cvs update that people had in mind when this was originally done. When do I need 'update -b foo' to fail, but 'update -r h:foo' to succeed? Update -rh:foo will fail if foo is unmerged, update -b foo might succeed in the same case if only one head is descended from the current revision. I haven't tested this though so it may not be how it works. I realize this does not exactly answer your question above but maybe it will help arrive at an answer there. I can't think of a good reason that update -b foo should fail if foo is merged or if only one head is descended from the current revision. Cheers, Derek ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] bugfest analysis
On Mon, May 10, 2010 at 6:24 AM, Stephen Leake stephen_le...@stephe-leake.org wrote: It is a minor modification of revert; I factored out the common code. undrop just tells revert not to revert a file that is present in the workspace, because it had changes when it was dropped. Ahh I see. I've wondered of and on about a few different options to revert. Like --name, --attrs, --content so that it can be a little more fine-grained about what it does. So would something like revert --no-content file be synonymous with undrop at this point? I think there are still some problems lurking in revert as well, for one it leaves renamed things laying around after reverting the renames. I've tried a few times to make revert work based on the editable_tree interface rather than just looking for missing files and recreating them but this turns out to be quite tricky and I've never actually managed to make it work quite right. The last attempt I made did at least get revert upgraded to use roster style checks rather than csets but it still doesn't actually replay the pending changes in reverse. One thing I noticed in trying to fix the diff bug was this: $ mtn mv dir dir2 $ edit dir2/file $ mth revert dir2/file # only reverts content, leaves directory rename in place $ edit dir2/file $ mtn revert dir2 --depth=0 # should revert the rename and leave the content change but fails it would be good to get this sorted out too. What I really need to do is to go and add a bunch of tests for things like this problem and a few others that I noticed in my thrashing around on Saturday. Cheers, Derek ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] bugfest analysis
On Mon, May 10, 2010 at 6:21 AM, Stephen Leake stephen_le...@stephe-leake.org wrote: Thomas Keller m...@thomaskeller.biz writes: Here is a little analysis of the recent bugfest efforts. Thanks for all your work in organizing this. I'll second that, you've done a great job of keeping track of what's going on and reviewing things. 1) Stephe 13 points (#7221 and #13597 still open) 2) Richard 11 points 3) Derek5 points (#20447 still open, might add +5) 4) Tim3 points (#17878 still open, might add +5) I'll give everybody some more time to cleanup / finish the mentioned things and recalculate the final scores again then. I feel a little guilty about this. I deliberately adopted a strategy of only working on trivial bugs. That was partly because I was tired and not in the mood for hard work, but also partly because I felt it was in the spirit of the bug hunt. Don't! I have a huge tendency to fall into any bottomless pit available and it happened again on Saturday. I looked at the diff bug and thought it looked like it might not be too bad and then it blew up in my face. Happens all the time, didn't even surprise me. The list branch names with tags fix took all of 15 minutes so I'm super lucky to get 5 points for that one too! ;) Cheers, Derek ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] bugfest analysis
On Mon, May 10, 2010 at 3:47 PM, Stephen Leake stephen_le...@stephe-leake.org wrote: I don't know; --no-content to me sounds like don't revert content, just renmaes and other stuff. That's not the same as 'undrop', which does revert content if the file actually got deleted from the workspace. Fair enough, I now see where you're coming from. I don't think I've ever used the --bookkeep-only option so I've never ended up with a file in such a state. One thing I noticed in trying to fix the diff bug was this: $ mtn mv dir dir2 $ edit dir2/file $ mth revert dir2/file # only reverts content, leaves directory rename in place $ edit dir2/file $ mtn revert dir2 --depth=0 # should revert the rename and leave the content change but fails it would be good to get this sorted out too. I think restrictions in general are poorly defined, which is one reason I never use them. If you say 'undrop file' you're using them! ;) The situation with revert might be better if it did do its work through the editable tree interface but getting this to work is difficult at best and it leaves open the possibility that revert will fail with mixed files/directories in the workspace blocking things from being reverted. One up-side of using the editable tree interface would be that revert wouldn't leave all kinds of junk laying around after its done. - Do you have any specific ideas of things that could be defined or described better? - Is it that the existing documentation doesn't describe what is possible well enough? - Is it that various commands deal with things in different ways (revert in particular, but also add etc.) which makes it feel like they are not well defined? - Is it that add a/b/c will add a, a/b and a/b/c and then commit a/b/c will fail because it has excluded a and a/b? - Is it that filenames are generally resolved against both the old and new roster to select nodes to be included or excluded? - Is it that the --depth option applies to all specified paths rather than to a specific path, allowing different levels of recursion for different directories? - Is it that you're not sure what will happen when you're about to say commit or revert with a set of paths? The intention is that the changes that get selected are *identical* for status, diff, commit, revert and the various list commands that apply to paths and there are tests to this effect. I believe that the set of nodes that get included based on a given list of paths and --exclude options is completely well defined. Whether this set is well defined for the operation it is used for might be another matter though as not all commands can or do use it. For example add doesn't have a set of nodes to select from so it has to do something slightly different. I do agree that committing part of a workspace can be considered bad practice in that you're essentially committing something that hasn't been tested but it happens often enough in reality that it seems like a necessary feature. Most other systems out there do allow this so we're not too far out in left field. Cheers, Derek ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] bug#13604: undrop
On Mon, May 10, 2010 at 5:53 AM, Stephen Leake stephen_le...@stephe-leake.org wrote: drop --recursive dir1 (realize mistake) undrop dir1/file1 What would that do? Currently, this gives an error: mtn: warning: restriction excludes addition of 'dir1' but includes addition of 'dir1/file1' mtn: misuse: invalid restriction opinions? If we change things so that parent directories of selected files/dirs are implicitly included (non-recursively) I think this would be able to do what you expect, undrop dir1 and dir1/file1. Cheers, Derek ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] to be recursive or non-recursive that is the question
On Mon, May 10, 2010 at 3:20 PM, Thomas Keller m...@thomaskeller.biz wrote: I think what he meant is the following: $ mtn mv a b $ edit b $ mtn revert b $ edit / save b again You end up with an unknown file b because of course your editor doesn't get the info that the rename was reverted. You don't even need to edit /save a second time. Revert just recreates the old file and leaves the renamed b sitting there. Cheers, Derek ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] to be recursive or non-recursive that is the question
On Mon, May 10, 2010 at 3:10 PM, Thomas Keller m...@thomaskeller.biz wrote:
$ mtn add a # non-recursive
$ mtn add a/... # recusive
$ mtn revert a # non-recursive
$ mtn revert a/... # recursive
I'm not sure how we'd represent a recursive revert of the entire
workspace,
maybe 'mtn revert ...' or something.
This is actually a nice idea - though we probably have to prohibit file
names like ^\.{3,} for that to work properly. It would certainly help
/ avoid the code clutter we have with the various --depth, --recursive
and so on option code.
Agreed.
I have somewhat mixed feelings about it though. It's not exactly standard
shell syntax which is not so good, but trying to do this with options
doesn't really work either. I'm not sure what we'd do about the backwards
compatibility concern raised upthread, other than call this a breaking
change.
One other thing, I think there is some requirement (maybe desire is a
better word) in the tests for the ability to select a directory and it's
immediate children but not their children, although I can't remember the
details. Maybe just using foo and foo/* would be the thing to do in that
case.
Cheers,
Derek
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] bugfest analysis - final points
On Mon, May 10, 2010 at 3:53 PM, Thomas Keller m...@thomaskeller.biz wrote: * #20447: mtn diff filename fails inside of a renamed directory - net.venge.monotone.bugfest-2010.20447-dscherger - @Derek: whats your plan here? Is this reviewable? Patch looks ok, if you add tests for the new diff behaviour (/dev/null in adds and file removals) and check the patch(1) compatibility, I'll reward that with an 8. Great! Ok, I'll add this to my list (which is getting rather long at this point) as well. It shouldn't be too hard to finish up. Note that you based this work on the code of #12273 - so only merge it into mainline afterwards when you had the time to manage the shortening of the ls tags output there :) Oh good catch. I'll finish that up and add a test and then merge it to mainline. I was wondering a bit more about a --verbose option that might apply here to turn on more detail in the list of tags. Perhaps the default would be to list only tag names and revs, and with --verbose list the branch and key details too. Cheers, Derek ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] bugfest analysis
On Sun, May 9, 2010 at 5:28 PM, Thomas Keller m...@thomaskeller.biz wrote:
* #20447: mtn diff filename fails inside of a renamed directory
- net.venge.monotone.bugfest-2010.20447-dscherger
- @Derek: whats your plan here? Is this reviewable?
I spent most of the day working on this and made some big changes
(reimplementing diff in terms of rosters rather than csets) but they didn't
actually fix the problem, which turns out to be somewhat complicated. I was
out for a long drive today and spent quite a lot of time thinking about it.
I have some ideas but I'm not yet sure if they'll work out or not. I'll
follow up with another email explaining the details.
* #12773: show which branch a tag belongs to
- net.venge.monotone.bugfest-2010.12273-dscherger
- Patch looks cool, a test would be nice though. Wrt space issues,
we could shorten the revision to gain additional space - I think
the chance of finding two partial tagged revisions which can be
completed to two different full revision ids is rather low.
- points: 5 to Derek (if you add a test :)
OK, adding a test should be easy. Do we have something to produce short
revision ids or should I just grab the first N chars or something?
* #13604: need 'undelete' ('undrop'?)
- net.venge.monotone.bugfest-2010.13604-stephen_leake
- patch looks largely cool, some minor objections:
revert = not undrop; - is the not operator portable?
bool undrop function argument - an enum would be cool :)
- possible issue left: undrop does not work correctly when
called on a dropped directory without --recursive. It still
re-creates all childs of the directory, while one would assume
that only the directory itself is recreated (and all the other
files keep dropped)
- points: 5 to Stephe (if the remaining issues are sorted out)
I'm somewhat curious about this one but I haven't looked at the bug or the
fixes yet. Is undrop/undelete somehow different from revert or is this just
a command alias?
Other than that I'm quite happy with the results. We've closed many bugs
and I think we should do that again some time in the future to bring
down the bug count even more.
Agreed. I personally find having a few people around working at the same
time is quite motivating.
Cheers,
Derek
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] [bug #17878] Usability: too easy to accidentally fork after merge or disapprove
On Sun, May 9, 2010 at 8:24 AM, Stephen Leake invalid.nore...@gnu.orgwrote: And, in general, support for option overwriting via --[no-]*, so you can put --update-workspace in the defaults, and override it on occasion. Agreed. Ideally such a system would allow for --foo --no-foo --foo etc. so that the last value wins. Cheers, Derek ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] diff bug 20447
So I spent quite a few hours on Saturday working on https://savannah.nongnu.org/bugs/?20447 which turned out to be somewhat more involved that I was expecting. The basic problem is this: given a file f in a directory d $ mtn mv d d2 $ edit f $ mtn status # rename d to d2 # patch d2/f from [1234] to [5678] $ mtn status d2 # rename d to d2 # patch d2/f from [1234] to [5678] $ mtn status d2/f # patch d/f from [1234] to [5678] Note that in the third status call the workspace changes are restricted to those on the file f and exclude the rename of the directory d to d2. The basic problem in bug 20447 is that when diff attempts to get the content for file f it uses the restricted name d/f rather than the unrestricted name d2/f. i.e. it doesn't know about the rename of d to d2 because that operation was excluded when the diff was limited to the single file. After looking over the code for dump_diffs and a few other functions I had the feeling that the problem was that they were written using csets rather than roster comparisons, probably left over from before rosters existed and never fully converted. Before looking into this too far (or thinking too hard) I just jumped in and converted everything to use rosters so that the proper names are available and there is no need for reverse rename maps and such. Almost all such code has been replaced with roster based implementations which are generally much simpler and correct. At the moment these changes result in slightly different diff output for additions and deletions which both now use /dev/null for one file (the source for adds and the target for deletes). There's a big comment in diff_output.cc that made this seem like the right approach. This new implementation currently does output a diff against /dev/null for a deletion where previously we simply didn't display anything. I'm not sure which is preferable but it's trivial to change, maybe we even want an option to control this? The new implementation also shows the both names involved when a rename occurs although I'm not sure if this is such a good idea as it may confuse patch and friends. Changing this is also trivial. Sadly, these changes didn't actually fix the problem, but having done this work I now understand what the problem is and have some ideas on what we might do. This problem is closely related to the problem of adding a directory d, then adding a file f to it and then restricting a commit to just the file d/f which fails because the directory addition is excluded. One fix for this would be to change the restrictions code so that including a file implicitly includes changes to all of its parent directories (non-recursively). So a commit of d/f would include d and d/f but not other children of d. I'm not sure if there are other ways we could deal with this. In the case of mv d d2 above if we include parents of f committing d2/f would also commit the rename of d to d2. This would effectively rename all other children x of d to d2/x as well which seems somewhat questionable, although it might be better than failing with 'mtn: misuse: file d/f does not exist'. Another way to possibly solve this might be to keep 3 rosters around (old, restricted and new) rather than 2 (old and restricted) and then when looking for files in the workspace use the unrestricted new roster (which represents the actual workspace content) to get the path and load the file to diff against. I think this could probably be made to work for diff but I'm not so sure about commit and I'm pretty sure that status, diff and commit must agree on what's changed when given the same set of paths to operate on. i.e. the point of status and diff is essentially to see what you are about to commit. Trying to use this approach for commit leads to the case where a commit of d2/f would commit the content change to f but not the rename of d so you're really only committing d/f which also seems questionable and doesn't fix the problem with committing a restricted addition. So, is there a general preference for (1) implicitly including changes (renames and attributes) to all parent directories of each included path or (2) being able to commit content changes to a file that is in a directory that has been renamed without including the directory rename? At the moment I think I'm in favour of (1) but I'm sure there are cases I haven't thought of yet and maybe (2) is a better choice. I'll note that add a/b/c will add a, a/b and a/b/c if they don't already exist in the project which is essentially implicitly including the parent directories of the specified file. Cheers, Derek ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] to be recursive or non-recursive that is the question
mtn add is non-recursive by default but allows for --recursive if you want it. mtn revert is recursive by default and doesn't allow for an obvious way of being non-recursive (I believe --depth=N will stop the recursion at the specified depth). So, which is more dangerous (1) accidentally adding some files you didn't mean to add, or (2) accidentally reverting a bunch of changes you didn't mean to revert? Recovering from (1) is easy, just revert the additions you don't want. Since revert is recursive this is no problem! ;) Recovering from (2) is ... not so easy. If you happen to have all the reverted files open in editor buffers you might be able to write them back out but any pending renames will be messed up badly. There's an old branch net.venge.monotone.restrictions.wildcard-paths that once tried to add something like the foo/bar/... suffix that perforce uses to indicate recursive behaviour and perhaps we should consider doing this again. This might help clean up add, revert, status, diff, commit, etc. and allow the --depth option to be retired. i.e. $ mtn add a # non-recursive $ mtn add a/... # recusive $ mtn revert a # non-recursive $ mtn revert a/... # recursive I'm not sure how we'd represent a recursive revert of the entire workspace, maybe 'mtn revert ...' or something. Comments? Cheers, Derek ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] [bug #12773] show which branch a tag belongs to
Update of bug #12773 (project monotone): Assigned to:None = dscherger ___ Reply to this item at: http://savannah.nongnu.org/bugs/?12773 ___ Message sent via/by Savannah http://savannah.nongnu.org/ ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] [bug #12773] show which branch a tag belongs to
Update of bug #12773 (project monotone): Open/Closed:Open = In Test ___ Reply to this item at: http://savannah.nongnu.org/bugs/?12773 ___ Message sent via/by Savannah http://savannah.nongnu.org/ ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] [bug #12773] show which branch a tag belongs to
Update of bug #12773 (project monotone): Status:None = Fixed ___ Reply to this item at: http://savannah.nongnu.org/bugs/?12773 ___ Message sent via/by Savannah http://savannah.nongnu.org/ ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] [bug #27929] Don't use excessive amounts of entropy
Update of bug #27929 (project monotone): Status:None = Wont Fix Open/Closed:Open = Closed ___ Reply to this item at: http://savannah.nongnu.org/bugs/?27929 ___ Message sent via/by Savannah http://savannah.nongnu.org/ ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] [bug #20447] mtn diff filename fails inside of a renamed directory
Update of bug #20447 (project monotone): Assigned to:None = dscherger mtn version --full: C:\dev\fortamtn --full-version monotone 0.35 (base revision: f92dd754bf5c1e6eddc9c462b8d68691cfeb7f8b) Running on : Windows NT/2000/XP/2003 (5.1, build 2600, Service Pack 2) on ia32 (level 6, rev 3846) C++ compiler: GNU C++ version 3.4.2 (mingw-special) C++ standard library: GNU libstdc++ version 20040907 Boost version : 1_33_1 Changes since base revision: format_version 1 new_manifest [33fa9f84dee6ec2e1bde81b607a067befbe2fc3e] old_revision [f92dd754bf5c1e6eddc9c462b8d68691cfeb7f8b] patch Makefile.am from [ecc00e0b8e9b5350157a1922e430ade4508d31bd] to [a52adc6a23a4bedf2d636a6c3e91cd46ce900a35] = C:devfortamtn --full-version monotone 0.35 (base revision: f92dd754bf5c1e6eddc9c462b8d68691cfeb7f8b) Running on : Windows NT/2000/XP/2003 (5.1, build 2600, Service Pack 2) on ia32 (level 6, rev 3846) C++ compiler: GNU C++ version 3.4.2 (mingw-special) C++ standard library: GNU libstdc++ version 20040907 Boost version : 1_33_1 Changes since base revision: format_version 1 new_manifest [33fa9f84dee6ec2e1bde81b607a067befbe2fc3e] old_revision [f92dd754bf5c1e6eddc9c462b8d68691cfeb7f8b] patch Makefile.am from [ecc00e0b8e9b5350157a1922e430ade4508d31bd] to [a52adc6a23a4bedf2d636a6c3e91cd46ce900a35] ___ Follow-up Comment #1: 0.45 and 0.48dev fail less badly $ mtn mv unix foobar $ echo foobar foobar/cputime.cc $ mtn diff foobar/cputime.cc mtn: misuse: file unix/cputime.cc does not exist but something is still wrong here ___ Reply to this item at: http://savannah.nongnu.org/bugs/?20447 ___ Message sent via/by Savannah http://savannah.nongnu.org/ ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] [bug #22417] fatal botan error if unreadable files are encountered in a workspace
Follow-up Comment #2, bug #22417 (project monotone): Monotone currently also fails for missing files which are somewhat similar to unreadable files. Perhaps we should still fail but with a nicer message rather than a hard crash. ___ Reply to this item at: http://savannah.nongnu.org/bugs/?22417 ___ Message sent via/by Savannah http://savannah.nongnu.org/ ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] [ANN] monotone Bug Hunt Day
On Thu, May 6, 2010 at 11:48 AM, Thomas Keller m...@thomaskeller.biz wrote: Am 06.05.10 13:09, schrieb Stephen Leake: 2) Create a new branch nvm.bugfest-2010.savane-bug-id-savane-login and work on the fix. There are several failing tests on main, so I suggest we branch from t:monotone-0.47 for this purpose. That passes all tests on Debian, and only a couple known failures on MinGW (haven't run Cygwin in a while). The current head also passes all tests on Debian - I fixed my introduced bugs recently - so no reason to start from 0.47. The openBSD failures we see come up because of a local workspace problem of the bot. I had a thought on this this morning. Do the tests not pass a --root option to the various mtn invocations to limit how far up the filesystem the search for a workspace goes? Maybe this is not being done for this test. If it was that might fix the problem. Cheers, Derek ___ 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
On Tue, Apr 20, 2010 at 3:57 PM, Thomas Keller m...@thomaskeller.biz wrote: In the meantime what I would really really want to get rid of are boolean function arguments - so maybe you could start and make the code a little easier to read by passing a more describable enum value...? Agreed. I've replaced the bool with an enum. I tend to agree here and I've reverted it to use the Changes against parent... however I'm now wondering whether displaying the branch names associated with each parent in this section might be useful which makes me wonder again about using Parent: ... and Branch: headers here. This might surely make sense, but where do we stop? If we start listing cert values of *parents* we might start listing the parents of these parents and their certs and... endless loop :) No, I think the parent revision id is enough, really. Everything else should be part of that revision's log output. Heh, ok. Nothing else to do here then. Now this is something which I'd slightly change - I'd love to see this information in the editable area and the hint that the branch changes above the editable area - because its important and might otherwise get easily forgotten, so something like: I'm not particularly fond of the old branch value in the editable area only because it clutters up the otherwise nicely aligned headers. I'm also not sure including the notice that the branch is changing before or after the editable area makes much difference. It may scroll off the top of a terminal if it's too early so it may be better after the editable values. I've left these where they were in the last iteration but I've emphasized the branch change message so it has a better chance of being noticed. You can set EDITOR='emacsclient +15' to get what you want but this is probably not what you want EDITOR set to in general. We'd need to do some more work in the edit_comment hook to get this right. This would be nice to do but I don't think it's critical for getting this branch finished. Instead of giving the editor a jump point (which could be error-prone f.e. if you think about i18n) I'd try to decrease the verbosity of the entry line mainly by removing the warning in line three: Done. I'd like to preserve the option of telling the editor to jump though, and since that's currently done in EDITOR we can all set it to the appropriate value for our translations so that shouldn't be a real problem. And of course I'd remove Revision: and Parent: from the editable area to make it even less verbose, but we've had this discussion before and as I said I'm happy already that my separators made it in ;) Yes, you're arguing for removing these non-editable things and including the non-editable old branch value. I'm arguing for keeping these and not including the old branch value. It's pretty arbitrary either way there's no doubt. My rationale for leaving the Revision and Parent headers in is that without them the nicely aligned headers look a bit odd because they have extra alignment whitespace that is only relevant when those headers do appear in the output from log and status and I'd like to keep the display from these three commands as similar as possible. I think we definitely want to have it for 0.48. And I'm also voting for not discussing this useful feature to death (because then it won't get included at all) - so I'm shutting up now :) I appreciate the feedback all the same. All that remains is to update the manual to include some examples of the new editor display. I should have this done some time this week. Sorry it took me so long to get to this. Cheers, Derek ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Bug Hunt Day
On Thu, Apr 29, 2010 at 5:00 AM, Thomas Keller m...@thomaskeller.biz wrote: Ok, two people now - what about the others? I'm in if the timing works. Cheers, Derek Yes I still need to get to that email about the changelog editor too ;) ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: netsync connection info cleanup
On Wed, Apr 28, 2010 at 5:14 AM, Thomas Moschny thomas.mosc...@gmx.dewrote: mtn ls branches | grep -v -E '^(\w+(-\w+)*)(\.\w+(-\w+)*)*$' shows only one branch that doesn't match in my local copy of the monotone db (prjek.net:tester). And what would you do with that branch if this were to become a restriction? I said I'd agree with the idea of *warning* the user (not *disallowing* usage of such branch names), I also said I think there's no technical need to restrict branch names - besides obvious things like \0, and given there's a way to quote characters if necessary (e.g. using URL quoting). For the record, when I was working on the git_export stuff the prjek.net:tester branch name was considered invalid by git and it was necessary to map this name to something else for git to accept it. Cheers, Derek ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: netsync connection info cleanup
On Wed, Apr 28, 2010 at 1:34 AM, Thomas Keller m...@thomaskeller.biz wrote: +1/2 - this is similar to my last proposal (with : as separators, but I'd accept , as well) - but the mandatory ? still strikes me. Do you see any way to avoid ? for the 90% use case (sync a single branch without wildcards from / to a remote database)? I haven't followed this thread terribly carefully so this may be a rehash of something earlier (apologies in advance if it is). Branches can be considered things that exist within a database so the idea of a hierarchy from database to branch is somewhat reasonable. Following this, a url like mtn://host/database/branch might be workable and can avoid the need for a ? separator. Things might get awkward when you try and extend this to include more than one branch or several branch patterns though. Cheers, Derek ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: netsync connection info cleanup
On Tue, Apr 27, 2010 at 5:54 PM, Zack Weinberg za...@panix.com wrote: On Tue, Apr 27, 2010 at 4:42 PM, Timothy Brownawell tbrow...@prjek.net wrote: Is the occasional backslash really that bad? '%' conflicts with urlencoding (and '*' would only actually glob things if you have some really weirdly named files), and '?' is probably necessary for file/ssh sync. I think it's more important to avoid characters that are meaningful in URLs (*especially* %) than to avoid characters that are meaningful to the shell. People expect to have to quote URLs. Also, I don't like / as a separator when it's not traversing a directory-like hierarchy. Agreed, on all counts. So, how about this? protocol:// u...@server.host.name/path/to/database?include,include,-exclude,-exclude should work equally well for mtn (with usher), ssh, and file. Without usher, you just leave out the /path part. +1 (nice and simple) (Also, ~ in the path part should absolutely have the 'go to home directory' semantic.) Agreed here too. This proposal doesn't change the meaning of any URL-special characters which I think is important. Overloading % + ? = or would be bad as people generally know what they mean in the context of a URL. We could consider using the fragment character # in place of the query string separator character ? but that's probably splitting hairs. This is a shell-special character too (for comments) but it doesn't seem to apply if there's non-whitespace immediately preceding it. Cheers, Derek ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] [bug #29576] mtn tries to rewrite options file every time
On Sat, Apr 17, 2010 at 4:53 PM, Derek Scherger de...@echologic.com wrote: How about something simple:just before writing out a new _MTN/options read in the current one and see if there is any difference between what is about to be written and what is already written, then only write out new options if there are *actual* changes. This should be entirely compatible with what we do now, but will avoid affecting the last modification time when nothing is actually changed. Fixed in 5f00cba58b8c3feb72d6de28e94610a42e30465b. This has been bugging me for a while too so thanks for the motivation Jack. Editing _MTN/options in emacs is all but impossible because emacs checks the mtime on the buffer and it's almost always modified, I assume the old school emacs VC integration is calling status frequently although I haven't confirmed this. Now all I need is for gentoo to update their monotone package so I can get my various machines updated... Cheers, Derek ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] [bug #29576] mtn tries to rewrite options file every time
On Sun, Apr 18, 2010 at 2:40 PM, Thomas Keller m...@thomaskeller.biz wrote: Heh, very cool, thanks Derek! Does this code change also fix the problem that _MTN/options is written out even if the command does not succeed? I don't think so. This change was to the set_options function in work.cc. The places that call this explicitly do so very late so there's not much left to fail. This function is also called by some of the workspace constructors which is probably where the trouble is... create a workspace and write out any changed options before doing something that might fail. Presumably these places should all be changed to explicitly call set_options after they've finished whatever they're doing so that failures wouldn't result in changed options. Cheers, Derek ___ 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
2010/4/15 Derek Scherger de...@echologic.com
2010/4/14 Stéphane Gimenez d...@gim.name
First remark: mtn status ask for my password and it's rather
inconvenient (I'm not using ssh agent). Same for mtn commit just after
it's invocation and prior to the real commit.
Hrm.. I hadn't noticed that but I'll take a look.
This should be fixed in c66c53da6285693772f76e3f7cfa3b99a34f8b04 but I'm not
sure if the change I've made there is a good one or not.
Thomas and Tim, can you please have a look at this revision and see if you
have a better approach? I don't see any obvious way of getting the signing
key without attempting to decrypt it.
I wouldn't call it ChangeSet but Parent, simply because it is the parent
About this, I find 'ChangeSet: ' really confusing, one could
think of '' as an id for the changeset. The good old 'Changes against
parent ' looks better to me.
I tend to agree here and I've reverted it to use the Changes against
parent... however I'm now wondering whether displaying the branch names
associated with each parent in this section might be useful which makes me
wonder again about using Parent: ... and Branch: headers here.
Since you want to know about what users think... See below for what
I'd like to see in my editor. I think it's pretty self explanatory
and compatible with most of the ideas you came up with.
Here's what I have now:
$ mtn commit
##
Enter a description of this change following the Changelog line.
The values of Author, Date and Branch may be modified as required.
Any other modifications will cause the commit to fail.
*** REMOVE THIS LINE TO CANCEL THE COMMIT ***
--
Revision: c66c53da6285693772f76e3f7cfa3b99a34f8b04
Parent: f016f1e3e91e181e1fee2320ad537d99ce236d7d
Author: de...@echologic.com
Date: Sun Apr 18 10:59:06 PM 2010
Branch: net.venge.monotone.experiment.changelog-editor
Changelog:
avoid requiring key passphrase for status and before editing commit message
* cmd_ws_commit.cc (status,commit): call get_user_key with new
don't-cache-key
flag; pass key_store object into complete_key_identity so that keys that
don't exist in the database are still available
* keys.{hh,cc} (get_user_key): add new cache boolean controlling whether
check_and_save_chosen_key is called to decrypt the private key
* tests/wrong_options_override_workspace_options/__driver__.lua: revert
changes
made on this branch that are no longer necessary; test now matches that
on
net.venge.monotone
--
Changes against parent f016f1e3e91e181e1fee2320ad537d99ce236d7d
patched cmd_ws_commit.cc
patched keys.cc
patched keys.hh
patched tests/wrong_options_override_workspace_options/__driver__.lua
##
Which includes a --- separator line after the Changelog section in the
commit editor. I've left the Revision: and Parent: lines between the ---
separator lines alone. I'm assuming that people won't have any reason to
edit these as they won't have any sensible values to put in them so they
aren't likely to touch them.
$ mtn status
--
Revision: aa124b3ff5c488a0aeba8754821d00a374c61440
Parent: c66c53da6285693772f76e3f7cfa3b99a34f8b04
Author: de...@echologic.com
Date: Sun Apr 18 11:12:45 PM 2010
Branch: net.venge.monotone.experiment.changelog-editor.foo
--
This revision will create a new branch.
Old Branch: net.venge.monotone.experiment.changelog-editor
New Branch: net.venge.monotone.experiment.changelog-editor.foo
Changes against parent c66c53da6285693772f76e3f7cfa3b99a34f8b04
no changes
The second --- separator line is only included in status when the branch has
been changed. The note about the branch changing is also displayed by
commit.
Also, it would be nice if the editor was invoked with option '+13' to
position the cursor just after the ChangeLog line. It seems to work
with vim, emacs and nano.
You can set EDITOR='emacsclient +15' to get what you want but this is
probably not what you want EDITOR set to in general. We'd need to do some
more work in the edit_comment hook to get this right. This would be nice to
do but I don't think it's critical for getting this branch finished.
I'm not in any particular hurry to merge this but I think it's pretty much
ready. Are there any fundamental objections at this point? Do we want to
have it in for 0.48?
Cheers,
Derek
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] [bug #29576] mtn tries to rewrite options file every time
On Sat, Apr 17, 2010 at 6:34 AM, Thomas Keller m...@thomaskeller.biz wrote: This is only partially a problem of the hook. The options system simply has no general code to accept --no-something options which would switch the default of the --something value to the opposite. Allowing a general --no-foo for each boolean option --foo would probably be a good thing though. It would be nice if any early --no-files option could be overridden by a later --files option. Ditto for --no-merges --no-graph, etc. This may not make sense for every boolean option that we have, but it would for many of them. Cheers, Derek ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] [bug #29576] mtn tries to rewrite options file every time
On Sat, Apr 17, 2010 at 1:27 AM, Thomas Keller invalid.nore...@gnu.orgwrote: 1) Save any given options back to _MTN/options at the very end of the execution (f.e. in monotone.cc) _after_ it has been clear that no exception occurred - so we don't remember possibly harmful settings. 2) Only save those options back to _MTN/options which have actually been given by the user on the command line - this would probably need a little fiddling with the someopt_given flag we set even for options from _MTN/options (or we leave that alone and find another way to determine which options have been given by the user and which not). Note that there is also a hook which returns default command options for a command. Alternatively we could always save back the options to _MTN/options unless another global command line option is given, f.e. --skip-options-saving or something similar. How about something simple:just before writing out a new _MTN/options read in the current one and see if there is any difference between what is about to be written and what is already written, then only write out new options if there are *actual* changes. This should be entirely compatible with what we do now, but will avoid affecting the last modification time when nothing is actually changed. Cheers, Derek ___ 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
2010/4/14 Stéphane Gimenez d...@gim.name Hi, I've been following your discussion, and I tried the nice features in this changlog editor branch. First remark: mtn status ask for my password and it's rather inconvenient (I'm not using ssh agent). Same for mtn commit just after it's invocation and prior to the real commit. Hrm.. I hadn't noticed that but I'll take a look. I wouldn't call it ChangeSet but Parent, simply because it is the parent About this, I find 'ChangeSet: ' really confusing, one could think of '' as an id for the changeset. The good old 'Changes against parent ' looks better to me. In my current workspace I've removed the Parent: lines from the top of the revision header and have used Parent: xxx for the changeset sections which avoids printing the parent lines twice. I'll post an example a bit later. Since you want to know about what users think... See below for what I'd like to see in my editor. I think it's pretty self explanatory and compatible with most of the ideas you came up with. Revision: 595feb9f09d68da0559e4f7ace01f5294090210e Parent: 803a401fd7a2703b5edc416155fbbdba0b287eb4 REMOVE THIS LINE TO CANCEL THE COMMIT * - or fill the following area with certificates - Author: m...@wherever Date: 2010-04-13 17:52:00 Branch: net.venge.monotone.experiment.changelog-editor ChangeLog: - end of editable area - Changes against parent 803a401fd7a2703b5edc416155fbbdba0b287eb4 patched README And, mtn status or mtn log would display the same, just remove '***' and '---' lines (plus empty lines around those). Also, it would be nice if the editor was invoked with option '+13' to position the cursor just after the ChangeLog line. It seems to work with vim, emacs and nano. Interesting. I hadn't noticed this option before but I agree. I have been wondering how annoying it would be to have to reposition the cursor before entering the ChangeLog message and being able to put the cursor right where it needs to go seems very good. This is a simple matter of a change to the lua hook to pass the appropriate arguments. Anyway, whatever you choose, thanks for all this! Thanks for the feedback. Cheers, Derek ___ 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
On Tue, Apr 13, 2010 at 1:29 AM, Stephen Leake stephen_le...@stephe-leake.org wrote: Derek Scherger de...@echologic.com writes: Presumably someone could write a monotone-commit-mode for emacs and something similar for vim that would allow the editor to prevent you from editing things you're not supposed to. I take the opposite approach in my Emacs front-end; I edit _MTN/log (almost directly), and tell commit to just use it. That means changing the branch, author etc require separate commands (which I have not implemented). Presumably you could pass --author, --date and --branch options? There are commands to enter comment templates from ediff, while reviewing changes. Good to know there are other options. I've been thinking about implementing 'automate log'; the current log implementation in the Emacs front end is horribly inefficient, and has at least one bug that I'm having a hard time fixing. It uses bunches of automate commands to reproduce approximately what 'mtn log' does. Yeah, I think I tried dvc at some point and found it to be quite slow iirc. I should probably try it again though. I still use monotone.el quite often but something better would be good. I've been using magit with git a bit and it seems quite nice as well. The ability to select particular diff hunks interactively can be quite useful, even though it can also be considered bad practice. Cheers, Derek ___ 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
On Mon, Apr 12, 2010 at 4:06 PM, Thomas Keller m...@thomaskeller.biz wrote: No, I just tried it out and it already looks much nicer, though I still miss the end of the editable changelog area somewhat - maybe this is just me who looks for some visual separator. One minor peeve I have with the current editor (on mainline) is that you don't really want to put a blank line after the message or it will be displayed as 2 blank lines after the revision is committed. If I reformat the paragraph I'm typing in emacs with fill-paragraph and there is no blank line following my message it pulls in all the MTN: prefixed lines and makes a bit of a mess. With the new format I was sort of relying on the fact that there would be a blank line following the message to prevent fill-paragraph from being overly greedy. Maybe this delimiter is too subtle though? Presumably someone could write a monotone-commit-mode for emacs and something similar for vim that would allow the editor to prevent you from editing things you're not supposed to. I have to admit I used the comment command the first time today. I now know what you mean, mtn comment REV fires up an editor with the possibility to add multi-line text. While you can add linebreaks in other certs as well, its usually a bit harder to do so and people don't trap into that. I initially thought that a comment cert's value could simply appended to the header section in mtn log or similar, but it makes more sense to deal with it just like with normal changelog certs. See 'mtn log -r 0f1782f7e2348f991a0b8eeac03c45a72c8633a2' for a revision with a few comment certs. I think the current format does a reasonable job there. ### Enter a description of this change following the ChangeLog line. The values of Author, Date and Branch may be modified as required. Any other modifications will will cause the commit to fail. *** REMOVE THIS LINE TO CANCEL THE COMMIT *** -- Author: m...@thomaskeller.biz Date: 12.04.2010 23:44:27 Branch: biz.thomaskeller.test3 ChangeLog: -- Parent: ace2791b0b3df530b449802ce82fd8d731a466f1 patched foo What has changed? Parent has been moved down into the ChangeSet section. I had considered this a while ago but then forgot about the idea so thanks for reminding me. We currently have the Parent listed twice, once in the header and a second time before the changeset. Maybe we should drop the one in the header and only include it with the changeset, DRY and all that. I wouldn't call it ChangeSet but Parent, simply because it is the parent Interestingly (maybe) in the code what is being displayed is exactly the changeset from the revision which is where the name came from. we denote with the revision. Revision is gone from the commit header as well - is there any use case displaying this for uncommitted revisions? None that I can think of... I was looking for consistency but I'm fine with dropping the Revision line from commit and status. Any objection to dropping (or moving) the Parent lines down with their changeset details? I would probably not change too much in mtn log, i.e. separators for marking an editable section are not needed here. I'd also keep most of the structure as it is now - also because I think we still have a couple of users which read in mtn log and parse it somehow directly because of the missing automate functionality for that. I know that this is a bit against your aim to provide a single way of displaying cert information, but maybe its worth to not do it exactly the same...? I was hoping/expecting to hear from anyone who might be parsing the log output if they were concerned with the changes being proposed. By unifying the formats I was hoping that people could see what their revision would look like before they've committed it so that there aren't any surprises introduced by the different formats. The mess of functions to display certs in log is mostly gone on this branch and that's one part of the change that I'd like to keep. ;) Hrm, no, probably not that far. Ok, forget the RFC :) If you think its easy enough to add some basic custom cert adding, then do it, otherwise we wait for a feature request... I'm punting for now. We can add this later if it becomes important. I'll have a look at this and see where the extra newline is coming from. # mtn: warning: This revision will create a new branch Old Branch: biz.thomaskeller.test New Branch: biz.thomaskeller.test3 -- Status explicitly outputs a blank line after the old/new branch details which can be changed if we want. I like the idea of adding this information to the instructions for commit if/when the branch is changing. A few extra lines there would make an
Re: [Monotone-devel] the changelog editor branch is ready for review
On Sun, Apr 11, 2010 at 12:38 PM, Thomas Keller m...@thomaskeller.biz 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 additional newline comes from): I'll have a look at this and see where
[Monotone-devel] the changelog editor branch is ready for review
Hi folks, I think the experimental changelog editor branch that I've been working on recently is to the point where we can consider merging it to mainline. (see the net.venge.monotone.experiment.changelog-editor branch) The original motivation for this branch was to help deal with the problem of saying commit and then realizing that you forgot to specify a --branch option while editing your commit message. This branch changes a few things: 1. Allows not only the ChangeLog message to be edited, but also the Date, Author and Branch values associated with the revision. 2. Unifies the format of revisions displayed by status, commit and log so that a revision looks the same before it's committed, while it's being committed and after it has been committed. 3. Requires that the long date/time format used by status, commit and log preserves a date passed through a formatting and parsing cycle. The status command checks that the current format meets this requirement and warns if it does not and commit refuses to operate for formats that don't meet this requirement. 4. Changes the edit_comment lua hook to take only one argument. Existing hooks that override the default will need to be changed to work properly. One somewhat nice side effect of the changes here is that the addition and removal of MTN: prefixes is no longer done in both the lua hook and the associated C++ code. There are some relatively minor things that are open for discussion: 1. There used to be a magic line that the old commit editor would include if the text of the commit message came from the cached _MTN/log file. This line existed so that a commit could be aborted. If there was data in the _MTN/log file the magic line had to be removed before the commit would proceed. With the new editor changes outside of the legal zones described below will abort the commit so there is no real need for a magic line anymore. 2. The default date formats on mainline use %x which (using en_CA.UTF-8) produce 2 digit years. This does not meet the requirement in point 3 above for years before 1969 or after 2068 (with glibc 2.1 or later). While this isn't a huge problem it might be a good idea to consider using the %F format which produces 4 digit years. 3. Changing text in the commit editor outside of the Author, Date, Branch and ChangeLog values is prohibited and will abort a commit because it may prevent these values from being found and extracted. Perhaps the entire contents of the editor should be saved to something like _MTN/changelog to prevent losing a long, carefully worded commit message entirely if you accidentally touch something outside of these legal zones. There are also some rather bikeshed-esque things that can be considered: 1. Currently the various cert headers all have a single space following the ':' character which doesn't line up their values very nicely. I think I would prefer these to be aligned left or right but I'm curious to see what others think. 2. The wording of the preliminary text describing what to do in the commit editor can probably be improved. This is a minor detail that can easily be changed later. 3. The Changes against parent line preceding the list of changed files and directories might be better as a Changes: line with an optional parent revision id which isn't included for root commits. Examples $ mtn status -- Revision: 90be95aa13e418be817cb85f7ec754cdf7b2389e Parent: 8e8e71399ff9035409671f93723223430c26edc3 Author: de...@echologic.com Date: Tue Apr 06 10:39:38 PM 2010 -0600 Branch: net.venge.monotone.experiment.changelog-editor ChangeLog: Changes against parent 8e8e71399ff9035409671f93723223430c26edc3 patched monotone.texi patched tests/commit_using__MTN_log/__driver__.lua patched tests/commit_using__MTN_log/commit_log_modified_return.lua patched unit-tests/dates.cc If there is a partial commit message in _MTN/log status will include it in the ChangeLog section above, otherwise this section is empty. $ mtn commit == Ensure the values for Author, Date and Branch are correct, then enter a description of this change following the ChangeLog line. Any other modifications to the lines below or to the summary of changes will cause the commit to fail. -- Revision: 90be95aa13e418be817cb85f7ec754cdf7b2389e Parent: 8e8e71399ff9035409671f93723223430c26edc3 Author: de...@echologic.com Date: Tue Apr 06 10:40:00 PM 2010 -0600 Branch: net.venge.monotone.experiment.changelog-editor ChangeLog: Changes against parent 8e8e71399ff9035409671f93723223430c26edc3 patched monotone.texi patched tests/commit_using__MTN_log/__driver__.lua patched
Re: [Monotone-devel] the changelog editor branch is ready for review
On Sat, Apr 10, 2010 at 1:28 PM, Thomas Keller m...@thomaskeller.biz 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. We could choose to omit this section unless there is something in _MTN/log. 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. 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. 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. Trimming is probably required if we choose to left align the headers anyway so I should probably just do that. 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 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. 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. In keeping with the Foo: header lines I was thinking of replacing Changes against parent x to something like Changes: x and omitting the x for root commits where there is no parent. Note that there may be 2 changes sections describing the changes from each parent to the new revision. Could we add support for custom certs here somehow? I thought of maybe adding a new hook get_commit_certs(branch), which would return a table of cert keys which are additionally added to the changelog editor (and which would be treated as optional, in the way that the user could remove them without letting the commit fail). Of course we could also enable the addition of any kind of custom cert just at commit time, but this might interfere with your current layout check code... The current code is quite simple and avoids trying to guess where things are. If it can't find something it aborts without looking any further. Presumably the current checking code could be smarter about how it looks for things but smarter code might get confused if you do something like duplicating the entire buffer in your editor by accident. Thanks for the feedback. Cheers, Derek ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Monotone-viz and repository structure.
On Tue, Feb 23, 2010 at 1:48 AM, Stephen Leake
stephen_le...@stephe-leake.org wrote:
hend...@topoi.pooq.com writes:
Right; you can pull any branch into any repository (= monotone
database). But then you do have to be careful not to accidentally send
a branch to an upstream repository; we don't want to have non-monotone
branches in the database at monotone.ca.
Except that we do... and the access rules seem to prevent one from getting
them.
$ mtn pull monotone.ca '*'
mtn: warning: protocol error while processing peer monotone.ca: 'received
network error: denied 'de...@echologic.com' read permission for '*'
excluding '' because of branch 'au.asn.ucc.matt.botan.monotone-2''
$ mtn pull monotone.ca '*' --exclude 'au.asn.*'
mtn: warning: protocol error while processing peer monotone.ca: 'received
network error: denied 'de...@echologic.com' read permission for '*'
excluding 'au.asn.*' because of branch 'ch.bluegap.home.markus''
$ mtn pull monotone.ca '*' --exclude 'au.asn.*' --exclude 'ch.bluegap.*'
mtn: warning: protocol error while processing peer monotone.ca: 'received
network error: denied 'de...@echologic.com' read permission for '*'
excluding '{au.asn.*,ch.bluegap.*}' because of branch
'com.opennetworksecurity.consulting.baesystems''
$ mtn pull monotone.ca '*' --exclude 'au.asn.*' --exclude 'ch.bluegap.*'
--exclude 'com.opennetworksecurity.*'
mtn: warning: protocol error while processing peer monotone.ca: 'received
network error: denied 'de...@echologic.com' read permission for '*'
excluding '{au.asn.*,ch.bluegap.*,com.opennetworksecurity.*}' because of
branch 'consulting.lp.se:AstraZeneca.RFS0091''
$ mtn pull monotone.ca '*' --exclude 'au.asn.*' --exclude 'ch.bluegap.*'
--exclude 'com.opennetworksecurity.*' --exclude 'consulting.lp.se*'
mtn: warning: protocol error while processing peer monotone.ca: 'received
network error: denied 'de...@echologic.com' read permission for '*'
excluding '{au.asn.*,ch.bluegap.*,com.opennetworksecurity.*,consulting.lp.se*}'
because of branch 'free.lp.se:elisp''
$ mtn pull monotone.ca '*' --exclude 'au.asn.*' --exclude 'ch.bluegap.*'
--exclude 'com.opennetworksecurity.*' --exclude 'consulting.lp.se*'
--exclude 'free.lp.se*'
mtn: warning: protocol error while processing peer monotone.ca: 'received
network error: denied 'de...@echologic.com' read permission for '*'
excluding '{au.asn.*,ch.bluegap.*,com.opennetworksecurity.*,consulting.lp.se
*,free.lp.se*}' because of branch 'internal.lp.se:admin.common''
$ mtn pull monotone.ca '*' --exclude 'au.asn.*' --exclude 'ch.bluegap.*'
--exclude 'com.opennetworksecurity.*' --exclude 'consulting.lp.se*'
--exclude 'free.lp.se*' --exclude 'internal.lp.se*'
mtn: warning: protocol error while processing peer monotone.ca: 'received
network error: denied 'de...@echologic.com' read permission for '*'
excluding '{au.asn.*,ch.bluegap.*,com.opennetworksecurity.*,consulting.lp.se
*,free.lp.se*,internal.lp.se*}' because of branch 'lp.se:courses.monotone''
$ mtn pull monotone.ca '*' --exclude 'au.asn.*' --exclude 'ch.bluegap.*'
--exclude 'com.opennetworksecurity.*' --exclude 'consulting.lp.se*'
--exclude 'free.lp.se*' --exclude 'internal.lp.se*' --exclude 'lp.se*'
mtn: warning: protocol error while processing peer monotone.ca: 'received
network error: denied 'de...@echologic.com' read permission for '*'
excluding '{au.asn.*,ch.bluegap.*,com.opennetworksecurity.*,consulting.lp.se
*,free.lp.se*,internal.lp.se*,lp.se*}' because of branch
'net.angrygoats.icalinate''
$ mtn pull monotone.ca '*' --exclude 'au.asn.*' --exclude 'ch.bluegap.*'
--exclude 'com.opennetworksecurity.*' --exclude 'consulting.lp.se*'
--exclude 'free.lp.se*' --exclude 'internal.lp.se*' --exclude 'lp.se*'
--exclude 'net.angrygoats.icalinate*'
mtn: warning: protocol error while processing peer monotone.ca: 'received
network error: denied 'de...@echologic.com' read permission for '*'
excluding '{au.asn.*,ch.bluegap.*,com.opennetworksecurity.*,consulting.lp.se
*,free.lp.se*,internal.lp.se*,lp.se*,net.angrygoats.icalinate*}' because of
branch 'net.randombit.botan''
*** botan was actually the branch I was thinking of when I started this
crazy probe ;)
$ mtn pull monotone.ca '*' --exclude 'au.asn.*' --exclude 'ch.bluegap.*'
--exclude 'com.opennetworksecurity.*' --exclude 'consulting.lp.se*'
--exclude 'free.lp.se*' --exclude 'internal.lp.se*' --exclude 'lp.se*'
--exclude 'net.angrygoats.icalinate*' --exclude 'net.randombit.botan*'
mtn: warning: protocol error while processing peer monotone.ca: 'received
network error: denied 'de...@echologic.com' read permission for '*'
excluding '{au.asn.*,ch.bluegap.*,com.opennetworksecurity.*,consulting.lp.se
*,free.lp.se*,internal.lp.se*,lp.se*,net.angrygoats.icalinate*,net.randombit.botan*}'
because of branch 'pingvinfabriken.se:foreningen''
$ mtn pull monotone.ca '*' --exclude 'au.asn.*' --exclude 'ch.bluegap.*'
--exclude 'com.opennetworksecurity.*' --exclude 'consulting.lp.se*'
--exclude 'free.lp.se*' --exclude
Re: [Monotone-devel] Problems with the tutorial
On Wed, Feb 3, 2010 at 5:30 PM, Stephen Leake stephen_le...@stephe-leake.org wrote: Thomas Keller m...@thomaskeller.biz writes: I'm not sure why the SQL update on next_roster_node_number should fail - given the fact that a previous INSERT worked - Stephe, Lapo, could you please have a look at it? I'm clueless... Total longshot... is there any chance a virus scanner fired up in the middle of this operation and somehow locked the database? Cheers, Derek ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] invalid author and committer values produced by git export
http://savannah.nongnu.org/bugs/?28372 Apparently author names that don't match the Name email format are imported ok by git but the resulting repo has some sort of problems, although I don't have any details on the nature of the problems. Currently we grab both the value of the author cert and the key that signed the author cert. The value is to be used as the git author and the key name is to be used as the git committer. Both of these are looked up in the author map to see if the user has specified replacement values that should be used in the exported data. If no replacements have been specified both the author and committer are checked to see if they contain '' and '' characters and if neither are present they are wrapped in these characters. This produces names that lack the Name before the email and apparently causes problems. If I remember right, there was once some interest in an option to require these values to exist in the author map file avoiding any automated doctoring of the author and committer values or failing if unmapped values exist. Having this might be one way to deal with the above problem. Reasonable suggestions for what to call such an option are welcome. I can't think of anything catchy. Another solution is to do more comprehensive checks on the author and committer values if they don't exist in the author map file, such as the following: If the value doesn't contain and characters - replace foo with foo foo if no @ character exists - replace f...@bar with foo f...@bar If the value begins with '' and ends with '' - replace foo with foo foo if no @ character exists - replace f...@bar with foo f...@bar Maybe these adjustments should be done in a lua hook that can be customized if needed. Finally, ensure that the resulting values match a valid git name regex, something like ^[^]* [^]*$ and fail if they don't. This could check values coming from the author map in addition to values constructed by the replacements above or could apply only to the automated replacements. Again, maybe this regex should come from a lua hook or perhaps the entire validity check should be done by a lua hook, either of which can be customized. Comments? Cheers, Derek ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: [PATCH] git_export: improve mark import when file is empty
On Fri, Dec 18, 2009 at 2:50 AM, Felipe Contreras felipe.contre...@gmail.com wrote: Anything wrong with this patch? Derek, can you please apply it? Looks fine to me. Applied in 01e79cd4d9e0e307431d16422820a7537b23df92. Sorry it took so long. Cheers, Derek ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] new bisect command
On Fri, Dec 18, 2009 at 2:31 AM, Thomas Keller m...@thomaskeller.biz wrote: Ok, I'm looking forward to your merge to nvm then. Merged in a8ac6a5f9fdd9d124cdd42d965e66897e030ecc8. Cheers, Derek ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] new bisect command
On Tue, Dec 15, 2009 at 1:18 PM, Thomas Keller m...@thomaskeller.biz wrote: Am 01.12.09 06:49, schrieb Derek Scherger: On Tue, Nov 24, 2009 at 12:59 AM, Thomas Keller m...@thomaskeller.biz mailto:m...@thomaskeller.biz wrote: At first sorry for answering this late. Too much attention withdrawn on other things lately... No problem, I've been distracted for the last little while as well. Agreed. I haven't made any changes here yet, but the describe_revision function should probably be updated to output localized dates. At the moment the only thing that localizes dates is the log command. As this change can be main directly on nvm, it shouldn't affect your branch. Yeah, I'm ignoring this for now. Well, my blunt approach here would have been to use database::get_common_ancestors() and look if the returned list is empty. If yes, the revision should be part of another tree and thus not be considered in the bisection, no? Sounds plausible. Every time more revisions are marked as good/bad/skipped recompute the set of common ancestors of all the good/bad/skipped revisions and if that set becomes empty reject the new additions? I don't know if this is really all that important although it's probably a small change, I'm somewhat tempted to not worry about it for now. If we ensure that the revisions are all in the same tree like above, we could probably simply compare the revision heights, i.e. if we recorded a bad revision with revision height X and another bad revision with revision height X should be recorded, than the latter should not be considered because the bug seem to have been introduced in a revision with height = X, right? The same is true for good revisions, just that we should not record any with a height smaller than the last good revision we already have been recorded. But actually I'm not sure if this is also the correct thing for non-linear development lines, in which case we'd falsely exclude good/bad revisions we actually need to find the bug. Unfortunately I'm too brain dead at the moment to think about a graph which would reveal such a misbehaviour. I'm tempted to leave this for now too, so that I can finish updating the texi and merge. Cheers, Derek ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Crash on git_export
On Wed, Dec 16, 2009 at 9:35 AM, Phil Hannent p...@hannent.co.uk wrote: Does the git crash log contain anything helpful? Not that I can tell, attached. Yeah, it looks almost completely empty. I suspect it's crashing on the first blob. I assume you must be running through a pipe and it doesn't look like your database is all that big, so can you export to a file and import from that? To be honest I am not sure how I would go about that? I have just tried: $ mtn git_export --db ../lynx.mtn --refs=revs --authors-file=authors_map.txt --use-one-changelog text.txt When I do: less text.txt The line ending are ^M oddly. I assume you're running in cygwin or something. Does 'od -c text.txt' show \r\n at the end of the blob command? If it does that looks even more like it is the problem. The export writes its data to std::cout which probably needs to be re-opened in binary mode to avoid translating line endings from \n to \r\n. I'm not sure there's a platform independent way of doing this and I don't have a windows development environment set up to test on so I'm not going to be much help with getting it fixed. Maybe someone else who does have a windows environment set up could have a quick look? Is there any chance that the pipe or something else is turning blob\n into blob\r\n and the unsupported command is blob\r ? Could well be. I guess I might be the first person to try this on Windows. Entirely possible. Once you have exported to a file can you import the first half of the file, the first quarter, or the first few revs? I am not sure how to pipe the file into git. Something like: $ git fast-import text.txt You could also possibly try removing the \r's from the file with sed or tr but this is likely to fail if any of the blobs have embedded binary data that contain \r's that should be preserved. Cheers, Derek ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Crash on git_export
On Mon, Dec 14, 2009 at 9:34 AM, Phil Hannent p...@hannent.co.uk wrote: Hello, I am running a git_export command with monotone 0.45 on Windows XP in a cygwin shell, however it fails with: mtn: loading mtn: 2558/2558 fatal: Unsupported command: blob fast-import: dumping crash report to .git/fast_import_crash_3744 I notice that there was a fix to a regression for the export in the development source, am I seeing what has been fixed or something completely different? http://viewmtn.angrygoats.net/all/revision/file/a4499efd0bc957705460b3a1a17ca87172e64683/NEWS Whilst I note that the crash is with git I figure that monotone is sending something it does not like. It sounds like git doesn't like the blob command, but that doesn't make a lot of sense, since that's how you send data to it. What version of git are you running? Does the git crash log contain anything helpful? I assume you must be running through a pipe and it doesn't look like your database is all that big, so can you export to a file and import from that? Is there any chance that the pipe or something else is turning blob\n into blob\r\n and the unsupported command is blob\r ? Once you have exported to a file can you import the first half of the file, the first quarter, or the first few revs? Hope this helps. Cheers, Derek ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] new bisect command
On Tue, Nov 24, 2009 at 12:59 AM, Thomas Keller m...@thomaskeller.biz wrote: Am 24.11.2009 06:57, schrieb Derek Scherger: On Fri, Nov 20, 2009 at 4:01 PM, Thomas Keller m...@thomaskeller.biz wrote: 1) If an update to a revision failed, f.e. because the addition / removal of a node is blocked because of unversioned files, it tells me to re-run the process with --move-conflicting-paths - however what should be re-run here is only the update, because the bisect status has already been updated. This turns out to be quite simple so I've allowed for --move-conflicting-paths in 'bisect good/bad/skip' commands, which may all update the workspace. I've also added a 'bisect update' command to be used if you notice later that status is warning about the workspace being at the wrong revision. More on this below. I haven't looked at the implementation, but if you say this is a common code path, then yes, we should change it in mainline. I'm not particularily fond to make every single piece of output monotone gives configurable via a hook. If there's consent to reorder the output of describe_revision, then we should probably just do so. Otherwise we end up with a big chunk of hooks which change the output somehow which nobody quite follows and which may just slow down the output (I don't know how much of a time penalty there is to call into lua, but there certainly is one). Agreed. I haven't made any changes here yet, but the describe_revision function should probably be updated to output localized dates. At the moment the only thing that localizes dates is the log command. 4) If I'm in the mid of a bisecting operation and (accidentially) call mtn up, I'm updated back to the head revision (if that is possible at all) of the branch I'm bisecting. I can easily go back to the last revision to test by simply reissuing mtn good or mtn bad on an already marked revision (I tested that - cool!), but somehow I wished mtn bisect status would just tell me the revision which is currently tested so I could also update my workspace revision by hand... (this would also be handy for problem 1) when the update to a certain revision fails for some reason) I've changed 'bisect status' to warn if the workspace is not at the correct revision for the current bisection and also added a 'bisect update' command that will update the workspace back to the next revision selected for bisection. The 'bisect update' command also allows for the --move-conflicting-paths option so it can be used to deal with a previously failed good/bad/skip update. The simplest approach I could think of is to at least note in the output of mtn status that the parent revision is not in the same branch as what is noted in _MTN/options for the workspace. This might also be handy for people screwing around with _MTN/options to branch-off some trunk for a feature branch (the long awaited (tm) mtn branch command should fix that :) and I think its reasonable to give this information there because in my opinion mtn status is the most-used command _before_ a commit happens. The normal status command now outputs the current revision in addition to the current branch and will also report the old and new branches in the cases where the current workspace branch does not match one of the parent revision's branches, regardless of whether a bisection is in progress or not. For example: $ ./mtn st Current revision: 902eb1ca6aeb7de6d6601c20b9de735d290e3613 Old branch: net.venge.monotone.bisect New branch: net.venge.monotone.bisect.asdf Changes against parent feb303ed0811833626f532c189e79ca1324cf45a no changes Here, the old branch (on the parent revision) is 'net.venge.monotone.bisect'. The new branch (from _MTN/options) will be 'net.venge.monotone.bisect.asdf' if revisions are committed from this workspace. Yes, sure, thats definitely something which would be cool. However, to get bisecting complete, I'd still say it would be enough in first instance to just give mtn status a hint about an ongoing bisection. We can still rework this later on the changelog editor branch. Good advice. The bisect branch is in much better shape now than before your review and handles a couple of other problems I hadn't thought of so thanks again. I wasn't sure at first how I as a user was supposed to use bisection (didn't used that in git or any other vcs until now), so my personal use case was at first I found a bug, but I don't know exactly where it happened. Ok, I enable debug output, start bisecting and look at the output..., which obviously won't work if enabling the debug output requires a code change. I learned however that bisecting is even more a perfect tool for automated bug finding and that my approach might also be honored with a simple patch(8) call... I've been doing quite a bit of bisecting lately, unfortunately with subversion, which has no native support and seems to fail to update my
Re: [Monotone-devel] new bisect command
On Fri, Nov 20, 2009 at 4:01 PM, Thomas Keller m...@thomaskeller.biz wrote: 1) If an update to a revision failed, f.e. because the addition / removal of a node is blocked because of unversioned files, it tells me to re-run the process with --move-conflicting-paths - however what should be re-run here is only the update, because the bisect status has already been updated. Maybe the update of the status information should be delayed until after it has succeeded? I'll think about this one a bit. 2) When two revisions are bisected which have no revisions in common (f.e. because they don't have the same root revision), bisecting them just gives me the starting revision. Maybe this is not a common case, but maybe we could be smart enough to detect if a given revision is not even part of the same tree? Yeah, that's a good idea. I'm not particularly fond of the current implicit assumption that good is assumed to be an ancestor of bad at all. If we determine which is an ancestor of the other, or if there is no ancestry relationship I should be able to sort this out as well. 3) A localized date output format for the revision and maybe a hint on which branch it is would be nice. I'm using describe_revision throughout and I notice that it doesn't currently handle localized date formatting. Maybe we should change this on mainline and I'll just get that for free? I also wonder whether describe revision should be a hook so people can customize it to their liking. I've often thought that date should be listed before author, because dates are fixed length strings and authors are not and this might make for slightly better output. I wonder if anyone is strongly attached to the current output? 4) If I'm in the mid of a bisecting operation and (accidentially) call mtn up, I'm updated back to the head revision (if that is possible at all) of the branch I'm bisecting. I can easily go back to the last revision to test by simply reissuing mtn good or mtn bad on an already marked revision (I tested that - cool!), but somehow I wished mtn bisect status would just tell me the revision which is currently tested so I could also update my workspace revision by hand... (this would also be handy for problem 1) when the update to a certain revision fails for some reason) It would be easy to list the last tested revision with its good/bad status. Perhaps I should have it list all explicitly tested revisions, in order? I did wonder a bit about whether a bunch of workspace modifying commands should refuse to operate while a bisection is in progress but I'm not sure if this is a good idea. The simplest approach I could think of is to at least note in the output of mtn status that the parent revision is not in the same branch as what is noted in _MTN/options for the workspace. This might also be handy for people screwing around with _MTN/options to branch-off some trunk for a feature branch (the long awaited (tm) mtn branch command should fix that :) and I think its reasonable to give this information there because in my opinion mtn status is the most-used command _before_ a commit happens. I' hoping to get back to the changelog-editor branch that I started a while ago and the idea of marking the 'Branch: ...' line with a (new) or (changed) flag might be appropriate in this case. I still like the general idea on this branch that the display of a revision from status (an uncommitted revision), commit (a revision being committed) and log (a previously committed revision) should be reasonably consistent. Including a bit more information in the status case (whether the branch has changed, maybe where the root of the workspace is, etc.) seems fine too. I also recall seeing a question in irc (?) about why bisect refuses to function in a modified workspace. The rationale I had in mind was just that updating all over the tree while carrying along some uncommitted changes seemed like a good way to hit a conflict and possibly lose the pending changes.I was being conservative in requiring that you don't have any changes to lose before starting the bisection. Thanks for the comments. Cheers, Derek ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] new bisect command
I've finally found the time to finish up the bisect command I started working on earlier in the year and it's now ready for review on the net.venge.monotone.bisect branch. There's one item I'd like some feedback on before merging this to mainline though: In the process of bisecting, the various bisect good/bad/skip commands update the workspace to the next revision to be tested based on the results of the last test. In doing so, these commands do *not* update the workspace branch option in _MTN/options, partly because there's no guarantee that the selected revision has a branch option, or that it has only one branch option and I don't think it's sensible for bisect to fail in these cases. If, in the middle of a bisection operation, one finds the bug they're looking for, and commits a fix against that rev before completing the bisection, there's the possibility of using the current workspace branch option when they might have intended to commit to some other branch. I'm not sure what the best way to deal with this is. One option would be to make lots of other commands fail if there is a bisection operation in progress, but that doesn't seem particularly great. I'm interested if anyone else has ideas on how to handle this, or whether it's actually a real problem that even needs to be handled. Also, if anyone sees an easy way of adding an erase_descendants function to graph.cc that works similarly to erase_ancestors I could use it in bisect. I'm doing something else at the moment which works ok, but erase_descendants would be a better solution. Cheers, Derek ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] monotone questions on stackoverflow.com (automatic tarball?)
On Wed, Sep 9, 2009 at 12:29 AM, Richard Levitte rich...@levitte.orgwrote: Hmmm, you're writing something about unchecked pulls, and it has me wonder if that could be an idea to explore... Right now, with just half a minute of thought, I wonder if it would be possible to have some kind of lazy check, that new revisions wouldn't be checked during pull, but rather when used for the first time... I wonder how long a full pull of the monotone database would take with SHA1 checking disabled on the client or on the server or (shudder) on both verses with it enabled on both sides as it is now. I think I've heard that the pidgin server is generally working pretty hard and I wonder if it would be a reasonable idea to have it not do any SHA1 checking and instead expect/require/hope that the clients pulling from it would do the checks themselves? This would at least distribute the work of checking revisions over N clients rather that putting it all on one server. Presumably the server would want to be checking incoming revs regardless of such a setting. Obviously a switch to turn off SHA1 read checks at the database level is a rather dangerous thing but if it does make a big difference to network performance then maybe it's not all bad. I'm not sure how much checking of things the competition does, but my impression is that monotone does more and suffers an apparent performance hit because of it. Cheers, Derek ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] netsync flag day justifies bumping version number to 1.0
On Wed, Aug 26, 2009 at 7:44 AM, hend...@topoi.pooq.com wrote: But if protocol negotiation won't do the whole job (and it looks as if it may not) it would simplify my life immensely if the protocol to use were made a command-line parameter on the mtn sync command. We could even store a default value of this parameter in the _MTN directory after a successful sync. It seems like it should be possible for a *new* client to negotiate a protocol to use with an old server. When the new client connects to the old server, the older server sends the initial hello that says I want netsync protocol version 6 (which is what it is currently at) so the new client just needs to respect this and use the old protocol. Even if the client needs to do do something drastic and reconnect, it should be able to come up with some means of talking to the old server. I'm assuming here that the server always sends the initial hello packet, which I think someone mentioned earlier in one of these threads. Individual client upgrades are presumably easier than server upgrades and this would allow for clients to be upgraded ahead of servers so that all clients can be ready for a pending server upgrade. Such a command-line parameter would cut down on the number of versions of monotone that have to be maintained, and would simplify getting it all through distro maintainers. End users would have to be informed of the issues, though. It would be nice if the 0.45 server could deal gracefully with older clients, and vice-versa, but it's not a requirement. And there seems to be some question whether it's reliably possible to recognise older clients with the protocol they understand at present. At a glance, I concur with Tim that there's no space in the initial packet (other than the nonce) for a new server to hint to a client that it speaks a newer protocol. It _is_ a requirement that the 0.45 server and client be able to deal gracefully with any future client or server, even in the case of another netsync protocol change. And that we cen design in now. One discussion that we've had before centers around protocol version numbers verses specific features. Iirc SMTP's EHLO command may respond with a list of keywords indicating the various optional features that a particular implementation supports. Personally, I think I prefer this scheme over a simple version number check. It makes feature support explicit rather than implicit and up to the respective parties to infer based on what protocol versions they find. Cheers, Derek ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] netsync flag day justifies bumping version number to 1.0
On Mon, Aug 24, 2009 at 5:39 PM, Timothy Brownawell tbrow...@prjek.netwrote: On Mon, 2009-08-24 at 19:23 -0400, hend...@topoi.pooq.com wrote: Wasn't there a list of things that also needed a flag day -- with the intent that we do them all together and thus need only one flag day? All I'm aware of is the NetsyncTodo page, which isn't terribly concrete or complete, and generally has things that we either don't know how to do or haven't started on. From the top of netsync.cc // TODO: things to do that will break protocol compatibility // -- need some way to upgrade anonymous to keyed pull, without user having // to explicitly specify which they want // just having a way to respond access denied, try again might work // but perhaps better to have the anonymous command include a note I // _could_ use key ... if you prefer, and if that would lead to more // access, could reply I do prefer. (Does this lead to too much // information exposure? Allows anonymous people to probe what branches // a key has access to.) // -- warning packet type? // -- Richard Levitte wants, when you (e.g.) request '*' but don't have // access to all of it, you just get the parts you have access to // (maybe with warnings about skipped branches). to do this right, // should have a way for the server to send back to the client right, // you're not getting the following branches: ..., so the client will // not include them in its merkle trie. // -- add some sort of vhost field to the client's first packet, saying who // they expect to talk to In case there's anything in there that we want to throw in while we're at it ;) It seems like the usher packet might take care of the last one. Cheers, Derek ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] list branches on server?
On Sat, Aug 22, 2009 at 11:20 PM, Zack Weinberg za...@panix.com wrote: It doesn't need Boost.System, but it does still depend on a few pieces of boost that we're not currently using, notably boost::date_time::posix_time, bleah. True enough. This looks like it's mostly internal to asio, although the deadline_timer stuff exposes it. We might be able to replace: typedef basic_deadline_timerboost::posix_time::ptime deadline_timer; with typedef basic_deadline_timerdate_t mtn_deadline_timer; for monotone's use. Although this still leaves us requiring boost to support asio I guess. Yeah, there's not much of an alternative there unless you want to implement your own DNS resolver, which isn't a good idea. [Linux does have getaddrinfo_a, but it's not portable, it may still use threads under the hood, and it reports completion with *signals*. Gag.] Yeesh. Another thought on this that I've had floating around for a while is that perhaps rather than starting a second process and running netsync over stdio we could have two separate database instances open and sync between them from within a single process. I haven't looked at this in any detail at all so it might just be a crazy idea, but I think it would avoid all of the windows related network issues. Maybe some of the refactoring that zack and markus did a while ago relating to app_state, options and database arguments in various api's would make the idea of having two open database objects less crazy? That was one of my goals, in fact. We may not be 100% of the way there yet though. Great, I remember looking at that a while ago and thinking that it didn't look to be too far off. Cheers, Derek ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] list branches on server?
On Sat, Aug 22, 2009 at 11:49 AM, Timothy Brownawell tbrow...@prjek.netwrote: I think dscherger is looking into using boost::asio (net.venge.monotone.asio), which includes ssl support (I think including client certificates, which we need) but would take us back to linking against boost libraries again. I have been looking at this a bit, largely staring at netsync.cc to try and get a better idea of what it's doing though. Note that the net.venge.monotone.asio branch that zack started a while ago does not use boost::asio, but the standalone variant that does not require linking against the boost libraries as far as I can tell. It does seem to need -lpthread on linux though as asio apparently uses threads internally to simulate certain asynchronous operations. See http://blog.think-async.com/2008/05/boostasio-vs-asio.html for more details on the non-boost asio variant. So the question is, what needs to be done on the asio branch? And how can we mitigate the problems people have with linking against boost? Pretty much everything at this point, as far as I can tell. I haven't found the asio docs to be all that great when trying to actually think in detail about how it will fit in to what netsync is doing, but on the surface at least asio seems fairly reasonable. I'd also like to get 'mtn sync file:' working on Win32; last I checked, that meant replacing netxx with boost::asio. Is that affected by the ssl transport change? Another thought on this that I've had floating around for a while is that perhaps rather than starting a second process and running netsync over stdio we could have two separate database instances open and sync between them from within a single process. I haven't looked at this in any detail at all so it might just be a crazy idea, but I think it would avoid all of the windows related network issues. Maybe some of the refactoring that zack and markus did a while ago relating to app_state, options and database arguments in various api's would make the idea of having two open database objects less crazy? Cheers, Derek ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] list branches on server?
On Sat, Aug 22, 2009 at 12:40 PM, Stephen Leake stephen_le...@stephe-leake.org wrote: Building that branch on Debian dies in netsync.cc on: #include netxx/address.h #include netxx/peer.h #include netxx/probe.h #include netxx/socket.h #include netxx/sockopt.h #include netxx/stream.h #include netxx/streamserver.h #include netxx/timeout.h #include netxx_pipe.hh so apparently we need to edit netsync to use asio. Yeah, that seems to be the current state of things. ;) configure says mtn requires asio 1.2; Debian 5.0 (lenny stable) has only asio 1.1.1. sid unstable has asio 1.4.1; that might be promoted to stable before we get done with this :). I wondered about this as well. I happen to have boost 1.35.0 installed which has boost::asio version 1.0.0 and I wondered whether there was anything specific in asio 1.2 that we need? In an ideal world it might be nice to be able to use either boost::asio or asio for the cases where someone has one or the other (or both I guess) installed. Cheers, Derek ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] list branches on server?
On Sat, Aug 22, 2009 at 1:59 PM, Timothy Brownawell tbrow...@prjek.netwrote: The two that come to mind are * different (and therefore annoying) build system 100% agree, however with plain asio we don't need to pull in boost and its sucky build system so this shouldn't be an issue. * version skew wrt libstdc++, eg boost and monotone have different ideas of what exactly an std::string looks like Fantastic. Can you elaborate on this? I wonder how it's even possible when boost is built with the same libstdc++ as monotone on my machine? Cheers, Derek ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] list branches on server?
On Sat, Aug 22, 2009 at 3:45 PM, Zack Weinberg za...@panix.com wrote: I suppose I should pop back in at this point, since I started the asio branch, and admit that I got stuck. In addition to the above problems, asio has what is IMO a serious design flaw: its I/O channel objects are statically typed. Since we wish to treat sockets, pipes, and whatever-fds-0-and-1-are as interchangeable, this requires a large hairy wrapper around all asio interfaces, which I started but got bogged down on. I'm also not sure asio's Windows support is good enough for us. I've been looking at libevent instead, but it has its own problems, e.g. not handling the creation of a network socket. It's written in C, though, so there's no question of ABI skew, and it uses a normal build system. My impression is that libevent doesn't give us anything in the way of ssl help, while asio does do provide some support and uses openssl under the covers. I vaguely recall that there were/are licensing issues with using openssl directly but maybe that was back in the days of bundling various library sources or something? Cheers, Derek ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] list branches on server?
On Sat, Aug 22, 2009 at 11:15 PM, Zack Weinberg za...@panix.com wrote: I wasn't aware that SSL was on the table, to be honest :) Libevent Yeah, what got me thinking about asio was thinking about nuskool and wondering what we might do to support https, particularly on the client side. We could probably get away with not supporting https on the server side by fronting with apache or something. does not have any SSL implementation. But shouldn't that be done by, or on top of, Botan rather than at a lower level? Very possibly yes. I haven't looked at how botan might help us here, if at all. Jack, can you comment? Cheers, Derek ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] diff --reverse?
On Mon, Jul 13, 2009 at 5:39 PM, Stephen Leake
stephen_le...@stephe-leake.org wrote:
I'd like to add a '--reverse' option to diff.
...
if (app.opts.reverse)
{
// FIXME: this breaks something in graph.cc
make_cset(new_roster, restricted_roster, excluded);
make_cset(restricted_roster, old_roster, included);
}
else
{
make_cset(old_roster, restricted_roster, included);
make_cset(restricted_roster, new_roster, excluded);
}
But this breaks an invariant in graph.cc when app.opts.reverse is
true.
I have two questions:
1) 'excluded' is a local variable; it is _not_ returned to the caller.
'included' is returned to the caller. Yet it seems that 'excluded'
contains the diff they are interested in! How does this work? Why are
There are three rosters involved: (1) the old_roster which is the one you're
diffing from, often your workspace base roster; (2) the new_roster which is
the one you're diffing to, generally the unrestricted content of your
modified workspace; and (3) the restricted_roster, which is some distance
between the old and new roster, depending on what files have been included
in the restriction. If there is no restriction specified then all changes
are included and restricted_roster == new_roster. If an overly restrictive
restriction is specified then no changes are included and old_roster ==
restricted_roster.
The included cset contains the changes from the old_roster to the
restricted_roster (those that are included by the restriction). The excluded
cset contains the changes from the restricted_roster to the new_roster
(those that are excluded by the restriction).
The reverse diff you are looking for is the one from the new_roster back to
the restricted_roster. The remaining diff from the restricted_roster back to
the old_roster will contain the changes excluded by any restriction. I think
you just need to swap included/excluded in you cset construction.
The comments in restrictions.hh might help. Also, although revert doesn't
actually use a cset to do the real work, there are some comments in there
describing what should happen if it did. If you can get your head around
what that would do you should have it figured out! ;)
we building two csets, but only returning one of them?
From what I can see the excluded cset is never used, calculating it is
completely redundant and should be removed.
2) Any suggestions for fixing this? I'll investigate graph.cc myself,
but I'm hoping someone has some pertinent advice.
A complete guess but the new_is_archived flag is probably used to pull the
new revision_from the database in the case when it lives there. When you're
going in reverse new probably has a different meaning. If your workspace
is uncommitted and you're attempting to diff from some committed revision
*back* to your uncommitted workspace then new really means old (i.e.
your workspace) and new_is_archived should be false.
Hope this helps.
Cheers,
Derek
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
