[Monotone-devel] [ANNOUNCE] North America Mtn Summit: Feb. 5-11 2007, Mountain View
Okay, time to just go for it. I hereby declare that Mtn Summit 2007, North American edition, will be held February 5-11 in Mountain View. Be there or... don't be there. But you'll totally be missing out on balmy California weather, seeing core monotone developers scribbling madly on whiteboards, and the famous Google Cafeteria! I have updated the wiki page with lots of stuff: http://venge.net/monotone/wiki/MtnSummit If you are coming, please sign up on the wiki! This will help us figure out things like, how many hotel rooms we will need. But, if you don't know yet, that's cool too. There is also a box there for whether you need money to attend, and also whether you are able to help others attend! I'm not sure a little box in a table is enough to adequately capture the full complexities of people's financial situations, but we'll give it a try. If you can help, please say so! This is gonna be awesome. -- Nathaniel -- Electrons find their paths in subtle ways. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Call for contributions: Lua Programming Gems
You have a project listed in our project page and I thought you might be interested in contributing to a book on Lua Programming Gems which we plan to publish. Here is a formal call for contributions, which is also available at http://www.lua.org/gems/ Thank you very much. We hope to hear from you. --lhf --- CALL FOR CONTRIBUTIONS: LUA PROGRAMMING GEMS We plan to publish a book on "Lua Programming Gems", along the lines of the famous "Graphics Gems" series and other similar series. The book will be edited by the Lua team and published by Lua.org, like PiL and the Lua Reference Manual. The goal of the book is to collect and publish existing wisdom and practice on how to program well in Lua (including the C API). Gems can range from detailed tutorials on Lua features to advanced techniques and tricks, like the late Lua Technical Notes. Interesting case studies of how Lua can make a difference in a concrete application are also welcome. In particular, the book will be an opportunity for wiki authors and other Lua experts to polish and publish their contributions. A gem should contain around 3000 words or 10 pages. We shall ask contributors to the book to license non-exclusive rights on their contributions to us. Authors will retain copyright of their work. If you are interested in writing one or more Lua Programming Gems, please send a one-page, 300-word abstract in plain text to [EMAIL PROTECTED] by 10 Jan 2007. The editors will review and select gems based on these abstracts. Here is the timetable for the first phase: 10 Jan 2007 - one-page abstracts due 01 Fev 2007 - authors notified of selection results 01 Jun 2007 - full text due During the second phase, the editors will work with the authors to polish their contributions. We plan publish the book in Dec 2007. --- ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] RFE: have monotone check line endings on commit
One of the things that is missing in this discussion are real concrete use-cases. The main one that I have had to contend with is: Assumption 1: VCS does no line ending conversion. Assumption 2: Line endings in repository are all "correct" per the project's conventions Assumption 3: All editors in use by developers can correctly handle non-native (to their workstation) line endings Step 1: User makes minor modification to workspace file Step 2: User XYZ *unwittingly* saves/commits a file with a different line ending than the previous revision. Step 3: Monotone now thinks that every line in the file has changed. Diff & merges break. One use case that may have been covered, but that I haven't seen addressed yet: I work (unfortunately) on a windows machine, but use cygwin where possible to have a more familiar (sane) set of tools. On this machine, all of the source code has windows style line endings, even though my cygwin install is configured to use unix line endings. Most of the time I have no problems, however when I propagate or merge rev's, the automatically merged files end up with unix style line endings on next checkout/update. This is (probably) caused by my mixed environment, but is annoying none-the-less I think some sort of attribute that specified the type of line-endings that a particular file should have on checkout would help. Patrick ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: line endings as project policy
On Mon, Nov 27, 2006 at 01:28:42PM -0800, Justin Patrin wrote: > On 11/27/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > >Some OS's make it hard for rank beginners (though possibly experienced > >on other systems) to find out how to do the necessary conversions. But > >that is not a version control problem. > > What conversions do you mean? Any decent text editor should be able to > deal with any line ending and not mess with it. Of course, I use emacs > which does the right thing with any of the three. Leaves it alone. I use emacs, too. Now that it has started guessing the file type depending on the line endings, it's getting hard to change the line endings when you need to! > However, I just thought of one case where some auto-munging would be > nice. Some of the people in my office use DreamWeaver to edit some > code and it always changes the newlines to whatever it's set to It > will read in any, but always save in what you have set, which is of > course mac newlines by default. It would have been nice if the VCS > said "newlines are different" and stopped the checkin as I then have > to go fix that person's editor, then change the newlines on the files > they changed, then re-check them in which kills the log/blame. Which suggests one option is to * recognise line-ends of any variety * ignore the line-end type when merging lines * but then, for lines that haven't changed except for line ending, restore the original line-endings so that the differences don't become excessive. This does require that the merge have some idea of which is the "original" and which is the "changes". -- hendrik ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: line endings as project policy
On Tue, Nov 28, 2006 at 07:43:51AM -0500, [EMAIL PROTECTED] wrote: > > Which suggests one option is to > * recognise line-ends of any variety > * ignore the line-end type when merging lines > * but then, for lines that haven't changed except for line ending, I mean, lines that got line-ending-converted on checkout >restore the original line-endings so that the differences don't >become excessive. > This does require that the merge have some idea of which is the > "original" and which is the "changes". > > -- hendrik ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Bug/patch: automate stdio
On Sat, 2006-11-25 at 20:40 +0100, Christian Ohler wrote: > There's a pretty serious bug in automate stdio in mtn 0.31 and mainline. > Under certain circumstances, mtn gets confused reading its input and > processes a command that is different from what was sent on stdin. > > I believe the attached (one-line) patch fixes this. Unfortunately, I > see no easy way for me to provide a test case for this. Patch applied, thanks. And yeah, it'd be a bit of a pain to write a test for. -- Timothy Free (experimental) public monotone hosting: http://mtn-host.prjek.net ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Bug/patch: automate stdio
On Tue, Nov 28, 2006 at 12:05:02PM -0600, Timothy Brownawell wrote: > On Sat, 2006-11-25 at 20:40 +0100, Christian Ohler wrote: > > There's a pretty serious bug in automate stdio in mtn 0.31 and mainline. > > Under certain circumstances, mtn gets confused reading its input and > > processes a command that is different from what was sent on stdin. > > > > I believe the attached (one-line) patch fixes this. Unfortunately, I > > see no easy way for me to provide a test case for this. > > Patch applied, thanks. And yeah, it'd be a bit of a pain to write a test > for. I suppose we'd have to write some sort of mock iostream, that fed us bytes with random blocksizes? I think I've seen this done (in the twisted testsuite), but ugh... -- Nathaniel -- Electrons find their paths in subtle ways. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Bug/patch: automate stdio
On Tue, 2006-11-28 at 10:27 -0800, Nathaniel Smith wrote: > On Tue, Nov 28, 2006 at 12:05:02PM -0600, Timothy Brownawell wrote: > > On Sat, 2006-11-25 at 20:40 +0100, Christian Ohler wrote: > > > There's a pretty serious bug in automate stdio in mtn 0.31 and mainline. > > > Under certain circumstances, mtn gets confused reading its input and > > > processes a command that is different from what was sent on stdin. > > > > > > I believe the attached (one-line) patch fixes this. Unfortunately, I > > > see no easy way for me to provide a test case for this. > > > > Patch applied, thanks. And yeah, it'd be a bit of a pain to write a test > > for. > > I suppose we'd have to write some sort of mock iostream, that fed us > bytes with random blocksizes? I think I've seen this done (in the > twisted testsuite), but ugh... (echo -n "l6:le"; sleep 2; echo -n "avese") | mtn automate stdio The "bit of a pain" mostly comes from needing to implement spawn_pipe for Windows (since the patch posted a few days ago only does unix), and then figure out the right way to make it available in tester. Once that's done, actually writing a test should be pretty simple (see above shell example). -- Timothy Free (experimental) public monotone hosting: http://mtn-host.prjek.net ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] line endings as project policy
On Sat, Nov 25, 2006 at 08:44:59AM +0100, Richard Levitte - VMS Whacker wrote: > In message <[EMAIL PROTECTED]> on Thu, 23 Nov 2006 12:11:06 -0800, Daniel > Lakeland <[EMAIL PROTECTED]> said: > > dlakelan> On Wed, Nov 22, 2006 at 10:40:58AM +0100, Richard Levitte - VMS > Whacker wrote: > dlakelan> > dlakelan> > - We need to convert line endings to the local standard on > anything > dlakelan> >that's assumed to be text on checkout. This I regard as a > fact. > dlakelan> >(see the problem that some Unixly programs have with embedded > \r) > dlakelan> > dlakelan> Consider languages like Python that have the ability to > dlakelan> create multiline strings, now the \r or \n characters are > dlakelan> part of the string. Converting them changes the behavior and > dlakelan> meaning of the program. This is very tricky. > > Does it really? So, if I write that little example in a python > program in Windows, using notepad, I should expect my program to > expect differently on Windows than if I wrote that in emacs on a Unix > box and ran it on Unix? If that is to be *expected*, then I'm > immediately throwing away python for any future plans. I'm not quite sure what you mean, but basically the string continues over several lines and the newline characters become part of the string. Therefore, for example, if your string contains some data that is exactly what you're looking for in the output of another program, you'll be surprised when monotone alters the line endings in your string and your python program doesn't match the output of the other program it interfaces with. Yes, as someone said, this is dodgy code. But nevertheless I don't know why monotone should be altering the content of any text that it checks in. It WILL cause problems eventually. -- Daniel Lakeland [EMAIL PROTECTED] http://www.street-artists.org/~dlakelan ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: line endings as project policy
> "Justin" == Justin Patrin <[EMAIL PROTECTED]> writes: Justin> What conversions do you mean? Any decent text editor Justin> should be able to deal with any line ending and not mess Justin> with it. Of course, I use emacs which does the right thing Justin> with any of the three. Leaves it alone. I suspect many Windows text editors will automatically convert files, including wordpad (not checked). -- Brian May <[EMAIL PROTECTED]> ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] line endings as project policy
Sorry for prolonging this thread. Line ending conversion affects my "use case". I keep bash scripts in mtn that I copy by hand to other computers, and I generally use sha1sum to make sure that said computers have a certain version of the scripts installed (comparing their SHA1 against the log). The fact that mtn identifies file versions by their SHA1 is very elegant and probably the feature that caught my eye when I was shopping for a SCM. I think that having "each version is identified by the SHA1 of what YOU commit" is inherently better than "each version is identified by the SHA1 of the UTF-8 (or whatever format chosen) of what you commit". The fact that I have an external tool that agrees with monotone's idea of a file's contents gives me confidence in monotone. cheers nicolás Ulf Ochsenfahrt wrote: > This line ending thing is getting far too much attention, IMHO. My last > word on this issue is: > > - Whatever I check in, I want checked out > > - What I'd like to see is a setting where monotone checks on commit if > the files obey a particular line ending convention/charset and gives a > warning if they don't > > > I don't want any automatic conversion of line endings or charsets. IMHO, > charsets are much too fragile and dangerous to be handled by monotone. > And line ending conversion cannot really be separated from charset > handling in the face of non-8-bit encoded charsets. > > That said, I am not opposed to an opt-in mechanism for line > ending/charset handling, as long as its not on by default. > > The CVS way to do it was really, really bad. It messed up my files > several times, with duplicate line endings and with treating binary > files as text. > > Now, there's also another thing, which is a better merge ui, which is > much overdue now... > > Cheers, > > -- Ulf > > > > > ___ > Monotone-devel mailing list > Monotone-devel@nongnu.org > http://lists.nongnu.org/mailman/listinfo/monotone-devel ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: strange charset problem?
Nathaniel Smith wrote: On Mon, Nov 27, 2006 at 08:38:49PM +0100, Markus Schiltknecht wrote: Hi, I've found the bug: I've added a '--verbose' flag, which seems deprecated. Sorry for the noise. --verbose is totally warty (right now it means "use a randomly different output format when doing either 'mtn annotate' or 'mtn complete'"), but it still shouldn't make commands fail with incomprehensible error messages... IDNA has to do with i18n-ized domain names; not sure what they have to do with cvs_import. ACE means "ASCII compatible encoding", it's a term for the various encodings that the IDNA specs are designed to project into. Only one is in any use these days: if you see a string that begins "xn--" it's an IDNA ACE string under nameprep+punycode. I think it dates from back when we used SMTP and NNTP transports. I think I picked ACE as an encoding for a few of the data types like branch names, host names and key names to make them easier to map onto the non-8-bit-clean SMTP/NNTP infrastructure (mail hosts, protocol strings, headers, etc). It's mostly historical cruft, but continues to be the constraint on several of monotone's datatypes. Many operations will be constrained by them, not just networking. See: http://venge.net/monotone/docs/Internationalization.html -graydon ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: listing unknown directories
Bruce Stephens wrote: As long as there is still as recursive version, I am happy. I think the default ought to be the recursive one (as it seems to be for other systems (those that I use, anyway)). However, I've no idea whether either option is better in any objective sense. subversion, for example, does not list the contents of unknown directories in its status output at least. Personally I like not seeing all of the gory details most of the time. As far as optionally enabling/disabling recursive support goes, I'm not sure a --recursive option entirely makes sense. ls unknown is still generally recursive, just not in the case of unknown directories so I'm not sure what the option should be called. Alternatively, perhaps a hook that controls this would be better as it appears that most people want the current behaviour by default and maybe the "don't list content of unknown directories" option is more of a workspace type setting that a option that you want to flip back and forth on. Also for ls known and ls unknown, I would really like it if pathnames were relative to the current directory, not the base directory, ie: [EMAIL PROTECTED]:~/tree/config/include$ mtn ls known . include include/config.sh include/filter Jonathan Shapiro argued against that, based on some experience with OpenCM. It annoys me, too, but I can see the arguments on both sides. It doesn't seem at all clear that what monotone does now is wrong. Yeah, this has come up a few times and should be simple enough to implement. I'm curious to know what shap's objections would have been though. Do you have a link handy? Cheers, Derek ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
