Date: Sat, 16 Dec 2000 19:31:29 +0200 From: "Eli Zaretskii" Sender: halo1 AT zahav DOT net DOT il To: "Tim Van Holder" Message-Id: <4634-Sat16Dec2000193129+0200-eliz@is.elta.co.il> X-Mailer: Emacs 20.6 (via feedmail 8.3.emacs20_6 I) and Blat ver 1.8.6 CC: djgpp-workers AT delorie DOT com In-reply-to: Subject: Re: MS-DOS path support in CVS References: Reply-To: djgpp-workers AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: djgpp-workers AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk > From: "Tim Van Holder" > Date: Sat, 16 Dec 2000 10:39:52 +0100 > > > In addition, we could make the I/O mode be sensitive to the repository > > location: a remote repository is probably almost always a Unix box. > I'm not sure that would be a good idea. And besides, the Unixness of the > repository doesn't matter that much anyway - it's what's stored in it > that matters. If a repository is on a Unix box, it means you need to write files in binary mode when checking them out. > if, say, you checked out the CVS sources (in text mode, > so you end up with all CRLF). You edit some files, including the > MSVC project files. You make a diff, which would either use text mode or > binary mode. > If it used text mode, the patches to the project files would fail (as > they're CRLF in the repository). And if binary mode was used, you'd be > introducing CRLFs into the Unix-style sources. Sorry, I'm not following: in the scenario you described above, what did the user create the diffs for, and how are they relevant to the routine CVS operation? If you are talking about the CVS client sending diffs to the server, then it should use the same logic as we talked before: read files in binary mode if that's the default, or in text mode if the user overrides the default. If the local CVS tree is kept in Unix-compatible format (which I think should be the default for remote repositories), then binary reads for computing diffs will always DTRT. > Unless I'm mistaken about how patch --binary operates, it would not help > in this case I thought you were talking about Patch invoked locally, not on the remote server. Are you?