RE: Activity-based CVS shell
It's a very nice idea. Essentially you are continuing what CVS started as (a bunch of scripts wrapping RCS up to be more useful). Kind regards, Peter Ring Forlaget MAGNUS A Wolters Kluwer Company -Original Message- From: Cees de Groot [mailto:[EMAIL PROTECTED]] Sent: Wednesday, May 24, 2000 8:59 PM To: [EMAIL PROTECTED] Subject: Activity-based CVS shell We just closed an evaluation of source management systems, and the good news is that we are sticking with CVS, Rational ClearCase lost the race. One thing we learnt, though, from talking and reading is that a lot of ClearCase customers take the time to define a process around the product, supported by shell-scripts, triggers, and whatnot. We feel that we want to do the same to CVS, so I am currently busy writing a shell around CVS (in Python) that offers an activity-based interface to the repository. The user typically won't say "I want to create a branch", but rather "I want to start working on bugfix xyz" - the shell will take care of branching, deciding when and what to merge, etcetera. I'm also planning a close integration with the bug tracking system we use, Bugzilla (so that a developer can click a button "Start work on this bug", which results in creating a branch etcetera).
RE: cvswrappers - any better suggestions ?
Quite often these days, CVS is not something that you choose -- you get chosen by CVS, much as you get chosen by Microsoft operating systems and development tools, simply because it's ubiquitous. Like it or not, there's not much respect for original design goals in the ways of the world. I suppose that 'full RCS compatibility' is not a goal by itself -- if you might as well use RCS, then why use CVS? I'd like to bring attention to one particular offspring of cvs: subversion. Have a look at http://subversion.tigris.org/. The project is near it's second major milestone, and plan to have an alpha release mid May and a 1.0 release late June. BTW, here's another way to use currently available features (aka cvswrappers) to avoid the poor loosers munging their binary files: Rather that listing patterns for known 'binary' files, you list patterns for known 'text' files, but default to binary, like this: # text formats *.[Tt][Xx][Tt] *.[Xx][Mm]][Ll] *.[Cc] #default is binary * -k 'b' Remember that cvswrappers doesn't work if you connect to the repository using a remote protocol (e.g. pserver); you must put a copy of the 'cvswrappers' file named '.cvswrappers' into each users home directory. Kind regards Peter Ring -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Greg A. Woods Sent: Saturday, 31 March, 2001 2:19 AM To: Gianni Mariani Cc: [EMAIL PROTECTED] Subject: RE: cvswrappers - any better suggestions ? [ On Friday, March 30, 2001 at 07:07:14 (-0800), Gianni Mariani wrote: ] > Subject: RE: cvswrappers - any better suggestions ? > > Your point is well taken. However, time are a changing - source code is not > only text. Image, sound, movie, geometry, encryption key, etc etc files are > all parts of modern day applications. All these files need to be version > managed just like regular files. If we could apply an rcsmerge on these > kinds of files, then it would be ideal. Yes, what you say is all very well and fine. What it means though is that CVS is not the correct tool for use in such a diverse environment. Obviously my point did not sink in properly though so I will say it more clearly: PLEASE go use something else ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: problem with LF <--> CRLF trasnlation
I'm 'messing' with line endings all the time. Usually, I stick to Unix conventions, because *nix tools tend to be more fussy. Most decent tools on Win32 don't care. If you work on Win32 and use Cygwin tools, go with the current default and use binary mounts; that will give you the least amount of problems. You can tell WinCVS to use LF in the administrative files, and it will coexist happily with the Cygwin port of cvs; the 'native' port, however, needs CR/LF in the administrative files. Kind regards, Peter Ring ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: problem with LF <--> CRLF trasnlation
While there might be some good reasons for native ports, the idea of native 'text' formats seems completely bogus to me. At least, it should always be an option, preferably per file (as is keyword expansion and merge behaviour). Kind regards, Peter Ring -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Eric Siegerman Sent: Thursday, 17 May, 2001 8:39 PM To: info-cvs Subject: Re: problem with LF <--> CRLF trasnlation I'd still prefer it if people used a native CVS client for their platform, of course, but as someone else said, they do insist on living dangerously... ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Is CVS free for commercial development?
Using cvs comes with no strings attached, except that you can only redistribute it and/or modify it under the terms of the GNU General Public License (GPL) as published by the Free Software Foundation. That is, if you redistribute derivative work, you must release the derivative work under the terms of the GPL as well, implying among other things that you must make the source code available. This is why GPL is called a 'viral license'. See GPL version 2 at http://www.gnu.org/copyleft/gpl.html. IMHO, the GPL has little effect for corporate deployment of cvs. You can safely use the distributed binaries and source 'as is' for any purpose you see fit. Any adaptions or customization is likely to be implemented as scripts that are not 'infected' by the GPL. And the projects in which you use cvs are are no legal way affected by the GPL because of your *use* of cvs. You can also develop and deploy *derivative work*, e.g., yet another authentification scheme or cvs client, but only inside your corporation. You can only distribute derivative work outside your corporation if you make the source available under the terms of the GPL. If in doubt, ask a lawyer. In any case, corporate users are also welcome to contribute patches, scripts, user guides, constructive criticism etc. Kind regards Peter Ring PS: I wonder whether a cvs client could be developed in a fashion that would make it not subject to the terms of GPL? This might be useful for interfacing non-GPL (BSD-style absolutely-no-strings-attached or more proprietary) software to cvs repositories. PPS: If you have an evening to spare for interesting reading, search for 'viral license'. You might also want to study a bewildering variety of 'open source' licenses: http://dmoz.org/Computers/Open_Source/Licenses/ http://directory.google.com/Top/Computers/Open_Source/Licenses/ PPPS: Micosoft doesn't like GPL, see http://news.cnet.com/investor/news/newsitem/0-9900-1028-4825719-RHAT.html?ta g=ltnc and http://www.microsoft.com/presspass/exec/craig/05-03sharedsource.asp. You don't have to be pro-Microsoft in order to see some issues with GPL, see e.g. http://www.onlamp.com/pub/a/onlamp/2001/03/08/unamerican.html. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Is CVS free for commercial development?
I was actually thinking of this new Microsoft EULA when I asked. Not that
I'd like to do a non-GPL client; and it would probably be necessary to study
not only the protocol documentation, but also the cvs source code, i.e., it
would be difficult to prove that I had not lifted a bit of code from cvs.
Microsoft is under pressure to release source code to Windows (or break up
the company), and have begun talking about 'shared source', which is why you
see so much noise about licenses.
http://www.microsoft.com/presspass/exec/craig/05-03sharedsource.asp
http://www.oreillynet.com/cs/weblog/view/wlg/293
http://www.e-businessworld.com/english/crd_microsoft_528040.html
In any case, the requirement in the EULA about not using 'viral' software
will be quite difficult to enforce in practice. I think it is a rather
defensive move.
Kind regards
Peter Ring
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
Matthew Riechers
Sent: Monday, 25 June, 2001 8:45 PM
To: [EMAIL PROTECTED]
Subject: Re: Is CVS free for commercial development?
Lan Barnes wrote:
>
> Matthew Riechers wrote:
> >
> > Peter Ring wrote:
> > >
> > > PS: I wonder whether a cvs client could be developed in a fashion that
would
> > > make it not subject to the terms of GPL? This might be useful for
> > > interfacing non-GPL (BSD-style absolutely-no-strings-attached or more
> > > proprietary) software to cvs repositories.
> >
> > As long as the client doesn't link directly to cvs code, you are ok. You
> > would either have to write your own code to handle the connection
> > protocol, or implement it as a simple wrapper to the cvs binary.
> >
>
> I fail to see why anyone would want to do that. Go to http://www.gnu.org
> and read the GPL (or even better, have your lawyer read it). Yes, CVS is
> GPL and so are many of its clients, but this fact has absolutely no effect
> on the license status of any software source maintained in a CVS
> repository. So writing a new client just to be something other than GPL
> makes no sense.
Exactly. The license of the client is irrelevant, especially when it's
just a command-line wrapper. There *are* programs that fall into this
catagory (to answer Peter's original query): UltraEdit, Visual
SlickEdit, Visual Studio, etc. The licenses of the clients in these
cases are proprietary, but who cares? It doesn't have any *added value*
feature that "embraces-and-extends" CVS; it just calls a program and
captures the output in a useful way.
> {NB: IANAL, but recent stories on /. and elsewhere indicate that the
> Microsoft EULA for the .NET SDK may forbid the use of GPL software tools
in
> conjunction with the SDK. If this is true and is enforceable, then using
> CVS or its GPL'ed front ends for archiving your own .NET SDK source code
> may violate your EULA.}
IANAL either... BTW, how many lawyers *are* on this list? :)
M$ seems to be trying to do an end-run around non-M$ licenses, by
bringing two otherwise disjoint things (code, storage mechanism) under
the same tool/system/license. So now I can't use my (possibly homegrown)
GPL'd [place utility here] to develop with a M$ SDK?!? This *could* have
an effect on how even simple intefaces (like the ones described above)
are handled legally. *shudder*
-Matt
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
cvswrappers, .cvswrappers and client/server
What is the current wisdom wrt. cvswrappers? We are using cvs 1.11 (or 1.11p1) client/server (via ssh). I've a .cvswrappers file to help make sure that the occasional binary file doesn't get munged, like this: *.c *.cpp *.h ... *.xml # anything else is binary * -k 'b' A previous version of cvs didn't really support the cvswrappers in the repository over remote protocols, so I got into the habit of having a ~/.cvswrappers. I believe that I've observed that I actually have to have the entries with no options (like '*.c') in both the $CVSROOT/CVSROOT/cvswrappers and the ~/.cvswrappers if *.c should not get added -kb. I tried to digest the source (wrapper.c), but must admit that I find it difficult to gather what exactly the code is accomplishing. Would I be better off with the more traditional list of known binary formats in $CVSROOT/CVSROOT/cvswrappers and ~/.cvswrappers, like *.[Aa][Cc][Gg] -k 'b' *.[Aa][Cc][Ll] -k 'b' *.[Aa][Cc][Mm] -k 'b' *.[Aa][Cc][Ss] -k 'b' *.[Aa][Cc][Tt] -k 'b' ... *.[Xx][Ll][Tt] -k 'b' *.[Yy][Bb][Kk] -k 'b' *.[Zz][Ii][Pp] -k 'b' Is the wrappers code designed to work in an 'additive' fashion so that the entries with options could be in either the $CVSROOT/CVSROOT/cvswrappers or the ~/.cvswrappers (or a local .cswrappers)? What takes precedence in case the options are different? Kind regards, Peter Ring ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: keyword substitution generates ^M
On Win32, I use the Cygwin cvs port and NTemacs with the pcl-cvs package. MS-DOS style files end up in the rep with a CR at the end of each line, and gets checked out the same - in effect as good ol' MS-DOS files. It's perfectly feasible to have a mix of CR-LF and LF end-of-record files in a project. I just have to take care 1) not to let anyone use Win32 'native' cvs to check out those files (that would add an extra CR in their sandboxes), 2) not to use Win32 'native' ports of CVS in the same sandbox; the Cygwin cvs port doesn't like CRs in the administrative files, and 3) use editors and tools that does not change the end-of-record format. Most good text editors on Win32 detects and preserves the end-of-record format. The simplistic distinction between 'binary' and 'text' is rotten anyway for several reasons. I'll just mention a very basic one. While ASCII (ISO-646) and UTF-8 encoded files can usually be dealt with as is on any platform (anybody still using EBCDIC?), it makes a real difference whether a file is ISO-8859-1 or ISO-8859-2 or whatever encoded. If you want to edit a text file (and those are the kind of files that cvs is meant for, right?), you sure want it to display correctly in your editor. Can't be done without information about the encoding. Kind regards Peter Ring -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Larry Jones Sent: 14. september 2001 20:59 To: Andreas Fabri Cc: [EMAIL PROTECTED] Subject: Re: keyword substitution generates ^M Andreas Fabri writes: > > I use cvs from within emacs under bash on NT. > > When I add a keyword and check the file in, cvs > perfroms keyword substitution, but unfortunately > also puts ^M at the end of each line. > > How can I avoid this. Work on a platform where text files don't end with . CVS works on text files. Text files on NT are *supposed* to have ^M at the end of each line. Proper NT text editors know that and don't display them. -Larry Jones Pitiful. Just pitiful. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: The future of CVS & Subversion
SourceForge is going to offer SV as an alternative to cvs (see http://sourceforge.net/forum/message.php?msg_id=232197). I perceive SV as a nice alternative (just as plain RCS, fancy BitKeeper, artsy PRCS, ambitious aegis, etc. etc.). It might be able to attract a large community, just as CVS has done it. Time will show. But CVS won't go away, and I'd never bet the farm on anything that new. Why not start with CVS (or whatever now), and consider SV a year from now? Kind regards, Peter Ring -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Andrew Johnson Sent: 21. september 2001 21:04 To: [EMAIL PROTECTED] Subject: Re: The future of CVS & Subversion Larry Jones wrote: > > Richard F Weber writes: > > > > Is subversion (http://subversion.tigris.org/) the future of CVS, or is > > it being developed by a totally separate group of individuals? > > It's a completely separate project. It's interesting to note though that one of the key developers Karl Fogel wrote one of the most comprehensive books on how to use CVS, and that Subversion is positioning itself to eventually take over many existing users of CVS by fixing many of the issues that have never been resolved in CVS (and arguably can't be because of its design). - Andrew -- Perfection is reached, not when there is no longer anything to add, but when there is no longer anything to take away. - Antoine de Saint-Exupery ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Checkout text files with the Unix LF (Oxa) - from command line
pfff ...
There's NOTHING except perhaps Notepad and a few other useless accessories
that need CR/LF as end-of-record on recent Windows operating systems.
If you have access to a Win2K box, please do me the favour to write a little
cmd or batch script with only LF as end-of-record, and run it.
BTW, if you use the Cygwin port of cvs for the command line, you can get the
desired behaviour. http://sources.redhat.com/cygwin. You certainly don't
need the full package of ported Gnu and open source applications; selecting
'cygwin' and 'cvs' should get you going (no guarantee). If you want to use
cvs through ssh, there's a nice description of a minimal install at
http://tech.erdelynet.com/cygwin-sshdmin.asp, though you shouldn't select
the 'DOS' option. Who cares about Notepad.
What's flawed is the idea that the end-of-record format in any text file
should be inherently determined by the operating system. Would you also like
your OS to determine what character set you should be allowed to use?
Kind regards,
Peter Ring
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
Mike Castle
Sent: 5. oktober 2001 19:41
To: [EMAIL PROTECTED]
Subject: Re: Checkout text files with the Unix LF (Oxa) - from command
line
On Fri, Oct 05, 2001 at 09:40:14AM +0200, PS wrote:
> I use WinCvs with checked option "Checkout text files with the Unix LF
> (Oxa)".
I would consider this a design flaw in WinCvs.
> And then I have a problem, because all updated files have every second
line
> empty. What to do to run that option (Unix LF) when I use cvs from command
> line in Windows.
You don't.
Either check the files out on a Unix box, or make it part of your build
process to transform the files from native format to Unix format.
check out file1.native
switch platform:
case DOS|NT:
dos2unix file1.native file1.unix
case UNIX:
cp file1.native file1.unix
case MAC:
mac2unix file1.native file1.unix
default:
error out unsupported platform
use file1.unix
mrc
--
Mike Castle [EMAIL PROTECTED] www.netcom.com/~dalgoda/
We are all of us living in the shadow of Manhattan. -- Watchmen
fatal ("You are in a maze of twisty compiler features, all different"); --
gcc
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Checkout text files with the Unix LF (Oxa) - from command line
Files are not suitable for the host (of your sandbox). They are suitable for certain uses in certain contexts. The host may or may not be part of the use, and the end-of-record format may or may not be important for the host. For example, I might need to manage configuration files for a multi-OS product. While I have both CR (MacOS), LF (*nix), and CR/LF (CPM/MS-DOS) end-of-record files, my editor (emacs) deals with this transparently, and the OS that holds the sandbox have no use for 2/3 of the files. Why should I need to check out files on a Mac just to do something that might as well be done on Windows or Linux? The canonical end-of-record format in RCS/CVS history files is LF. This has the interesting consequence that you can manage text files with CR/LF end-of-record as if they had LF end-of-record; there is just an CR as the last character of each record. Whether this is acceptable or not depends on the uses of each file. IMHO, there's no safe way to infer the encoding (character set) etc. except by managing some metadata explicitly. This is why SGML, XML and HTML files (which are text files by any account) have explicit statements about their encoding, except that UTF-8 is the default encoding for XML files, i.e., UTF-8 is assumed if you do not specify something else. UTF-8 has some nice properties that makes it suitable as a default encoding for exchange of files: there's no byte order that you must know, because each character is encoded as a sequence of bytes, and most letters in Western alphabets get encoded in one or a few bytes. For many purposes, you can deal with it as if it was ASCII. I really don't know what should be the preferred end-of-record format. I tend to favour LF because *nix is in more widespread use than MacOS and because the CR/LF format introduces an extra and superfluous distinction between 'binary' and 'text'. Kind regards Peter Ring -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Thornley, David Sent: 8. oktober 2001 17:07 To: Peter Ring; [EMAIL PROTECTED] Subject: RE: Checkout text files with the Unix LF (Oxa) - from command line > -----Original Message- > From: Peter Ring [mailto:[EMAIL PROTECTED]] > What's flawed is the idea that the end-of-record format in > any text file > should be inherently determined by the operating system. > Would you also like > your OS to determine what character set you should be allowed to use? > What, then, is the OS-independent way of marking an end of record? There are several that occur to me as possibilities, and which have been used by various operating systems I am or have been familiar with. All of them have advantages and disadvantages, and have been selected for various reasons. I've also worked on systems that mandated EBCDIC, ASCII with assorted variations, several CDC display codes, and Unicode. There is some grounds for standardization here, but should it be on ASCII, Unicode, ISO 8559-1, or what? The CVS idea that the program, be it client or server, uses whatever convention is suitable for its host, does quite well when people refrain from mixing that which should not be mixed. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: line ending conversions
If the problem is that you need CR/LF for files in a Windows hosted sandbox, but only LF when those files are checked out in a *nix hosted sandbox, you need the CR/LF to LF translation. The binary from the cvshome site will do it, http://ftp.cvshome.org/win32/cvs1-11.zip. There will probably be some issues with the administrative files in the sandbox if you just switch; be prepared to check out a new sandbox. If you do not need CR/LF in your Windows sandbox, or if you don't mind CR/LF in non-Windows sandboxes, you can just stick with the Cygwin port of cvs. The CRs will be preserved, as you have observed, and will appear in non-Windows sandboxes. You might not need the CRs though; NTemacs does fine without, and can be set up to default to *nix-style line endings. On Windows, I use the Cygwin ports of cvs etc. together with emacs and PCL-CVS. All mounts are binary and I'm happy as can be. Files that absolutely must have CR/LF tend to be specific for Windows applications anyway, i.e., they are of no use to applications on any other OS. Kind regards Peter Ring -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Matt McClure Sent: 9. oktober 2001 19:11 To: [EMAIL PROTECTED] Subject: Re: line ending conversions On Tue Oct 09 2001, 11:08, Roman Belenov <[EMAIL PROTECTED]> wrote: > Matt McClure <[EMAIL PROTECTED]> writes: > > > But I have also noticed some text files in my repository that have CRLF > > line endings. I think I understand how this happened, but just to > > confirm... > > > > The files were created with GNU Emacs on Windows 2000, which uses CRLF > > line endings, by default. They were committed to the repository using > > Cygwin CVS. Does Cygwin CVS assume that LF is the "form appropriate to > > the operating system on the client", and thus neglect to convert the > > line endings? > > Cygwin has concept of binary and text mounts (you can use 'mount' > command without arguments to check mount point types on your > system). In binary-mounted directories, CRLF<->LF translation is > not done for text files so that LF itself is treated as line ending. Thanks. I remounted the directory in textmode. But it still seems that files I add to the repository get added with the CRLF line endings. [mlm CVSROOT]$ pwd /cygdrive/c/home/mlm/tmp/CVSROOT [mlm CVSROOT]$ mount C:\cygwin\bin on /usr/bin type system (binmode) C:\cygwin\lib on /usr/lib type system (binmode) C:\cygwin on / type system (binmode) c: on /cygdrive/c type system (textmode) [mlm CVSROOT]$ cat > test a line with a CRLF ending [mlm CVSROOT]$ cat -A test a line with a CRLF ending^M$ [mlm CVSROOT]$ cvs add -m "" test cvs server: scheduling file `test' for addition cvs server: use 'cvs commit' to add this file permanently [mlm CVSROOT]$ cvs ci -m "" test RCS file: /usr/local/mvroot/CVSROOT/test,v done Checking in test; /usr/local/mvroot/CVSROOT/test,v <-- test initial revision: 1.1 done cvs server: Rebuilding administrative file database In the repository: [mlm@cvs CVSROOT]$ cat -A test,v head^I1.1;$ access;$ symbols;$ locks; strict;$ comment^I@# @;$ $ $ 1.1$ date^I2001.10.09.16.44.16;^Iauthor mlm;^Istate Exp;$ branches;$ next^I;$ $ $ desc$ @@$ $ $ 1.1$ log$ @*** empty log message ***$ @$ text$ @a line with a CRLF ending^M$ @$ Similarly, if I check out a file that has LF line endings in the repository, they are not translated into CRLF line endings on my machine. Any ideas? -- Matt http://www.faradic.net/~mmcclure/ "I don't believe in rivalries. I don't believe in curses. Wake up the damn Bambino, maybe I'll drill him in the (behind)." -Pedro Martinez ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Checkout text files with the Unix LF (Oxa) - from command line
cvs doesn't work, people do. Assumptions become invalid. The concept 'DOS text files' is a stale leftover from CP/M. Who cares if there's a ^Z to mark the end of a 'text' file? I don't see any hands up. There's no end to the amount of grief those pesky ^Z have caused. Anyway, most work on a Win2K box can be done with either CR/LF or LF. MacOS-style can be a problem though. I have not tried VMS-style yet ;) and probably never will. But you have got a point there. In my philosophy, I need to save a bit more information about each text file. E.g., the record format and the encoding; just a minimal amount of information about inherent properties of each text file (what makes it a text file). Unless I use and expect UTF-8 by default, there's no way to be sure that I don't munge text files with characters outside the ASCII repertoire. This isn't that much different from the question about what record format you want for each file in you sandbox. Basically, the distinction 'text' vs. 'binary' is too simplistic. You cannot infer what encoding I want, why should you be able to infer what record format I want? I'm just lucky that XML files by default are UTF-8 or else declare their encoding explicitly; this takes care of the encoding problem for me. Of course I like the abstraction of 'variable-length-record files' that cvs provides. I just don't like cvs to second-guess me when I know better. At the very least, keyword expansion and record format translation could have been different options. Kind regards, Peter Ring -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Larry Jones Sent: 9. oktober 2001 17:05 To: Peter Ring Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: Checkout text files with the Unix LF (Oxa) - from command line Peter Ring writes: > > The host may or may not be part of the use, and the > end-of-record format may or may not be important for the > host. For example, I might need to manage configuration > files for a multi-OS product. While I have both CR (MacOS), > LF (*nix), and CR/LF (CPM/MS-DOS) end-of-record files, > my editor (emacs) deals with this transparently, and the > OS that holds the sandbox have no use for 2/3 of the files. > Why should I need to check out files on a Mac just to do > something that might as well be done on Windows or Linux? You're missing the whole point on the way CVS works. You don't have files with specific line endings, you just have text files. When you check them out on DOS, they have DOS line endings and you can edit them or whatever with your DOS tools. When you check them out on Unix, they have Unix line endings and you can edit them or whatever with your Unix tools. When you check them out on Mac, they have Mac line endings and you can edit them or whatever with your Mac tools. When you go to deploy them, you check them out on the platform you're going to deploy them on and they get the correct line ending for that platform. In your philosophy, what would you do with VMS files that have a two byte binary line length followed by the bytes of the line with a NUL pad byte if required to make the number of bytes even and no line ending characters at all?!? In CVS's philosophy, it just works. -Larry Jones Fortunately, that was our plan from the start. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: choice of extension languages for a heterogeneous client/server version control system
Why not all of them? Or is this discussion about which is needed the most? I'd like a well-designed basic framework that allows several language bindings. I'd probably be most happy if the first three language bindings were Python, Scheme, and Perl. If it has to be only one language, I might be tempted to opt for Java. While Java is by itself a bit too low-level, you might also consider the fact that a Java run time engine is pervasively available, and that a lot of nice client/server code is being developed for Java. Kind regards Peter Ring
RE: Line ending confusion
Or you can check out on the Windows box using a CVS client that doesn't do EOL translation. Both WinCVS and the Cygwin port of cvs can do it. BEWARE: this will also create CVS control files with LF as EOL. Kind regards Peter Ring -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Matt Riechers Sent: 18. februar 2002 16:24 To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: Line ending confusion [EMAIL PROTECTED] wrote: > > The files were imported from a directory on the same system on the > repository, but they had CR/LF endings since they came from a DOS > system. Aha.would that mean that CVS did not line ending conversion > because a client was not being used and it assumed that the files had > the native LF-only line endings? True. > If my theory is correct, I believe I can correct it by changing the > files to Unix line endings on my Unix client and committing the files > again, no? True. -Matt ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: ANN: cvssh - secure ext-to-pserver bridge
Please share! While we are at it, are there any practical way with CVS on Linux (i.e., without ACLs) to control access on a per-file basis? We need to control access on files that cannot (i.e., CANNOT) be logically arranged into disjunct directories. So I can't rely on the usual mechanism with a number of project groups, sticky bits on directories in the repository, and direcories and files owned by project groups. Is *info scripts the way to go? It's easy enough to control commits, but I can't find an obvious way to prevent checkout or update from getting everything. Except by somehow controlling the group owner of each individual file. This is not Fort Knox, mind you, we just have to take reasonable measures that good citizens cannot compromise each other. It would be a lot easier if I could rely on ACLs supported by the filesystem. Oh, but wait; it comes to my mind that we do have servers running a filesystem with ACLs ... It's just that we don't like them exposed outside the firewall. Kind regards Peter Ring -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Douglas Finkle Sent: 22. februar 2002 04:17 To: '[EMAIL PROTECTED]' Subject: RE: ANN: cvssh - secure ext-to-pserver bridge Sorry, I've gotta jump in for a minute... Greg is right about SSH v pserver, however. Well, key management is a bit of work, and so is setting up a well hardened cvs server. The key mgmt part it's easily scripted. If I had more than a dozen users that's what I'd advise scripting the administration. I'm actually completing a setup aas described, and will be happy to share it w/ the list when I have a bit more time. I just wanted to add my 0.02 in defense of the SSH solution. For an externally facing server it's the only sane thing to do. -Dou ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: text files with Unix LF
Depends ... The way you ask the question, the answer is probably 'no'. If you use these files for Windows software development, i.e., using Visual Studio or similar, some files must have CR/LF line endings aka "DOS text format" (or was it CP/M, see http://www.cpm.z80.de/drilib.html). Selecting 'Unix LF' does not imply that some text files cannot have a CR as the last character on each line; just that they will also have it if you check them out from a Unix workstation. I.e, if you select 'Unix LF', you can have both 'Unix style' and 'DOS style' text files. But you must then - use only tools that don't care about line endings - use editors (like vim, emacs, TextPad, etc.) that take care not to trash line endings - *not* use CVS clients that translate line endings (add an extra CR) If you want to use another cvs client than WinCVS, you might need adapt to it. Some will (in practice) only work with the Unix text format, and some will only work with the DOS text format. The problem is related to the administrative files (in the CVS subdir) which must be _either_ Unix style or DOS style in a sandbox. I'm not aware of any CVS client that handles this gracefully. Kind regards, Peter Ring -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Iqbal Shaikh Sent: 19. april 2002 13:39 To: [EMAIL PROTECTED] Subject: text files with Unix LF Hi all, We have got our Cvs Server running on SunSolaris. We checkout files using WinCvs Client on Windows. The files are then edited on Windows using gvim and checked in back to the cvs server. Just want to know if while checking out files , should we have the following enabled in WinCvs Client Checkout text files with the Unix LF (0xa) What will be the problem if we checkout files without enabling the above option. Please respond. Thanks & Regards iqbal ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: merge mode for XML
One of the most widespread uses of XML is as a neutral storage and exchange format for documents. In these cases, avoiding XML or SGML would just imply going back to Word or FrameMaker (and we don't want that), or to LateX or Texi, which are similar wrt. merging. Or HTML, an application of SGML. And anyway, a lot of documentation for open source projects are being written or converted to DocBook, and will be maintained using the same revision control tools as the rest of the projects, i.e., cvs. So we are going to see questions about XML or SGML pop up more frequently. Many of the issues wrt. cvs are essentially not much different from maintaining documentation written in LateX or Texi format. Except you can't assume that authors will be using vi or emacs. A lot of different tools will be used -- that was one of the main points of using SGML or XML. It is common sense to break up a document into mini- or micro-documents with each their own lifecycle -- just as you do for programming source code. The concept of storage management is built into SGML and XML at a very low level. The customary way to do this is by declaring entitities, symbolic names for storage objects, which can then be included in other documents at appropriate places. XInclude and XLink (and for SGML, HyTime) also offer ways to include or locate parts of documents in terms of parse trees. But how about the physical storage format of each file? Authors will often be using different XML or SGML editors that will 'beautify' the XML or SGML source in different ways, introducing spurious differences and conflicts. Another source of spurious conflicts are character encoding, namespace declarations, and order of attributes; most documents can be stored in a number of different ways with no loss of information for the intended use. But a simple diff will show a lot of difference that's not there, essentially. Until proper XML repositories become as ubiquitous as cvs, we might as well find a way to live with it. The character encoding is easy to control -- SGML and XML are very explicit about it, and editors do in general handle encoding gracefully. Namespace declarations and attribute order are tricky. Things can be normalized, see Canonical XML, http://www.w3.org/TR/xml-c14n, but full canonicalization of a documents will be too much. The 'beautify' problem is even worse., i.e., how to introduce and remove whitespace in a way that makes cvs behave meaningfully. I have not yet found a simple recipe for beautifying SGML and XML. Here are some of the options: The most generic, simple and safe way to break XML or SGML into lines is unfortunately not too pretty. Keep any line breaks already present in the source and, in addition, break just _before_ the markup delimiter close character '>' on the start tag, e.g.: $ osx xml.dcl beautify.xml Beautifying XMLPapagenoBreak inside markup like this: some text.Papagena Some tools can beautify in a way more suitable for human consumption: $ xmllint --format beautify.xml Beautifying XML Papageno Break inside markup like this: some text. Papagena Keeping white space in character context while beautifying is a simple way to avoid problems with NOTATION linespecific AKA xml:space='preserve' AKA . But the reason we needed a beautfier in the first place is that editors put in different amounts of whitespace in different places. If someone out there have a nice and robust XSLT stylesheet for normalizing/beautifying XML, please publish! There are, BTW, XML diff tools. See e.g.: http://www.alphaworks.ibm.com/tech/xmldiffmerge http://www.deltaxml.com http://www.vmguys.com/vmtools http://www.logilab.org/xmldiff The first one can be used as merge tool. The other ones can produce a XML diff file that -- given a proper XML patch utility -- can update one one XML file to become the other one. There are, to the best of my knowledge, no freely available stand-alone SGML diff tools. Some editors, e.g. ArborText Epic, can do a very nice compare. kind regards, Peter Ring -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Greg A. Woods Sent: 26. april 2002 23:45 To: CVS-II Discussion Mailing List Subject: RE: merge mode for XML A better approach is to avoid XML entirely in the first place -- it's a really really horrid syntax with all kinds of goo that's usually way over-kill for the application, being SGML based and all that ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: merge mode for XML
I tried not to argue about the virtues of SGML/XML -- the fact is that it there and any non-propriatary alternatives have similar properties wrt. meaningful diffs (and thus merge). My IDE for editing XML and SGML files is usually emacs+psgml. I like the idea of extending PCL-CVS to invoke another diff tool (but I'll probably not get around to exploring the idea). SGML and XML files are really just serialized representations of parse trees, infosets, and an infoset can be serialized in many equivalent ways. So diff'ing XML and SGML alike need a validating parser, i.e. one that uses a schema such as a DTD. There's a class of simple XML documents that live and die without getting near either a DTD or revision control. Without a schema and accompanying documentation, there's no way to tell the semantics of the XML document, and not much point in version management. kind regards Peter Ring -Original Message- From: Greg A. Woods [mailto:[EMAIL PROTECTED]] Sent: 30. april 2002 19:09 To: Peter Ring Cc: CVS-II Discussion Mailing List Subject: RE: merge mode for XML [ On Monday, April 29, 2002 at 08:31:24 (+0200), Peter Ring wrote: ] > Subject: RE: merge mode for XML > I sort of agree with the logic of the arguments for SGML and its derrivatives, but I find the rhetoric about it being "the only choice because it's the best there is" (something I've heard whined about for nearly two decades now) to be nor more than self-serving, at best. As for source code beautification issues w.r.t. XML, well those are no different than when dealing with any kind of source code primarily written and edited with an integrated IDE. For instance PCL-CVS, the emacs front-end to CVS, allows one to re-do merges with ediff. I don't know if ediff could be extended to use external diff tools (and also perhaps alternate merge tools), or not, but that may be the best way for users with immediate needs to proceed. (I.e. even if you're not an emacs user, treat emacs as an application framework and use emacs+PCL-CVS+ediff as a stand-alone CVS interface.) > There are, to the best of my knowledge, no freely available stand-alone > SGML diff tools. Some editors, e.g. ArborText Epic, can do a very nice > compare. Would not a full stand-alone SGML diff tool be required to understand the DTD in order to do a proper job of knowing just how different tagged elements relate to each other in order to know whether or not they have to be included in any delta or merge? -- Greg A. Woods +1 416 218-0098; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Planix, Inc. <[EMAIL PROTECTED]>; VE3TCP; Secrets of the Weird <[EMAIL PROTECTED]> ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: merge mode for XML
I might just sit back and watch the show, but I like to be part of the
fun ;)
DTDs are certainly not enough in a lot of situations, and XML Schemas,
RELAX NG, or what-have-you won't ever obliviate the need for documentation
and project management.
But sometimes, well-formed XML is worthy of version management even
when no-one bothers about a schema. For example, you might need to save
some of those short-lived XML-formatted messages for a regression test.
Also, there is now a trend towards a more Unix-like 'tool-set' approach,
in which different parts of a chain of processes are responsible for
different tasks. While it might be valuable early in a proces to validate
an XML instance, it might be a waste of resources later in the proces.
There's also another interesting trend: HyTime is slowly being re-invented
in XML incarnation. Which to me is proof-of-concept: you can dream up
another syntax (and a full-blown SGML parser might even be able to parse
it, given a suitable SGML declaration), but in the end, it doesn't make
much of a difference whether you write something or
(concept something) or \concept{something} or whatever; the fundamental
issue is the same: You are not really supposed to look at the markup
except as an expression of structure.
Which was what started this thread: how to diff and merge in a meaningful
way, i.e. in a way that knows that isn't
different from in a way that most XML
applications should care about. You can come this far with just well-formed
XML. When it comes to whitespace in character context, things get really
interesting. XML in essence leaves it up to the application what to do with
whitespace, so you have to know the application in order to decide whether
a whitespace difference matter. A DTD or schema helps a lot because you
can then ignore whitespace in element context.
BTW, I stumbled over yet another XML diff, this one written by
Norman Walsh:
http://nwalsh.com/java/diffmk/
and a small feature about whitespace and prettyprinting XML:
http://www.xml.com/pub/a/2002/01/02/whitespace.html
Kind regards
Peter Ring
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
Gary Bisaga
Sent: 1. maj 2002 17:12
To: CVS-II Discussion Mailing List
Subject: RE: merge mode for XML
Sorry, this strikes me as just a little bit extreme. I agree that you ought
to write DTDs or schemas (just yesterday I had to make one of our developers
do so, and our own internal XML infrastructure requires them). But to call
documents without DTDs/schemas "not XML" and unworthy of configuration
management is certainly not supported by the XML spec or common usage. For
one thing, as I'm sure you know, the XML spec does not seem to deprecate
well-formed XML documents. When I was in the W3 XML working group (1999)
there was certainly a group of us (not everybody) who believed that
well-formed documents had a place in the world.
And if we take this tack, what about constructs not declarable with DTDs?
XML Schemas will certainly improve this, but many people are not using them
yet. Are DTDs with "ANY" declarations also not XML, since they really don't
describe the semantics of the document? Since DTDs can't describe data types
or other restrictions (such as field length), is any DTD'ed document "not
XML"?
DTDs and schemas are good and should be used wherever possible. But there
are realities of life.
<>< gary
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
Greg A. Woods
Sent: Wednesday, May 01, 2002 1:56 AM
To: Peter Ring
Cc: CVS-II Discussion Mailing List
Subject: RE: merge mode for XML
> There's a class of simple XML documents that live and
> die without getting near either a DTD or revision control.
> Without a schema and accompanying documentation, there's no
> way to tell the semantics of the XML document, and not much
> point in version management.
Amen. I couldn't agree more!
Those who dare call such things "XML" are sadly mistaken.
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
RE: How to keep unix eoln in repository
Your repository files do have unix-style eol ... it's just that there's a CR at the end of each line ;) This will happen un-intentionally if you use a cvs client with no eol conversion (e.g., the Cygwin port) and stupid editors that munge eol. If your Windows-hosted developers really need DOS text file format, they should be using a cvs client that does eol conversion. kind regards Peter Ring -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of juhas Sent: 14. maj 2002 12:56 To: [EMAIL PROTECTED] Subject: How to keep unix eoln in repository Hi, is there any simple way how to keep unix ends of lines (eolns) in the repository? Despite the fact that our compile & link platform is UNIX, some of our developers edit source files on windows. And they always forget to change win eolns to unix eolns... Is it possible to set/write a trigger which would convert eolns in text files during cvs checkin? If not, is there another chance? Thanks a lot, Dusan Juhas ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: merge mode for XML
A paper that will interest you:
(preliminary version)
http://citeseer.nj.nec.com/cache/papers/cs/15339/http:zSzzSzwww.cs.arizona.e
duzSzpeoplezSztodszSzacceptedzSz2000zSzParsonsEmancipating.pdf/parsons00eman
cipating.pdf
(published)
http://portal.acm.org/citation.cfm?id=357778&coll=portal&dl=ACM&CFID=2131136
&CFTOKEN=70981949
Abstract:
"Database design commonly assumes, explicitly or implicitly, that instances
must belong to
classes. This can be termed the assumption of inherent classification. We
argue that the extent and complexity of problems in schema integration,
schema evolution, and interoperability are, to a large extent, consequences
of inherent classification. Furthermore, we make the case that the
assumption of inherent classification violates philosophical and cognitive
guidelines on classification and is, therefore, inappropriate in view of the
role of data modeling in representing knowledge about application domains."
Also, a search for 'semantic interoperability' should return some
interesting hits.
To tell the difference between two (or three) sequences of bytes is not too
difficult; comparing two sequences A and B to determine their longest common
subsequence (LCS) or the edit distance between them has been much studied.
GNU diff is based on an algorithm published by Eugene W. Myers in 1986.
To tell the difference (distance) between two semantic structures is
difficult in a very fundamental way.
Kind regards
Peter Ring
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
Glew, Andy
Sent: 13. maj 2002 19:32
To: [EMAIL PROTECTED]; Glew, Andy
Cc: Gary Bisaga
Subject: RE: merge mode for XML
> > Motivation: schema changes in most existing relational databases are
> > onerous.
>
> For very good reason.
And what is that reason?
OK, I admit that some RDBMS applications in production
need stability - just like some systems software applications
(the kind Greg seems to work on, the kind I used to
work on) value stability above all else, and actively
want to make it hard to change things.
However, there are other application domains
- in programming, the domains attacked by agile
methodologies like XP (eXtreme Programming).
{Donning asbestos underwear, expecting Greg
to flame.}
An application area that I frequently work in nowadays
is experimental databases - databases for experimental data.
I want to archive all of my experimental data in a form that
allows me to do arbitrary SQL-like queries over it.
Problem is, as I continue my research, the format of
my records is continually changing. For example, a few years
ago I might have recorded CPU MHz and Cache Size as
configuration parameters - now I have to record at least
3 different cache sizes, as well as multiple clock domain
frequencies. Not to mention that the observations that
I record are constantly changing.
Rather than continually reformatting my database,
adding new fields which are "Unknown" or "Null" on old data,
I find it easier to add records containing fields that were not
known earlier.
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Line Breaks
Another potential source of confusion could be DOS-style text files checked in as binary files (from any CVS client on any OS). BTW, Windows applications are often more forgiving about end-of-line style than Unix applications. I've been living and working 'incorrectly' for some years now. Those few text files that absolutely must be DOS-style are anyway of little use in a sandbox on a Unix workstation. So all my text files are Unix-style, and a few of them have a CR at the end of each line. kind regards Peter Ring -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Larry Jones Sent: 1. januar 1601 01:00 To: Willi Richert Cc: [EMAIL PROTECTED] Subject: Re: Line Breaks Willi Richert writes: > > the CVS doc says that it handles the different > line breaks of windows and unix platforms by itself. > I.e. if I check out a file under unix which was > checked in under windows I get the unix line breaks. > > Is that true? In my CVS it does not work. Do I have to > put on certain switches to get that behaviour? Yes, it's true, provided your CVS clients follow the rules. The standard CVS release works correctly. WinCVS and the cygwin version of CVS can both be configured to work incorrectly, using Unix line endings on Windows. -Larry Jones All girls should be shipped to Pluto--that's what I say. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: [Fwd: CVS, Cygwin, IDE and Emacs]
Which Windows IDE is it? Emacsen (gnu or X, any platform) are pretty agnostic (ie: accommodating) wrt. line-ends. A shame some people never get to like emacs; there's also this very nice VC mode specifically for CVS, pcl-cvs, which is my primary GUI interface to CVS. On Windows, I use also the command line (cygwin) and occasionally WinCVS, TortoiseCVS, tkcvs, or jCVS. WinCVS can be told to behave globally (per installation) to treat 'text' Unix-style or DOS-style. For me, this setting depends on which other CVS clients must be used in sandboxes on that machine, since CVS clients are rather unforgiving about the administrative files (in CVS subdirs in the sandbox). TortoiseCVS is becomming popular, I guess mainly because it's easy to get going for users that loathe command lines, and it's easy on the CVS admin wrt. support because it's 'just there' where people need it (it works as a shell extension to Explorer), and comes with a ssh client integrated. But text files (the administrative files, actually) must be DOS style for TortoiseCVS to work. Kind regards Peter Ring -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Mike Ayers Sent: 12. juni 2002 05:08 To: Eric Siegerman Cc: [EMAIL PROTECTED] Subject: Re: [Fwd: CVS, Cygwin, IDE and Emacs] Eric Siegerman wrote: > My wording was imprecise. I meant "get CVS to start taking them > out, as it's @#(! well supposed to do". There's no way to tell > CVS to do this; it's supposed to just happen. Hmmm - if it's "supposed to just happen", then that may explain it. Specifically, I am checking in DOS format files from a Unix format environment, so I suspect that my (Unix format compiled) CVS client just assumes that I have Unix format files and does no conversion, as it would not need to, ordinarily. Your discussion of CVS internals in this regard support this theory, if I read it correctly. Then the answer would be to use WinCVS after all, which would canonicalize the line ends for me, yes? /|/|ike ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
