Re: (no subject)
On Wed, Apr 18, 2001 at 01:14:21PM -0700, mm rao wrote: Can you please include me in this group please. Right now I am not ablt to post the messages ti this group. You have to do that by yourself: List-Help: mailto:[EMAIL PROTECTED]?subject=help List-Post: mailto:[EMAIL PROTECTED] List-Subscribe: http://mail.gnu.org/mailman/listinfo/info-cvs, mailto:[EMAIL PROTECTED]?subject=subscribe List-Id: Announcements and discussions for the CVS version control system info-cvs.gnu.org List-Unsubscribe: http://mail.gnu.org/mailman/listinfo/info-cvs, mailto:[EMAIL PROTECTED]?subject=unsubscribe List-Archive: http://mail.gnu.org/pipermail/info-cvs/ HTH Frank ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
NEED HELP ON WINCVS1.2
Hello, Does anyone know of a user manual or guide for WinCVS 1.2?. The one that is available on the www.wincvs.org website is for version 1.1. I am a total novice as far as CVS and WinCVS is concerned, and I have been asked to do some research on how to use WinCVS 1.2. Could you please tell me how one should go about learning WinCVS 1.2 client for working on the CVS server running on Linux Redhat 6.1.? I would be thankful if someone gives me some pointers, tips, ideas, etc. Thanks, Mahesh ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Xdelta and CVS
Hello, We are using CVS, for several projects, with great pleasure. We now have the need to store and track revisions of large binary files (audio analysis data). Because we are already familiar with CVS, and use it with clients on various platforms, we would like to use CVS for this data as well. Obviously, storing all revisions entirely will not be very efficient. The data is pretty straigthforward, and the differences between versions could be extracted very well with Xdelta. So Xdelta integration in CVS seems to be the solution. The webpage http://www.cvshome.org/cyclic/gallery/xdelta-dev.html looks very optimistic, so I was surprised to find out that I could hardly find any other references to Xdelta and CVS, let alone a patch or (starting) implementation. My questions are: - is the forementioned webpage too optimistic? - what do people on this list think about the three mentioned methods? which would be the way to go? - is / has anybody been working on this already? - are there other ways that might be better/easier (like modifying diff) I am well aware of the fact, that CVS has not been designed to deal with large binary files, and that some people would consider it undesirable to add such functionality. I think it is worth the try though. As this is an important issue for our project, I can spend some time on this. Kind regards, and looking forward to your reactions, Maarten de Boer ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Terminology
Simple question really "So what is the repository?" Now I thought I knew the answer to this: (chapter 2 Version Management with CVS 1.10.6): "...so the repository :local:/usr/local/cvsroot means ..." "The repository is split into two parts $CVSROOT/CVSROOT contains administrative files for cvs the other directories contain the actual user-defined modules" So my reading of this would be that the REPOSITORY means: /usr/local/cvsroot Now I've been trying to use 'commitinfo' to match things like: .*\.properties dosomething.sh .*\.javavalidate.sh And it did not work. When all else fails read the source (if that fails read the manual ;-) This contains (repos.c) /* * Return a pointer to the repository name relative to CVSROOT from a * possibly fully qualified repository */ Ahh! so that's why I can't match the regular expressions it's comparing the 'repository name' not the full pathname of the file! (dumb mistake on my part) But hang on isn't the 'repository name' /usr/local/cvsroot that's not going to be any use? Tests reveal that I can match things like: ^config dosomething.sh ^javasrcvalidate.sh Where these are inside the 'repository' (as defined above): /usr/local/cvsroot/config /usr/local/cvsroot/javasrc So this seems to define (by it's actions) repository to mean: 'The various sub-directories under $CVSROOT' At this point I reread the comment at the start of commitinfo: # The first entry on a line is a regular expression which is tested # against the directory that the change is being committed to, relative # to the $CVSROOT. For the first match that is found, then the remainder # of the line is the name of the filter to run. # # If the repository name does not match any of the regular expressions in this # file, the "DEFAULT" line is used, if it is specified. ... humm .. "the directory that the change is being committed to" OK that's just what it does ... "If the repository name does not match..." so the 'directory name' is AKA 'repository name'? Then again "cvs init" Creates a CVS repository if it does not exist... OK I give up at this point "what is a repository?" -- Only kings, presidents, editors, and people with tapeworms have the right to use the editorial "we". -- Mark Twain Graeme *** The contents of, and the information contained in this email and any files transmitted with it are confidential and legally privileged, and are sent for the personal attention of the addressee(s). If you are not the intended addressee, any use, disclosure or copying of this document is unauthorised. Thank you NTL *** ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
directory addition
Thank you sir. now i am understand ... now.. last question if your dont mind.. if my friend added a directory(not empty directory) to CVS server.. how can i get the new directory to my local hard disk ?? should i check out the whole module everytime a new directory added ?? or can i just check out to the specific new directory ??? thx, a Java Addicted --- Runbox Mail Manager - www.runbox.com Free online email application ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
How can one mark a file as binary after importing it
Thank you very much Best regards Paulo Bras _ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
A problem with CVS commands that modify the repository
Hi, We've been working on our CVS repository for a while, and everything used to be ok. Starting today, we are getting messages like the following: cvs [commit aborted]: could not open lock file `some-path-in-the-repository/some-file,' : File exists We got similar messages when trying to tag the repository. Looking into the repository I found out two files for some-file: * "some-file,v" - this is the usual (RCS) file in the repository, and * ",some-file," - this is the new version of the (RCS) file in the repository, which should replace "some-file,v". Looking at the permissions in that repository directory, I noticed that all ",v" files were read-only. Changing them to writable (using 'chmod +w *,v') solved the problem. My questions: 1. Should the files in the repository be writable? 2. How can it be that we used to commit and tag without a problem, and suddenly we are unable to do so (in the same repository directories)? Thanks, Shlomo ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: WinCVS and MacCVS Logins
Yes, using TCP compression, set to 5. No load on the server, haven't put it into production use yet and connection is over LAN at 100 Mbits. It is really strange. It seems to be erratic. For instance, this morning I logged in and it took a minute and a half. I restarted the Linux server and login was instantaneous. I moved to another machine with same version of WinCVS (version 1.2). Login took almost 2 minutes, restarted that machine, login took 10 seconds. Usually when logins take longer, so do other commands. Sometimes logins and other commands are faster after the first slow login. CVS version: 1.10.7-7 Linux: Debian 2.2 r2 -Original Message- From: David Fuller [mailto:[EMAIL PROTECTED]] Sent: Thursday, April 19, 2001 8:31 AM To: Brad Pfautsch Cc: [EMAIL PROTECTED] Subject: Re: WinCVS and MacCVS Logins My first two ideas: 1) slow connection/heavy load server? 2) Are you using TCP compression? -- David F. Brad Pfautsch wrote: Logins take upwards of two minutes to receive the "*CVS exited normally with code 0*" message. Any idea's why/how to fix? ___ 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: WinCVS and MacCVS Logins
Using TCP compression is a fine art. Finding the right setting based on network traffic can take quite sometime. Try other settings, including turning it off. The time cost in compressing the traffic may out-weigh the time savings in network traffic. Also, once you are logged in you stay logged in until you specifically say logout. CVS keeps a '.cvspass' file on the local machine which keeps all your login info. Logging in a second time will just check against this file. If your info matches it won't go out to the server again. -- David F. Brad Pfautsch wrote: Yes, using TCP compression, set to 5. No load on the server, haven't put it into production use yet and connection is over LAN at 100 Mbits. It is really strange. It seems to be erratic. For instance, this morning I logged in and it took a minute and a half. I restarted the Linux server and login was instantaneous. I moved to another machine with same version of WinCVS (version 1.2). Login took almost 2 minutes, restarted that machine, login took 10 seconds. Usually when logins take longer, so do other commands. Sometimes logins and other commands are faster after the first slow login. CVS version: 1.10.7-7 Linux: Debian 2.2 r2 -Original Message- From: David Fuller [mailto:[EMAIL PROTECTED]] Sent: Thursday, April 19, 2001 8:31 AM To: Brad Pfautsch Cc: [EMAIL PROTECTED] Subject: Re: WinCVS and MacCVS Logins My first two ideas: 1) slow connection/heavy load server? 2) Are you using TCP compression? -- David F. Brad Pfautsch wrote: Logins take upwards of two minutes to receive the "*CVS exited normally with code 0*" message. Any idea's why/how to fix? ___ 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: Xdelta and CVS
Maarten de Boer wrote: Hello, Obviously, storing all revisions entirely will not be very efficient. The data is pretty straigthforward, and the differences between versions could be extracted very well with Xdelta. So Xdelta integration in CVS seems to be the solution. Could be. The webpage http://www.cvshome.org/cyclic/gallery/xdelta-dev.html looks very optimistic, so I was surprised to find out that I could hardly find any other references to Xdelta and CVS, let alone a patch or (starting) implementation. The page you have mentioned is a set of suggestions for people who might have the interest, ability, and time to work on integration of CVS and Xdelta, not a description of any work going on. In order for this implementation to appear, somebody's going to have to do it, and from the tone of the page it's going to be some outside volunteer. If you have the interest, ability, and time, you could do it. (I'm not sure I have the interest, and I know very well I don't have the time.) Note that the page listed three projects of increasing order of size, and using Xdelta to reduce repository size would apparently fall under the third project. I am well aware of the fact, that CVS has not been designed to deal with large binary files, and that some people would consider it undesirable to add such functionality. I think it is worth the try though. As this is an important issue for our project, I can spend some time on this. CVS uses diff in different ways. One is to keep the revision history files relatively small, and one is to merge changes. I looked at the web pages to see if there was some Xdelta correspondence to diff3, and apparently I'd have to go to Sourceforge, which is down at the moment. If Xdelta can create binary diffs and apply them to other files, in order to merge changes, and these merges result in something useful enough times to make the capability worth having, then it would seem to me to be an extension of the CVS philosophy. It would still mean changing the RCS format, and that may be a problem. If Xdelta provides its own archive file format, it is unlikely to be compatible with RCS, and it would be necessary (at the very least) to have some means of telling CVS what sort of file it was to access. Ideally, it would make it possible to version the file type, which is not currently possible. -- David H. Thornley Software Engineer at CES International, Inc.: [EMAIL PROTECTED] or (763)-694-2556 at home: (612)-623-0552 or [EMAIL PROTECTED] or http://www.visi.com/~thornley/david/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
rdiff without -c option
Hi all , As a new user to CVS , I do not know how to get rdiff with "-bBw " option instead of "-c" . How can I get this ? . Thanks Regards, Kudiyarasan ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Terminology
[EMAIL PROTECTED] writes: Simple question really "So what is the repository?" It all depends on context. In general, "the repository" is a collection of revision histories of files. The term is also used (imprecisely) to mean the location of that collection, the name of that location, or a particular subset of any of the above. "...so the repository :local:/usr/local/cvsroot means ..." That should more properly be: "so the repository *specification* ..." "The repository is split into two parts $CVSROOT/CVSROOT contains administrative files for cvs the other directories contain the actual user-defined modules" So my reading of this would be that the REPOSITORY means: /usr/local/cvsroot That's the location of the repository in this example. Now I've been trying to use 'commitinfo' to match things like: .*\.properties dosomething.sh .*\.javavalidate.sh And it did not work. When all else fails read the source (if that fails read the manual ;-) Reading the manual first would have been a lot better option -- it clearly states that it's the current directory name within the repository that's matched against the regular expressions. This contains (repos.c) /* * Return a pointer to the repository name relative to CVSROOT from a * possibly fully qualified repository */ Ahh! so that's why I can't match the regular expressions it's comparing the 'repository name' not the full pathname of the file! (dumb mistake on my part) But hang on isn't the 'repository name' /usr/local/cvsroot No. Comments in the code are not user documentation and thus are likely to use jargon and other shorthand. In this case, "repository name" is being used to mean "name of a particular directory in the repository". Tests reveal that I can match things like: ^config dosomething.sh ^javasrcvalidate.sh Where these are inside the 'repository' (as defined above): /usr/local/cvsroot/config /usr/local/cvsroot/javasrc So this seems to define (by it's actions) repository to mean: 'The various sub-directories under $CVSROOT' Which you would have known had you read the manual. At this point I reread the comment at the start of commitinfo: # The first entry on a line is a regular expression which is tested # against the directory that the change is being committed to, relative # to the $CVSROOT. For the first match that is found, then the remainder # of the line is the name of the filter to run. # # If the repository name does not match any of the regular expressions in this # file, the "DEFAULT" line is used, if it is specified. ... humm .. "the directory that the change is being committed to" OK that's just what it does ... "If the repository name does not match..." so the 'directory name' is AKA 'repository name'? Once again, that's a jargony or shorthand usage of "repository name" which should have been clear from the context created by the first paragraph. -Larry Jones Your gender would be a lot more tolerable if it wasn't so darn cynical! -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: A problem with CVS commands that modify the repository
Reinstein, Shlomo writes: My questions: 1. Should the files in the repository be writable? No. 2. How can it be that we used to commit and tag without a problem, and suddenly we are unable to do so (in the same repository directories)? Someone just adjusted the permissions on your repository or your repository is on some kind of shared file system and someone just adjusted it's security settings. -Larry Jones Even though we're both talking english, we're not speaking the same language. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Is the pserver running without starting by inetd?
Dear People, does anyone of you know, whether the pserver can start up without the inet deamon? I have an UNIX account to an internet server, but no access to the configuration files and my provider don't want setup the neccessary configurations. (security doubt) So, is it possible to start a cvs pserver process manually from the shell? Thank's and best regards, Dominik Kalb ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
$Name $ and branches
I'm a little confused by an aspect of CVS: If I have a file that contains the $Name: $ keyword, and that file is checked out under a normal, non-branch tag FOO, the keyword will be expanded as $Name: FOO$. However, if the tag is a branch, the keyword won't be expanded. Is there some logic behind this behavior? For some of what I am doing, I'd really like to have the $Name$ be replaced with the branch tag. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: general organization of CVS modules
Fran Fabrizio wrote: Hello all, I have a couple of general questions. 1. Say I have a web project that consists of some CGI scripts and some static pages. The CGI scripts are in /usr/local/apache/cgi-bin/, the static pages are in /usr/local/apache/htdocs. I want to make it all one module since logically they are related, but it seems unwieldy. The shared parent directory is /usr/local/apache, but clearly I would not want the project to be based there, as there are also several unrelated directories underneath that directory (conf, logs, etc...). How does one organize this neatly? Is there a way to say 'cvs co my-project' or 'cvs update my-project' while in /usr/local/apache and have it just checkout/update those two directories? cd /usr/local/apache cvs co -d cgi-bin my-project/cgi-bin cvs up -d cgi-bin Sorry, I can't help with #2. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Passwd file
I've set up CVS for remote repository, and I can login using a system user account (i.e. my own) but I want to use separate passwords and have CVS run as a common user so I can tighten permissions (more to prevent accidental deletation). I created a $CVSROOT/CVSROOT/passwd file with just dummy::cvs in it (cvs is a system account), but I can login as dummy with no password - i just get the failed message. I can still login using my own (system) account (ultimately I will turn off the system auth. ability). Do I have to do anything special to the passwd file to get it to be used? From what I can tell its the latest version (came with red hat linux 6.2) Cheers Nigel ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: applying astyle on commit
From cvs help: The commitinfo file defines programs to execute whenever cvs commit is about to execute. These programs are used for pre-commit checking to verify that the modified, added and removed files are really ready to be committed. This could be used, for instance, to verify that the changed files conform to to your site's standards for coding practice. -- David F. Maarten de Boer wrote: Hello, We use some strict rules on code layout, but of course people sometimes make mistakes. Luckily, astyle does a great job in layouting automatically. So I would like to apply astyle on all the code that is commited to the repository, so the code inside the repository is always correct. People would only have to do an update after to commit to get the formatted version. So my question is: how can I do this? Doing it client side is not really an option, because we use different platforms, and besides, doing it server-side assures correct usage of astyle. Kind regards, Maarten ___ 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: commit -m Line One\rLineTwo
Or ksh...
$ cvs commit -m"$(echo "Line One\nLineTwo")" file
Andy
-Original Message-
From: Gianni Mariani [mailto:[EMAIL PROTECTED]]
Sent: 13 April 2001 15:26
To: James A. N. Stauffer; CVS
Subject: RE: commit -m "Line One\rLineTwo"
It seems this depends more on your shell than it does cvs.
Using tcsh you need to do so:
cvs commit -m "foo\
bar"
tcsh requires an escape ('\') for each newline
withing a quote.
On bash you do:
cvs commit -m "foo
bar"
bash (GNU bash, version 2.04.11(1)-release) keeps
on reading input until it's matching end '"'
G
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
James A. N. Stauffer
Sent: Friday, April 13, 2001 7:00 AM
To: CVS
Subject: commit -m "Line One\rLineTwo"
How do I run commit and give a two line message?
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
NOTICE AND DISCLAIMER:
This email (including attachments) is confidential. If you have received
this email in error please notify the sender immediately and delete this
email from your system without copying or disseminating it or placing any
reliance upon its contents. We cannot accept liability for any breaches of
confidence arising through use of email. Any opinions expressed in this
email (including attachments) are those of the author and do not necessarily
reflect our opinions. We will not accept responsibility for any commitments
made by our employees outside the scope of our business. We do not warrant
the accuracy or completeness of such information.
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Passwd file
David Fuller writes: You'll have to turn off system auth for the passwd file to start working right. Wrong -- CVS always looks at the repository passwd file. If SystemAuth is set to true, the system passwd file is only consulted if the repository password file doesn't exist or it doesn't contain an entry for the user. You'll also probably want to put something in the password area. Even a blank password has a crypted value. As of CVS 1.11, CVS interprets an empty password field to mean that any password is acceptable (this is typically used only for anonymous, read-only accounts). If you're not running 1.11, then the empty password field will never match, which may be the problem. Try doing ``cvs version'' to find out what version(s) you have -- if that command isn't valid, then you definitely don't have 1.11 (you can get it from www.cvshome.org). -Larry Jones I've got to start listening to those quiet, nagging doubts. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Is the pserver running without starting by inetd?
Dominik Kalb writes: does anyone of you know, whether the pserver can start up without the inet deamon? It needs something to manage the connection details for it. You can run a private copy of inetd without being root as long as you use your own configuration file instead of using the system configuration file. You can also use an inetd replacement such as Dan Bernstein's tcpserver (see http://cr.yp.to/ucspi-tcp.html for info on tcpserver and links to some other similar programs). -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
Re: removing a directory
On Wed, Apr 18, 2001 at 09:55:17AM +, JavaSoft wrote: How can i delete a drectory (including the contents) from CVS on linux server using wincvs without deleting the directory in my local hard disk ? so it's just delete in the linux not in my local hardisk so i can to re-ADDing the direcotry to the linux again. You can't. You'll have to: - make a backup of the sandbox on your local machine - delete the directory locally - "cvs rm" it - commit - restore from the backup -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. - RFC 1925 (quoting an unnamed source) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Val-tags file
Rui Cordeiro writes: Does anyone may explain me which is the val-tags file syntax ? Each line consists of a valid tag name followed by a space and the letter "y". This file is used by the CVS in which situations? It is only used to store the tags and branch names that are in use? Branch names *are* tags. CVS uses it to validate that a user-entered tag is valid: If the tag appears in the val-tags file, it is assumed to be valid. If the tag does not appear in the val-tags file, then CVS goes looking through all of the files in the repository that are specified in the command. If one of them contains the tag, it is valid and is added to the val-tags file. If it is not found, the user is given an error message. -Larry Jones You know how Einstein got bad grades as a kid? Well MINE are even WORSE! -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: rdiff without -c option
Kudiyarasan writes: As a new user to CVS , I do not know how to get rdiff with "-bBw " option instead of "-c" . How can I get this ? . You have to use diff instead of rdiff. -Larry Jones These pictures will remind us of more than we want to remember. -- Calvin's Mom ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Xdelta and CVS
= Original Message From "David H. Thornley" [EMAIL PROTECTED] = It would still mean changing the RCS format, and that may be a problem. If Xdelta provides its own archive file format, it is unlikely to be compatible with RCS, and it would be necessary (at the very least) to have some means of telling CVS what sort of file it was to access. Ideally, it would make it possible to version the file type, which is not currently possible. One project I'm keeping my eye on is at http://subversion.tigris.org/; I believe they have incorporated support for binary files in a more-flexible way than has CVS. Cheers, Laird -- [EMAIL PROTECTED] http://www.amherst.edu/~ljnelson/ Good, cheap, fast: pick two. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Xdelta and CVS
[ On Thursday, April 19, 2001 at 11:16:31 (+0200), Maarten de Boer wrote: ] Subject: Xdelta and CVS We are using CVS, for several projects, with great pleasure. We now have the need to store and track revisions of large binary files (audio analysis data). Because we are already familiar with CVS, and use it with clients on various platforms, we would like to use CVS for this data as well. That would be a "not-very-smart" thing to do. CVS does not in any way meet your requirements for that kind of data. You appear to be suffering from the "All I have is a hammer, so every fastener must be a nail" syndrome, and even though you've begun to realize that there are these screw-like things in your tool-belt pouch you haven't yet figured out that you'll create nothing but splinters and bent screws by trying to bash them into your project. Obviously, storing all revisions entirely will not be very efficient. The data is pretty straigthforward, and the differences between versions could be extracted very well with Xdelta. So Xdelta integration in CVS seems to be the solution. Sure, but if you do that then you'll be off using an incompatible branch variant of CVS that has no hope of ever being integrated back into the main variant of CVS that uses standard RCS files for storage. Note also that you cannot change what is considered to be "the main variant of CVS" unless you convince the majority of CVS users to give up on RCS as the sole repository file format either. The webpage http://www.cvshome.org/cyclic/gallery/xdelta-dev.html looks very optimistic, so I was surprised to find out that I could hardly find any other references to Xdelta and CVS, let alone a patch or (starting) implementation. The first so-called idea on that page is bogus. It provides no real benefit in the direction you're hoping to go. What its author was even thinking of is unclear. The second idea is just plain wrong in claiming that it would not change the CVS repository format since it would, by definition. RCS uses "diff" and only "diff" for delta storage. What it really proposes is to change RCS. As for the third idea, well it's less half-baked than its author even tries to make it sound Overall what that web page fails to note is that introduction of such a drastic change to the repository data structures would make any such repository incompatible with any normal RCS-only version of CVS, and indeed incompatible with RCS itself. BTW, that web page also fails to give full justice to the size of the project. If you're really serious about something along these lines you'd be INFINITELY better off if you simply started a new design for a versioning tool and wrote it right from scratch. In any case unless somone creates such an implementation, makes it freely available, *and* convinces a significant portion of the CVS community to use it, there's little chance of any success in this direction. Of course there are ways to enhance one's chances of success by also writing lots of tools to help convert repositories in *BOTH* directions, but there'd still be no guarantees. Of course you'll get all of my moral support if you do venture out to design a new versioning tool that meets your requirements! :-) - are there other ways that might be better/easier (like modifying diff) You could jsut switch to using PRCS, at least for the audio data. It uses xdelta internally by default already I am well aware of the fact, that CVS has not been designed to deal with large binary files, and that some people would consider it undesirable to add such functionality. I think it is worth the try though. As this is an important issue for our project, I can spend some time on this. You've obviously been blinded by your situation. What you're proposing is somthing new and entirely different which may have a command-line like that of CVS, but which would otherwise not be CVS. Calling it "CVS" would be wrong. -- Greg A. Woods +1 416 218-0098 VE3TCP [EMAIL PROTECTED] [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: directory addition
[ On Thursday, April 19, 2001 at 10:06:30 (GMT), JavaSoft wrote: ] Subject: directory addition now.. last question if your dont mind.. if my friend added a directory(not empty directory) to CVS server.. how can i get the new directory to my local hard disk ?? should i check out the whole module everytime a new directory added ?? or can i just check out to the specific new directory ??? Just make sure you have at least these lines in your ~/.cvsrc file: checkout-P update -d -P and any new directories will appear automatically with every "cvs update" -- Greg A. Woods +1 416 218-0098 VE3TCP [EMAIL PROTECTED] [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Xdelta and CVS
[ On Thursday, April 19, 2001 at 09:23:34 (-0500), David H. Thornley wrote: ] Subject: Re: Xdelta and CVS CVS uses diff in different ways. One is to keep the revision history files relatively small, and one is to merge changes. I looked at the web pages to see if there was some Xdelta correspondence to diff3, and apparently I'd have to go to Sourceforge, which is down at the moment. If Xdelta can create binary diffs and apply them to other files, in order to merge changes, and these merges result in something useful enough times to make the capability worth having, then it would seem to me to be an extension of the CVS philosophy. As I understand it the more recent versions of Xdelta do indeed have the ability to do three-way merges. Some of the research also seems to indicate that Xdelta is just as successful at computing deltas of, and merging, text files as it is with the traditional text diff algorithm. However one of the problems is in how to represent conflicts in the resulting merges in a way that's easy to resolve with a text editor (at least in the case of text files. I've not actually seen this happen so I'm not sure how the Xdelta tools manage at the moment. It would seem that a visual merge tool would be required to do the edits in all cases (which of course opens up the possibility of having data structure dependent merging tools). Certianly the Xdelta algorithm has been used to great success in rsync. Whether it makes a mark in any new versioning tools beyond PRCS is yet to be seen -- Greg A. Woods +1 416 218-0098 VE3TCP [EMAIL PROTECTED] [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: directory addition
On Thu, Apr 19, 2001 at 03:29:26PM +0200, Matthias Kranz wrote: Usage: cvs update [-APdflRp] [-k kopt] [-r rev|-D date] [-j rev] [-I ign] [-W spec] [files...] -d Build directories, like checkout does. Which is pretty unclear. You have to already know what it means to understand it. How about this, which is an abbreviated version of what's in the manual: -d Create directories that are missing from working directory. -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. - RFC 1925 (quoting an unnamed source) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
UCE Complaint (Re: Xdelta and CVS)
You have sent the attached unsolicited e-mail to my e-mail account. I do not wish to receive such messages in the future. Please remove my name from your lists immediately. --- This message was intercepted by SpamKiller (www.spamkiller.com) --- [ On Thursday, April 19, 2001 at 09:23:34 (-0500), David H. Thornley wrote: ] Subject: Re: Xdelta and CVS CVS uses diff in different ways. One is to keep the revision history files relatively small, and one is to merge changes. I looked at the web pages to see if there was some Xdelta correspondence to diff3, and apparently I'd have to go to Sourceforge, which is down at the moment. If Xdelta can create binary diffs and apply them to other files, in order to merge changes, and these merges result in something useful enough times to make the capability worth having, then it would seem to me to be an extension of the CVS philosophy. As I understand it the more recent versions of Xdelta do indeed have the ability to do three-way merges. Some of the research also seems to indicate that Xdelta is just as successful at computing deltas of, and merging, text files as it is with the traditional text diff algorithm. However one of the problems is in how to represent conflicts in the resulting merges in a way that's easy to resolve with a text editor (at least in the case of text files. I've not actually seen this happen so I'm not sure how the Xdelta tools manage at the moment. It would seem that a visual merge tool would be required to do the edits in all cases (which of course opens up the possibility of having data structure dependent merging tools). Certianly the Xdelta algorithm has been used to great success in rsync. Whether it makes a mark in any new versioning tools beyond PRCS is yet to be seen -- Greg A. Woods +1 416 218-0098 VE3TCP [EMAIL PROTECTED] [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; Secrets of the Weird [EMAIL PROTECTED] ___ 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: WinCVS and MacCVS Logins
If you haven't already, you may want to send this question to [EMAIL PROTECTED] also. And always include as much information as you can. Jerry From: David Fuller [mailto:[EMAIL PROTECTED]] Sent: Thursday, April 19, 2001 7:05 AM Brad Pfautsch wrote: Brad Pfautsch wrote: Logins take upwards of two minutes to receive the "*CVS exited normally with code 0*" message. Any idea's why/how to fix? ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
UCE Complaint (Re: $Name $ and branches)
You have sent the attached unsolicited e-mail to my e-mail account. I do not wish to receive such messages in the future. Please remove my name from your lists immediately. --- This message was intercepted by SpamKiller (www.spamkiller.com) --- [ On Thursday, April 19, 2001 at 11:01:27 (-0500), David D. Hagood wrote: ] Subject: $Name $ and branches Is there some logic behind this behavior? For some of what I am doing, I'd really like to have the $Name$ be replaced with the branch tag. In CVS $Name is really only intended to be used with "cvs export -kv". I.e. it's there to freeze the release name into any identification strings. From a high-level release management view there's little sense in providing any mechanism for identifying the branch name of some product that could have come from any old working directory. All such a mechanism can do is create confusion and lead to mis-identification of products. I.e. the feature you're asking for is *BAD* for the business of hygienic release management! If you ever get to the point where you need to be identifying the origins of some product file then you should already have been creating proper releases with "cvs export -kv" for some time. I.e. it's best to get in the habit of making releases, as appropriate, as early as possible and thus have lots of practice by the time you need to create real releases for external consumption. -- Greg A. Woods +1 416 218-0098 VE3TCP [EMAIL PROTECTED] [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; Secrets of the Weird [EMAIL PROTECTED] ___ 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: Xdelta and CVS
Dear Greg, Thank you very much for your answer. It certainly sheds a whole different light on things. I will notify the webmaster of the mentioned page that the information provided there is misleading, and pass your comments, if you don't mind. What I don't get, is why the whole structure of the repository would change. Wouldn't it be possible to store the Xdelta output instead of the diff output, and in the same place? The problem with using PRCS is that it doesn't have network support (does it?). From the PRCS webpage: "The primary goal of version 2 is to add client/server support A snapshot of PRCS2 was released in April 1999 named prcs2-0.18.0. Do not try to compile this, it won't do anything" That's 2 years ago, so development doesn't seem to be very alive. Same goes for Xdelta (latest release Jun. 14, 2000). The Xdelta sourceforge pages are even more discouraging. I Cc: this mail to it's writer, Josh MacDonald, in the hope to get any information from him. Maybe he has just been to busy with writing PRCS2 to maintain the webpages :-) Another solution might be to use some sort of text format for our audiofiles, but I hardly see that feasible... Kind regards, Maarten ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: $Name $ and branches
[ On Thursday, April 19, 2001 at 11:01:27 (-0500), David D. Hagood wrote: ] Subject: $Name $ and branches Is there some logic behind this behavior? For some of what I am doing, I'd really like to have the $Name$ be replaced with the branch tag. In CVS $Name is really only intended to be used with "cvs export -kv". I.e. it's there to freeze the release name into any identification strings. From a high-level release management view there's little sense in providing any mechanism for identifying the branch name of some product that could have come from any old working directory. All such a mechanism can do is create confusion and lead to mis-identification of products. I.e. the feature you're asking for is *BAD* for the business of hygienic release management! If you ever get to the point where you need to be identifying the origins of some product file then you should already have been creating proper releases with "cvs export -kv" for some time. I.e. it's best to get in the habit of making releases, as appropriate, as early as possible and thus have lots of practice by the time you need to create real releases for external consumption. -- Greg A. Woods +1 416 218-0098 VE3TCP [EMAIL PROTECTED] [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: applying astyle on commit
[ On Thursday, April 19, 2001 at 18:47:33 (+0200), Maarten de Boer wrote: ] Subject: applying astyle on commit So my question is: how can I do this? Doing it client side is not really an option, because we use different platforms, and besides, doing it server-side assures correct usage of astyle. Generally speaking that's way outside the scope of any pure versioning tool. Something like style enforcement is more along the lines of automated policy enforcment in a larger process model. Remember: CVS is not an automated testing program. CVS does not have a builtin process model. If I were you I would switch to using Aegis -- it offers a two-phase commit policy and also offers the ability to require a series of tests to complete on all commits. With Aegis you could arrange things in such a way that one of the tests was a style conformance test or you could do style conformance tests as part of the second commit phase and push any non-conforming changes back to the developer for correction. -- Greg A. Woods +1 416 218-0098 VE3TCP [EMAIL PROTECTED] [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
UCE Complaint (Re: applying astyle on commit)
You have sent the attached unsolicited e-mail to my e-mail account. I do not wish to receive such messages in the future. Please remove my name from your lists immediately. --- This message was intercepted by SpamKiller (www.spamkiller.com) --- [ On Thursday, April 19, 2001 at 18:47:33 (+0200), Maarten de Boer wrote: ] Subject: applying astyle on commit So my question is: how can I do this? Doing it client side is not really an option, because we use different platforms, and besides, doing it server-side assures correct usage of astyle. Generally speaking that's way outside the scope of any pure versioning tool. Something like style enforcement is more along the lines of automated policy enforcment in a larger process model. Remember: CVS is not an automated testing program. CVS does not have a builtin process model. If I were you I would switch to using Aegis -- it offers a two-phase commit policy and also offers the ability to require a series of tests to complete on all commits. With Aegis you could arrange things in such a way that one of the tests was a style conformance test or you could do style conformance tests as part of the second commit phase and push any non-conforming changes back to the developer for correction. -- Greg A. Woods +1 416 218-0098 VE3TCP [EMAIL PROTECTED] [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; Secrets of the Weird [EMAIL PROTECTED] ___ 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: UCE Complaint (Re: applying astyle on commit)
Then may I suggest that you unsubscribe from [EMAIL PROTECTED], and not spam all of *us* with these bounce messages (three of which have appeared in my inbox in the last half hour). Thank you. On Thu, Apr 19, 2001 at 02:59:49PM -0400, Christopher Fogarty wrote: You have sent the attached unsolicited e-mail to my e-mail account. I do not wish to receive such messages in the future. Please remove my name from your lists immediately. --- This message was intercepted by SpamKiller (www.spamkiller.com) --- [ On Thursday, April 19, 2001 at 18:47:33 (+0200), Maarten de Boer wrote: ] Subject: applying astyle on commit So my question is: how can I do this? Doing it client side is not really an option, because we use different platforms, and besides, doing it server-side assures correct usage of astyle. Generally speaking that's way outside the scope of any pure versioning tool. Something like style enforcement is more along the lines of automated policy enforcment in a larger process model. Remember: CVS is not an automated testing program. CVS does not have a builtin process model. If I were you I would switch to using Aegis -- it offers a two-phase commit policy and also offers the ability to require a series of tests to complete on all commits. With Aegis you could arrange things in such a way that one of the tests was a style conformance test or you could do style conformance tests as part of the second commit phase and push any non-conforming changes back to the developer for correction. -- Greg A. Woods +1 416 218-0098 VE3TCP [EMAIL PROTECTED] [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; Secrets of the Weird [EMAIL PROTECTED] ___ 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 -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. - RFC 1925 (quoting an unnamed source) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
not able to see the messages in the group..
Hi, I subsribed to this group. But my new messages are not showing in the yahoo groups( inf-cvs)? What could be the reason. Thanks MM. __ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Xdelta and CVS
[ On Thursday, April 19, 2001 at 20:42:51 (+0200), Maarten de Boer wrote: ] Subject: Re: Xdelta and CVS Thank you very much for your answer. It certainly sheds a whole different light on things. I will notify the webmaster of the mentioned page that the information provided there is misleading, and pass your comments, if you don't mind. I don't mind at all! What I don't get, is why the whole structure of the repository would change. Wouldn't it be possible to store the Xdelta output instead of the diff output, and in the same place? The CVS repository structure is defined as being a collection of RCS-format files. RCS files use only text-diff deltas. You can't add Xdelta files to the CVS repository and still have a CVS repository since then neither CVS nor RCS would be able to access the complete contents of repository -- you'd only be able to use some "CVS+Xdelta" program (and/or RCS+Xdelta program(s)). The problem with using PRCS is that it doesn't have network support (does it?). From the PRCS webpage: "The primary goal of version 2 is to add client/server support A snapshot of PRCS2 was released in April 1999 named prcs2-0.18.0. Do not try to compile this, it won't do anything" That's 2 years ago, so development doesn't seem to be very alive. Same goes for Xdelta (latest release Jun. 14, 2000). The Xdelta sourceforge pages are even more discouraging. I Cc: this mail to it's writer, Josh MacDonald, in the hope to get any information from him. Maybe he has just been to busy with writing PRCS2 to maintain the webpages :-) I have heard that Josh has been very busy of late. How time flies though Of course what is meant by "network support" can simply be a matter of perspective There's no reason why you can't use rsync and similar programs to script up a set of tools that could efficiently distribute working directories from some central server. If your network is fast enough (i.e. is all a LAN) you could even use NFS or similar to access the working directories directly on a central server. In many/most cases there's usually no real need for network support directly in the version control system. I only ever use remote CVS network support to access freeware repositories on the likes of SourceForge, etc. (And even then I prefer to have a local mirror copy of the actual repository and not just remote access to the repo.) Another solution might be to use some sort of text format for our audiofiles, but I hardly see that feasible... I'm not sure what that would gain either. They'd only get bigger and the deltas would still be meaningless and unmergable. Why not just tag the audio files with a version identifier as part of their name and leave them in a directory outside of any structured version control system? You could easily write packaging scripts that could collect the appropriately named audio files and include them as part of any released distribution of the rest of your products. These scripts could obviously be version controlled with the rest of your source and so in the end you'd effectively still be using CVS to manage the versioning of your audio files but just not storing them. :-) -- Greg A. Woods +1 416 218-0098 VE3TCP [EMAIL PROTECTED] [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: checkout with -D resurrects deleted files
Hi, I believe I've found the source of my confusion. When a file is deleted in CVS, then revised by another user, cvs checkout will not produce the file, however cvs checkout -D now will. I'm uncertain if that's a bug or a feature, use of checkout -D ... seems to be the safer way to go. Here is the scenario - Time User 1User 2 -- | cvs checkout proj1 cvs checkout proj1 | rm foo | cvs -remove foo \|/ cvs commit edit foo cvs update cvs commit rm -rf * rm -rf * cvs checkout proj1 cvs checkout proj1 (will not get foo) (will not get foo, where is my change?) rm -rf * rm -rf * cvs checkout -D now proj1 cvs checkout -D now proj1 (will get foo)(will get foo) Regards, Bruce [EMAIL PROTECTED]
RE: Passwd file
Cheers for this. It wasn't liking the blank password which I couldn't figure out as that was in the manual. I'd just assumed that I had the latest version but couldn't check coz "cvs version" didn't work!! Ironic really, given that when set up no one will have a blank password - just never thought to try it with one. David was correct that in order to get the passwords working right the way I want i will need SystemAuth to be turned off as I don't want all system account users to get to all of the source. Thank you both the help and reasoning - been driving me mad for the last few days! Cheers Nigel -Original Message- From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: 19/04/01 18:44 Subject: Re: Passwd file David Fuller writes: You'll have to turn off system auth for the passwd file to start working right. Wrong -- CVS always looks at the repository passwd file. If SystemAuth is set to true, the system passwd file is only consulted if the repository password file doesn't exist or it doesn't contain an entry for the user. You'll also probably want to put something in the password area. Even a blank password has a crypted value. As of CVS 1.11, CVS interprets an empty password field to mean that any password is acceptable (this is typically used only for anonymous, read-only accounts). If you're not running 1.11, then the empty password field will never match, which may be the problem. Try doing ``cvs version'' to find out what version(s) you have -- if that command isn't valid, then you definitely don't have 1.11 (you can get it from www.cvshome.org). -Larry Jones I've got to start listening to those quiet, nagging doubts. -- 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: Xdelta and CVS
"Greg A. Woods" wrote: [ On Thursday, April 19, 2001 at 11:16:31 (+0200), Maarten de Boer wrote: ] Subject: Xdelta and CVS We are using CVS, for several projects, with great pleasure. We now have the need to store and track revisions of large binary files (audio analysis data). Because we are already familiar with CVS, and use it with clients on various platforms, we would like to use CVS for this data as well. That would be a "not-very-smart" thing to do. CVS does not in any way meet your requirements for that kind of data. More accurately, it meets requirements in a rather bad way, using a lot of disk space and offering little benefit you wouldn't get by gzipping and backing up the data regularly. CVS exists to allow concurrent development involving incremental changes to files. Is this useful on the analysis data? Obviously, storing all revisions entirely will not be very efficient. The data is pretty straigthforward, and the differences between versions could be extracted very well with Xdelta. So Xdelta integration in CVS seems to be the solution. Sure, but if you do that then you'll be off using an incompatible branch variant of CVS that has no hope of ever being integrated back into the main variant of CVS that uses standard RCS files for storage. Note also that you cannot change what is considered to be "the main variant of CVS" unless you convince the majority of CVS users to give up on RCS as the sole repository file format either. Um, what's so sacred about RCS file format? I realize that file formats are to be changed only with caution, but since the entire functionality is internalized into CVS (as of 1.10, I believe) there is no reason why it cannot be changed for a good purpose. The second idea is just plain wrong in claiming that it would not change the CVS repository format since it would, by definition. RCS uses "diff" and only "diff" for delta storage. What it really proposes is to change RCS. No, what it proposes to do is to replace RCS. I thought that the essence of CVS was something other than its file format. Overall what that web page fails to note is that introduction of such a drastic change to the repository data structures would make any such repository incompatible with any normal RCS-only version of CVS, and indeed incompatible with RCS itself. Perhaps the web page author considered that it would be obvious to the intended reader (i.e., somebody considering development work on CVS). In any case, I really don't care about compatibility with RCS. RCS is on my list of stuff I never want to use again, not that far below COBOL. BTW, that web page also fails to give full justice to the size of the project. If you're really serious about something along these lines you'd be INFINITELY better off if you simply started a new design for a versioning tool and wrote it right from scratch. I'm not all that familiar with CVS internals (not having had to mess around with it like I did Gnats), but it seems to me that we're talking about changing the repository format, nothing else. If this is a really large project, then CVS is very badly designed. (Now, test and validation would be time-consuming.) There is the obvious need for both-way conversion programs, but after that I think the Xdelta version would see fairly rapid acceptance. (How rapid depends partly on how effective the merging was, which is to say whether two changes in a file can be merged to produce another useful file. This would obviously depend partly on the file format, and I'm not an authority on common binary file formats.) I am well aware of the fact, that CVS has not been designed to deal with large binary files, and that some people would consider it undesirable to add such functionality. I think it is worth the try though. As this is an important issue for our project, I can spend some time on this. You've obviously been blinded by your situation. What you're proposing is somthing new and entirely different which may have a command-line like that of CVS, but which would otherwise not be CVS. Calling it "CVS" would be wrong. Given a copy of CVS, and a copy of XCVS, with the ability to use both but not examine repository format or source code, could you necessarily tell the difference? If properly implemented, it seems to me that the changes could be mostly invisible. Given that this could be a plug-compatible replacement to everybody but the admins, why would it be new and entirely different? -- David H. Thornley Software Engineer at CES International, Inc.: [EMAIL PROTECTED] or (763)-694-2556 at home: (612)-623-0552 or [EMAIL PROTECTED] or http://www.visi.com/~thornley/david/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
$Name $ in branches
I disagree with Mr. Woods on this: adding the branch ID to a build makes sense in my environment: I have several developers, each working on their own branch of an embedded system. As needed, the load their code into target systems for development. Since the number of developers is larger than the number of target systems available to do development on, there needs to be some reuse of the systems. Being able to quickly identify that "Oh, this unit has Bruce's build, therefor I should contact him about this" would save a great deal of time. Also, this would allow the software to automatically maintain unique setups across different development branches. Sometimes I want MY setups to be different from Bruce's, or I need to unit to access MY section of the server, rather than Bruce's. Again, if I can generate this automatically it saves an error prone step. Additionally, I have to deal with marketing types who frequently come into the lab and stea..., er, borrow units to take to customers. Sometimes those units aren't as controlled as they should be. If the software can get the branch ID, it can correctly ID that is ISN'T a released version, and jump up and down and scream about it. This is the best solution I can come up with that management will allow (bludgeoning the individuals in question is not considered viable). Actually, what I'd really rather see would be a $Branch$ or something that would allow me to contain that information. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Xdelta and CVS
On Thu, Apr 19, 2001 at 03:47:14PM -0500, David H. Thornley wrote: (How rapid [-ly an xdelta-capable CVS was accepted by the world at large] depends partly on how effective the merging was, which is to say whether two changes in a file can be merged to produce another useful file. It would be exactly as effective as it is now (ie. good for text, useless for binary). The merge algorithm is completely orthogonal to the storage format; a merge from an xdelta repo would be done the same way it is now: - check out any needed revisions - point diff3 at them (Well, the implementation might be a bit different. I think those two steps are currently encapsulated within the compiled-in copy of rcsmerge; if so, they'd have to be pulled up into the CVS-proper layer.) The fact that merging and delta generation currently use the same algorithm is a coincidence, and as far as I know, nothing depends on it. This would obviously depend partly on the file format, and I'm not an authority on common binary file formats.) This is therefore an unrelated (albeit frequently debated) issue :-) -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. - RFC 1925 (quoting an unnamed source) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: $Name $ in branches
[ On Thursday, April 19, 2001 at 16:12:25 (-0500), David D. Hagood wrote: ] Subject: $Name $ in branches I disagree with Mr. Woods on this: adding the branch ID to a build makes sense in my environment: I have several developers, each working on their own branch of an embedded system. As needed, the load their code into target systems for development. Since the number of developers is larger than the number of target systems available to do development on, there needs to be some reuse of the systems. Being able to quickly identify that "Oh, this unit has Bruce's build, therefor I should contact him about this" would save a great deal of time. Huh? Why doesn't the $Author keyword (part of $Id, BTW), work for you then? Or are the developers each checking out the entire project on their own branch, working on some random part of it, and then plugging a sub-product that may have been built from changes by many separate developers into a common/shared test environment? In either case though it would seem that your process is fatally flawed (at least from a release management perspective). Also, this would allow the software to automatically maintain unique setups across different development branches. Sometimes I want MY setups to be different from Bruce's, or I need to unit to access MY section of the server, rather than Bruce's. Again, if I can generate this automatically it saves an error prone step. Still it would be of enormous benefit to force developers to create mini releases of anything and *everything* that goes onto a common test system From a higher-level release management perspective there's NEVER any excuse for letting something out of a developer's direct control (i.e. into an environment where its origins and status must be identifiable) unless it's been properly "released". In CVS this is most easily done by simply tagging the code to be released and using "cvs export -kv" to create a copy that can be compiled such that the resulting products can be shared. You don't have to keep the tags forever -- only so long as the released product exists in any place where it needs to be identified. The $Name keyword will work *perfectly* for this since that's the way it was "designed" to work in CVS. In fact in CVS this kind of release management is so trivially easy that there's not really any excuse for avoiding it. All you need to do is define a release tag naming scheme, give everyone five minutes of training, and carry a big stick to reinforce the training Proper release management reduces errors and saves one from many headaches. You can't really use any version control system effectively in a multi-user development environment without doing proper release management. Note also that this automatically gets rid of the issue of un-committed code going into a "public"/shared/common test environment where its origins might need to be identified. In fact now that I think about it, this is perhaps your central problem right there. You're letting developers test un-committed code on shared test systems. This isn't really an effective way to use version control. You have to freeze changes *before* you share them in any way! Remember that you can't do effective QA without having a proper release management policy and without doing some level of change control. Release management is what allows you do identify what exactly you're testing in the QA phase of your development process. CVS itself can only help do some of this stuff at a very low level. Additionally, I have to deal with marketing types who frequently come into the lab and stea..., er, borrow units to take to customers. That's a management issue, not a CVS issue! ;-) Big sticks, commonly called "clue-by-4s" in B.O.F.H. circles, might help here too! :-) Every repository manager needs B.O.F.H. training! ;-) As for letting the marketing types get away with such shenanigans, well, "You create the circumstances you must live with." Actually, what I'd really rather see would be a $Branch$ or something that would allow me to contain that information. You can't really do that without changing the RCS file format! :-) (of course this would be a relatively trivial and innocuous change and could be done in a relatively compatible way, though full ineroperability with other RCS tools would not be possible.) -- Greg A. Woods +1 416 218-0098 VE3TCP [EMAIL PROTECTED] [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: $Name $ in branches
I haven't tried it, but it looks like the $State$ keyword could provide the functionality you're looking for. See: http://www.cvshome.org/docs/manual/cvs_12.html#SEC98 and http://www.cvshome.org/docs/manual/cvs_16.html#SEC120 Jerry ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Is the pserver running without starting by inetd?
On Thu, Apr 19, 2001 at 17:57 +0200, Dominik Kalb wrote: does anyone of you know, whether the pserver can start up without the inet deamon? Of course. Run any inetd like program listening to network sockets and handing them to newly created processes at request. Another x?inetd instance or DJB's ucspi-tcp (tcpserver) are the most prominent examples. I have an UNIX account to an internet server, but no access to the configuration files and my provider don't want setup the neccessary configurations. (security doubt) You better make sure that you don't run a service your provider refuses to allow running then. I don't see the point in "he's concerned and won't support me running it, so I have it run by myself". But that's not a technical question ... So, is it possible to start a cvs pserver process manually from the shell? Have you actually tried it? Have you considered searching the list's archive? The answer is yes. virtually yours 82D1 9B9C 01DC 4FB4 D7B4 61BE 3F49 4F77 72DE DA76 Gerhard Sittig true | mail -s "get gpg key" [EMAIL PROTECTED] -- If you don't understand or are scared by any of the above ask your parents or an adult to help you. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Repository Migration...
On Thu, Apr 19, 2001 at 09:49 -0700, mm rao wrote: I am are trying to move the repository to a brand new machine where the cvs-1.11 is installed( current ver 1.9). Can anybody please help me in expalining, the steps need to be followed and waht all needs to be taken care? In a decent setup it boils down to changing one CNAME in your DNS database and not bothering your users at all. Why it is this easy and what to do if you don't have the appropriate setup already has been discussed several dozen times in the list and is archived at the usual places. Go and make use of this facility before asking others to repeat it once more. "Moving" and "repository" is the combination you are searching for. virtually yours 82D1 9B9C 01DC 4FB4 D7B4 61BE 3F49 4F77 72DE DA76 Gerhard Sittig true | mail -s "get gpg key" [EMAIL PROTECTED] -- If you don't understand or are scared by any of the above ask your parents or an adult to help you. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: $Name $ in branches
[ On Thursday, April 19, 2001 at 18:19:04 (-0700), Jerry Nairn wrote: ] Subject: RE: $Name $ in branches I haven't tried it, but it looks like the $State$ keyword could provide the functionality you're looking for. Take care because $State is also used internally in CVS. Probably the most critical use is the state of "dead" (which is used for "removed" files). -- Greg A. Woods +1 416 218-0098 VE3TCP [EMAIL PROTECTED] [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Installing cvs on Solaris 2.6
PROBLEM TARGET = I want to connect to a CVS installed on a Solaris through a wincvs front End running on a NT m/c. ERROR = I can't configure CVS on SOLARIS 2.6. Login Faliure [ Within the solaris - itself ]. Please send me a correct Manual for installation and advice. Here is what I did so far: CVS Version I am using: Concurrent Versions System (CVS) 1.11 (client/server) Copyright (c) 1989-2000 Brian Berliner, david d `zoo' zuhn, Jeff Polk, and other authors What I did: step 1: gzip -d cvs-1.11-sol8-sparc-local.gz step 2: pkgadd -d cvs-1.11-sol8-sparc-local cvs got added to /usr/local/bin step 3: Created a user ( group) called: cvs step 4: Created a repository: cvs -d /usr/local/cvsroot init step 5: Changed owner and group of repository and all files to cvs: chown -R cvs.cvs /usr/local/cvsroot step 6: Created a tcp service by editing /etc/services - add line (NOTE: May already be present): cvspserver 2401/tcp #CVS PServer step 7: Created a inetd entry for service by editing /etc/inetd.conf - add following lines: # # CVS PServer # cvspserver stream tcp nowait cvs /usr/bin/cvs cvs --allow-root=/usr/local/cvsroot pserver step 8: Restarted inetd step 9: Then logged in as the user cvs. [ I added a passwd file on to /usr/local/cvsroot/CVSROOT] step 10: I set the default repository in the environment setenv CVSROOT :pserver:[EMAIL PROTECTED]:/usr/local/cvsroot [ cvs is the unix user and password is the same as the user name ] step 11: Login: cvs login This is what I am getting; iNet:/usr/local/bin>cvs login (Logging in to [EMAIL PROTECTED]) CVS password: cvs [login aborted]: recv() from server 204.143.101.100: EOF iNet:/usr/local/bin> OR Connection reset by peer OR broken pipe Thanks in advance. Srimal
Problem in Installing CVS on Solaris 2.6
PROBLEM TARGET = I want to connect to a CVS installed on a Solaris through a wincvs front End running on a NT m/c. ERROR = I can't configure CVS on SOLARIS 2.6. Login Faliure [ Within the solaris - itself ]. Please send me a correct Manual for installation and advice. Here is what I did so far: CVS Version I am using: Concurrent Versions System (CVS) 1.11 (client/server) Copyright (c) 1989-2000 Brian Berliner, david d `zoo' zuhn, Jeff Polk, and other authors What I did: step 1: gzip -d cvs-1.11-sol8-sparc-local.gz step 2: pkgadd -d cvs-1.11-sol8-sparc-local cvs got added to /usr/local/bin step 3: Created a user ( group) called: cvs step 4: Created a repository: cvs -d /usr/local/cvsroot init step 5: Changed owner and group of repository and all files to cvs: chown -R cvs.cvs /usr/local/cvsroot step 6: Created a tcp service by editing /etc/services - add line (NOTE: May already be present): cvspserver 2401/tcp #CVS PServer step 7: Created a inetd entry for service by editing /etc/inetd.conf - add following lines: # # CVS PServer # cvspserver stream tcp nowait cvs /usr/bin/cvs cvs --allow-root=/usr/local/cvsroot pserver step 8: Restarted inetd step 9: Then logged in as the user cvs. [ I added a passwd file on to /usr/local/cvsroot/CVSROOT] step 10: I set the default repository in the environment setenv CVSROOT :pserver:[EMAIL PROTECTED]:/usr/local/cvsroot [ cvs is the unix user and password is the same as the user name ] step 11: Login: cvs login This is what I am getting; iNet:/usr/local/bin>cvs login (Logging in to [EMAIL PROTECTED]) CVS password: cvs [login aborted]: recv() from server 204.143.101.100: EOF iNet:/usr/local/bin> OR Connection reset by peer OR broken pipe Thanks in advance.
Re:directory addition
Dear all, Thank you so much for all your answers .. i get it now .. thx, a Java Addicted --- Runbox Mail Manager - www.runbox.com Free online email application ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: directory addition
On Thu, Apr 19, 2001 at 10:06:30AM +, JavaSoft wrote: now.. last question if your dont mind.. if my friend added a directory(not empty directory) to CVS server.. how can i get the new directory to my local hard disk ?? should i check out the whole module everytime a new directory added ?? or can i just check out to the specific new directory ??? mskranz@seth:~/development$ cvs --help update Usage: cvs update [-APdflRp] [-k kopt] [-r rev|-D date] [-j rev] [-I ign] [-W spec] [files...] -A Reset any sticky tags/date/kopts. -P Prune empty directories. -C Overwrite locally modified files with clean repository copies. -d Build directories, like checkout does. ... Cheers, Matthias -- Matthias Kranz [EMAIL PROTECTED] http://www.belug.org/~kranz ech`echo xiun|tr nu oc|sed 'sx\([sx]\)\([xoi]\)xo un\2\1 is xg'`ol ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: WinCVS and MacCVS Logins
My first two ideas: 1) slow connection/heavy load server? 2) Are you using TCP compression? -- David F. Brad Pfautsch wrote: Logins take upwards of two minutes to receive the *CVS exited normally with code 0* message. Any idea's why/how to fix? ___ 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: WinCVS and MacCVS Logins
It would be awfull darn usefull if you gave us something to work with here. What version of cvs are you running, on the server? What os and version are you running on the server? Do other commands complete faster? donald On Thu, Apr 19, 2001 at 07:35:34AM -0500, Brad Pfautsch wrote: Logins take upwards of two minutes to receive the *CVS exited normally with code 0* message. Any idea's why/how to fix? ___ 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: directory addition
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Use the following CVS command: cvs update -d -P from the top directory of your sandbox. The -d option tells CVS to create directories that have been added to the repository that don't exist in your sandbox and the -P tells CVS to delete directories that are now empty (because all the files in them have been removed). - - Tim -Original Message- From: JavaSoft [mailto:[EMAIL PROTECTED]] Sent: Thursday, April 19, 2001 6:07 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: directory addition Thank you sir. now i am understand ... now.. last question if your dont mind.. if my friend added a directory(not empty directory) to CVS server.. how can i get the new directory to my local hard disk ?? should i check out the whole module everytime a new directory added ?? or can i just check out to the specific new directory ??? thx, a Java Addicted --- Runbox Mail Manager - www.runbox.com Free online email application ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs -BEGIN PGP SIGNATURE- Version: PGPfreeware 6.5.8 for non-commercial use http://www.pgp.com iQA/AwUBOt7q9H0GulZt1ukUEQJ75ACguE4qo73uTe8HPNfKoodX8ExqvCMAoMwi +qQv0IPlGSmXdEodi4DGEO7X =Dl60 -END PGP SIGNATURE- ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Passwd file
You'll have to turn off system auth for the passwd file to start working right. You'll also probably want to put something in the password area. Even a blank password has a crypted value. -- David F. Nigel Morse wrote: I've set up CVS for remote repository, and I can login using a system user account (i.e. my own) but I want to use separate passwords and have CVS run as a common user so I can tighten permissions (more to prevent accidental deletation). I created a $CVSROOT/CVSROOT/passwd file with just dummy::cvs in it (cvs is a system account), but I can login as dummy with no password - i just get the failed message. I can still login using my own (system) account (ultimately I will turn off the system auth. ability). Do I have to do anything special to the passwd file to get it to be used? From what I can tell its the latest version (came with red hat linux 6.2) Cheers Nigel ___ 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: directory addition
There's no need to do a new checkout, just do an update -d and it will check out the new directory. Keep in mind, however, that there must be a file in the new directory, or it will not be updated. HTH, Rob Helmer Namodn On Thu, Apr 19, 2001 at 10:06:30AM +, JavaSoft wrote: Thank you sir. now i am understand ... now.. last question if your dont mind.. if my friend added a directory(not empty directory) to CVS server.. how can i get the new directory to my local hard disk ?? should i check out the whole module everytime a new directory added ?? or can i just check out to the specific new directory ??? thx, a Java Addicted --- Runbox Mail Manager - www.runbox.com Free online email application ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs - End forwarded message - ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
applying astyle on commit
Hello, We use some strict rules on code layout, but of course people sometimes make mistakes. Luckily, astyle does a great job in layouting automatically. So I would like to apply astyle on all the code that is commited to the repository, so the code inside the repository is always correct. People would only have to do an update after to commit to get the formatted version. So my question is: how can I do this? Doing it client side is not really an option, because we use different platforms, and besides, doing it server-side assures correct usage of astyle. Kind regards, Maarten ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Repository Migration...
Hi, I am are trying to move the repository to a brand new machine where the cvs-1.11 is installed( current ver 1.9). Can anybody please help me in expalining, the steps need to be followed and waht all needs to be taken care? We have got too many number of users. What is the best plan to migrate? Has any body done this before? I guess all users should check in before migration and after migration they have to checkout again from the new server. What's about the changes they made in between? As somebody suggested, if every user needs to run the script to mudify info in CVS/Repository and cva/root files, where the script available. Any problems with this method. Please help me in this regard. Thanks in advance, --MM __ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Val-tags file
Hi, Does anyone may explain me which is the val-tags file syntax ? This file is used by the CVS in which situations? It is only used to store the tags and branch names that are in use? Thanks in advance. Rui Cordeiro ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Xdelta and CVS
[ On Thursday, April 19, 2001 at 15:47:14 (-0500), David H. Thornley wrote: ] Subject: Re: Xdelta and CVS More accurately, it meets requirements in a rather bad way, using a lot of disk space and offering little benefit you wouldn't get by gzipping and backing up the data regularly. Yeah, whatever! :-) Um, what's so sacred about RCS file format? I realize that file formats are to be changed only with caution, but since the entire functionality is internalized into CVS (as of 1.10, I believe) there is no reason why it cannot be changed for a good purpose. Those two points are totally orthogonal. Some people have even argued that the CVS repository format is irrelevant and all that matters is the network protocol, though they've missed some of the inherent issues in the protocol's design that effectively require text-based diffs as the delta storage format. The RCS format is important because it makes it possible to retrieve the contents of the repository with third-party tools (eg. RCS itself). RCS file format is well documented and tools for handling it are widely implemented, the canonical definition being publicly and freely available. The RCS format is also important because it guarantees forward and backward and sideways compatibility and interoperability with other releases and variants of CVS. One can rewrite CVS from scratch and still *interoperate* with the exact same repository. Finally the RCS format is important because it means that many RCS users can migrate to using CVS without losing version history or trying to figure out how to convert it to some new format. I.e. I sure don't want to change my CVS repository format, though if I were to do so it would only be to some other well known text-based delta storage format (and I only know of one other: SCCS). The second idea is just plain wrong in claiming that it would not change the CVS repository format since it would, by definition. RCS uses diff and only diff for delta storage. What it really proposes is to change RCS. No, what it proposes to do is to replace RCS. I thought that the essence of CVS was something other than its file format. Well, OK, yes, it replaces RCS (the change would be complete :-). The essense of CVS is more than just its file format. However historically CVS was just an RCS wrapper and its file format was defined by RCS. Many features of CVS are also just RCS features. At one point back in the not so distant history of CVS (i.e. prior to RCS and diff integration) this kind of replacement of RCS would have been relatively easy (not trivial -- I actually investigated the level of difficulty a few years ago). One need just change the implementation of the underlying RCS commands it used. For example one could have dropped BitSCCS in and with a relatively few hacks to CVS and you would pretty much have built an SCCS-based CVS (BitSCCS has RCS command-line compatability). With only slightly more hacks you could have built a CVS that used ATT SCCS (or GNU CSSC, MySC, etc.). If the hacks were done carefully you'd even end up with a CVS that could use either storage system, and maybe even any random tool with similar underlying capabilities. Some of the hacks required would have revolved around branch numbering issues, keyword expansion differences, etc. Obviously none of that would have made CVS suitable for *binary* files (i.e. data files with opaque internal structure that cannot be merged with diff3 and a text editor to resolve marked conflicts), since CVS is still a concurrent versioning system. Note also that changing the delta format involves changing the remote protocol support (or at least dropping support for sending patches to the client, which may totally destroy the efficiency and make it unusable for many people). I'm not all that familiar with CVS internals (not having had to mess around with it like I did Gnats), but it seems to me that we're talking about changing the repository format, nothing else. If this is a really large project, then CVS is very badly designed. Indeed. :-) CVS, having been once just a wrapper around the CVS commands, is inhernently tied tightly to many RCS features and semantics, and now that it has its own internal implementation of RCS handling functionality it's even more tightly integrated into the RCS way of doing things. (Now, test and validation would be time-consuming.) Well, some would, but it's that's another part of CVS that desparately needs re-writing anyway Many of the current tests though would still be valid and suitable for regression testing. There is the obvious need for both-way conversion programs, but after that I think the Xdelta version would see fairly rapid acceptance. (How rapid depends partly on how effective the merging was, which is to say whether two changes in a file can be merged to produce another useful file. This would obviously depend partly on the file format, and I'm not an
