On Mon, Nov 27, 2006 at 10:22:25AM -0800, Justin Patrin wrote: > On 11/27/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > >On Mon, Nov 27, 2006 at 11:52:53AM +0000, Bruce Stephens wrote: > >> Richard Levitte - VMS Whacker <[EMAIL PROTECTED]> writes: > >> > >> [...] > >> > >> > That leads me back to thinking that we still need to mark files that > >> > are getting changed, and that something automatic should happen to > >> > them, so a file will look the same checked out as before it got > >> > checked in. > >> > >> I'm sure we discussed all of this the last time around (and probably > >> the time before that; possibly I'm thinking of discussions in OpenCM > >> or GNU Arch). > >> > >> Storing things as binary seems easy, but that's likely to cause > >> irritation for projects that use Windows and Unix. > >> > >> More aggressively converting files that look texty also seems not too > >> hard, but it may break files that have inconsistent line-endings, and > >> files that are text but require a specific line ending convention. > >> > >> On the whole I think the second is a better option. Basically do what > >> subversion seems to do: guess when files are text, and mark them as > >> such; have an option that lets people specify the line-ending > >> conventions of a file, but by default assume the native convention. > > > >I remain against doing any conversion based on a guess. > > As a heavy user of version control systems (CVS, SVN, and MTN mostly)
So you might be qualified to report on their relative merits in actual use? I've found charts on the web comparing features, but these give me no insight into what happens in practice -- what the real day-to-day irritations are. Any experience with bzr? > I'm also against any automatic conversion of text line endings. While > I understand that "some editors" and "some programs" don't like > certain line endings, in the general case it's easier to just leave > things as they are. 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. > Most programs and editors are fine with any type > of line ending and will work correctly on them. If there is a problem > then the user or repository manager can set a setting that will > convert the files. The default should always be "leave it alone, let > the user/repo admin/person checking in decide whether to convert". Of course, being to be able to declare the file format and get a syntax check (such as correct line-endings) would be quite helpful in it was done cleanly and allowed revisions to explicitly change the file format as well as the contents. This does open the door to a very long corridor of potential syntax checks, but I suggest we leave C's syntax check to the C compiler. (Actually, this corridor has a number of interesting rooms on it, such as custom merge algorithms for specific file types -- I can imagine, for example, that edited JPEG images might usefully be merged by quite different algorithms from C source code. :-) But conversions should be requested explicitly. I wouldn't even mind if a request for conversion-to-local on checkout were to be treated as a request for conversion-back-to-archive on checkin if the conversions were one-to-one and reversible. -- hendrik _______________________________________________ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel