Re: newbie question on initializing repository
Hello, * On Mon, Jun 07, 2004 at 05:34:02PM -0400 Larry Jones wrote: However, I now believe its not that simple, as the binary files(only) must be initialized with the -kb option. Is that correct? If so, any suggestions on the simplest/easiest to go about this? If you can distinguish the binary files from the text files by their names (e.g., *.gif files are always binary), you can use the CVS wrappers facility to automatically handle the files correctly To add to this: If the text files are Unix-style (LF only), I also had success in importing everything as binary, and changing the text files to text afterwards with cvs admin. If the text files are Windows style, doing a dos2unix on them, and then treating it as in the above case, works, too. Best regards, Spiro. -- Spiro R. Trikaliotis I'm subscribed to the mailing lists I'm posting, http://www.trikaliotis.net/ so please refrain from Cc:ing me. Thank you. ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Any CVS tricks for creating patch files?
Hello, * On Mon, Jun 07, 2004 at 05:46:20PM -0400 [EMAIL PROTECTED] wrote: To create a patch, I could do this: % cvs co -d buggy -r Release_0_1 MyProj % cvs co -d fixed -r Release_0_1_Bugfixes MyProj % LC_ALL=C TZ=UTC0 diff -Naur buggy fixed Release_0_1_Patch ...but I wonder if there are some CVS tricks to streamline the process further. $ cvs co -r Release_0_1_Bugfixes MyProj $ cd MyProf $ cvs diff -uN -r Release_0_1 ../Release_0_1_Patch I think (but I have not tested it) that $ cvs rdiff -uN -r Release_0_1 -r Releae_0_1_Bugfixes Release_0_1_Patch should work, too. Regards, Spiro. -- Spiro R. Trikaliotis I'm subscribed to the mailing lists I'm posting, http://www.trikaliotis.net/ so please refrain from Cc:ing me. Thank you. ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
RE: Any CVS tricks for creating patch files?
Spiro Trikaliotis wrote: $ cvs rdiff -uN -r Release_0_1 -r Releae_0_1_Bugfixes What does the -N flag do? It isn't documented. -- Jim Hyslop Senior Software Designer Leitch Technology International Inc. (http://www.leitch.com) Columnist, C/C++ Users Journal (http://www.cuj.com/experts) ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Info-cvs Digest, Vol 19, Issue 17
Hello, * On Mon, Jun 07, 2004 at 05:34:02PM -0400 Larry Jones wrote: However, I now believe its not that simple, as the binary files(only) must be initialized with the -kb option. Is that correct? If so, any suggestions on the simplest/easiest to go about this? If you can distinguish the binary files from the text files by their names (e.g., *.gif files are always binary), you can use the CVS wrappers facility to automatically handle the files correctly To add to this: If the text files are Unix-style (LF only), I also had success in importing everything as binary, and changing the text files to text afterwards with cvs admin. If the text files are Windows style, doing a dos2unix on them, and then treating it as in the above case, works, too. Best regards, Spiro. Spiro, Thanks for your reponse. It prompts a couple more questions. When you went back and ran the cvs admin command, did you have to run it once for every file you wanted to change? Also, would it work equally well to put all the files in as regular files and the run cvs admin later to change the binary files? ThanksBret Cooper IBM Global Services - ATT ADM Account 614.501.2540___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Info-cvs Digest, Vol 19, Issue 17
Hello Bret, * On Tue, Jun 08, 2004 at 01:50:36PM -0400 Bret A Cooper wrote: Thanks for your reponse. It prompts a couple more questions. When you went back and ran the cvs admin command, did you have to run it once for every file you wanted to change? Yes, this has to be run for every file to be changed. Anyway, you can use wildcards, so a cvs admin -kk *.c *.cc *.h makefile and so on works very good. Even if you forget to change a file to text mode, it does not do much harm, as you can even do this afterwards. Also, would it work equally well to put all the files in as regular files and the run cvs admin later to change the binary files? It depends upon your binary files. If 1. your client runs Windows (CR/LF instead of LF), or 2. you binary files contain any of the RCS keywords ($Id$, $Log$, etc), 3. not sure if there are other conditions which could do havoc to your binary files, chances are very good your binary files will get corrupted, and you will not be able to recover them from CVS. Thus, checking everything in as binary is a more defensive solution than the opposite. Regards, Spiro. -- Spiro R. Trikaliotis I'm subscribed to the mailing lists I'm posting, http://www.trikaliotis.net/ so please refrain from Cc:ing me. Thank you. ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
cvs format strings
Hi, After upgrading cvs due to the vulnerability, I see the following: cvs commit: warning: Set to use deprecated info format strings. Establish compatibility with the new info file format strings (add a temporary '1' in all info files after each '%' which doesn't represent a literal percent) and set UseNewInfoFmtStrings=yes in CVSROOT/config. After that, convert individual command lines and scripts to handle the new format at your leisure. Mailing the commit message... We're using the Apache CVS log_accum.pl and my loginfo looks like: DEFAULT $CVSROOT/CVSROOT/log_accum.pl %s What do I need to do? (I also added UseNewInfoFmtStrings=yes to the CVSROOT/config file) Thanks, Jason ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Any CVS tricks for creating patch files?
Hello Jim, * On Tue, Jun 08, 2004 at 09:03:27AM -0400 Jim.Hyslop wrote: Spiro Trikaliotis wrote: $ cvs rdiff -uN -r Release_0_1 -r Releae_0_1_Bugfixes What does the -N flag do? It isn't documented. forget it, it is non-existant with rdiff, while it exists with diff. So it is my fault. with diff (not cvs diff), the option -N tells diff to treat files which are non-existant in one directory as if it was there, but empty. This way, the diff is complete. If you do not specify -N, diff only tells you that some file was missing, but you don't see the contents of it. As I said, this option is missing with cvs rdiff, while it exists with cvs diff (cvs 1.11.16). Is this difference by intention, or is it accidentially? I would find it very usefull for rdiff. The following simple skript demonstrates this: -- #! /bin/bash export CVSROOT=~/test.cvsroot/ cvs init mkdir ~/test.cvsroot/test/ cvs co test cd test cat f1 % This is file 1 % cvs add f1 cvs commit -m First version cvs tag v1 cat f2 % This is file 2 % cvs add f2 cvs commit -m 2nd version cvs tag v2 rm f1 cvs rm f1 cvs commit -m 3rd version cvs tag v3 cvs diff -u -r v2 ../v2_v3.diff cvs diff -u -r v1 ../v1_v3.diff cvs diff -uN -r v2 ../v2_v3_N.diff cvs diff -uN -r v1 ../v1_v3_N.diff -- Regards, Spiro. -- Spiro R. Trikaliotis I'm subscribed to the mailing lists I'm posting, http://www.trikaliotis.net/ so please refrain from Cc:ing me. Thank you. ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Automatic merging
I'm trying to get my company to move to CVS from Source Safe. One of the concerns that people have raised is that CVS does automatic merging of changes with the repository. Apparently they had bad experiences with PVCS which did the same thing. I personally never had these problems with PVCS, but there it is. My understanding is that even when CVS does the automatic merging of changes, it does not commit them to the repository until you OK the changes is that correct? What has been the experience with this feature in CVS? BTW, Source Safe also does automatic merging, but I think it does a rather poor job. I don't know why the CVS automatic merging is an issue, but I can't explain human behavior. I'm hoping CVS merging is better and I can use that to sell it's use. ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
RE: Automatic merging
Carucci, Jason wrote: I'm trying to get my company to move to CVS from Source Safe. Have a look here: http://www.highprogrammer.com/alan/windev/sourcesafe.html it may give you additional information to help you convince others. BTW, Source Safe also does automatic merging, but I think it does a rather poor job. I don't know why the CVS automatic merging is an issue, but I can't explain human behavior. I'm hoping CVS merging is better and I can use that to sell it's use. Comfort level. CVS is new and strange, Source Safe is familiar and comfortable (even if it is badly broken). Logic tells you the worn out, ragged slippers should be thrown in the garbage, but emotion rules and we hang onto them. -- Jim ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Automatic merging
On Tue, 2004-06-08 at 15:53, Frederic Brehm wrote: The only problem I have had is once when there was a project full of cowboys who did not bother to communicate with each other and wanted to fix everything themselves. The merge problems were a symptom of a dysfunctional team and no source code control system could fix that. Very nicely put. Constant merge conflicts are usually a symptom, not a problem. Yours, Tom ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Deleting a Directory
We've followed the proper procedure for removing a subdirectory tree from our source tree. When we checkout the source tree it no longer creates the directory hierarchy that we've removed. The checkout process, however, stil traverses the tree and prints out messages as it does so. Is there a way to tell cvs to stop doing this? -- Jake Colman Sr. Applications Developer Principia Partners LLC Harborside Financial Center 1001 Plaza Two Jersey City, NJ 07311 (201) 209-2467 www.principiapartners.com ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: CVS corrupts binary files ...
[ On Saturday, June 5, 2004 at 17:10:58 (-0700), Paul Sander wrote: ] Subject: Re: CVS corrupts binary files ... Source files are any files that cannot be reproduced automatically. Nope, that's wrong too. Source files are those files written and edited by humans. Source _code_ is human (and machine) readable. Intermediate files that might be binary in nature are not source. -- Greg A. Woods +1 416 218-0098 VE3TCPRoboHack [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED] Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: CVS corrupts binary files ...
[ On Saturday, June 5, 2004 at 20:52:06 (-0700), Paul Sander wrote: ] Subject: Re: CVS corrupts binary files ... Yeah, well, sending such hapless people away is easier than fixing the tool. The tool is not broken -- I.e. there's nothing to fix! CVS is designed _only_ for tracking changes in human written text files. If you want to design (and implement) a new tool that does work well with non-text files then please do so. That'll give us yet another tool to recommend people use when they want to. Demonstrating that such support could be added to CVS was done in less than eight man-hours; Nope -- it's just not possible, as you should well know. This is a fundamental and purposeful design limitation in CVS. The entire concept of concurrent editing, which is central to the design and goals of CVS, is completely antithetical to managing binary files. Changing the design of CVS would make it some other VS that is not CVS any more. -- Greg A. Woods +1 416 218-0098 VE3TCPRoboHack [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED] Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Branch mess, and starting a project with import
[ On Friday, June 4, 2004 at 21:41:02 (-0400), Larry Jones wrote: ] Subject: Re: Branch mess, and starting a project with import Greg A. Woods writes: cvs import should really never be used for anything but third-party code that's going to be managed on a CVS-style magic vendor branch. (though it is relatively easy to remove all traces of the vendor branch if it's done soon enough) It's even easier to just ignore it. It's not really 100% safe though -- at minimum the default branch must be returned to the trunk _before_ any other branches are made. Removing the tags also helps avoid future confusion, and once you've gone that far then you may as well outdate the 1.1.1.1 revision too. Personally I think using cvs add is easier, even if it means writing a wee script on the command line to do deep adds. -- Greg A. Woods +1 416 218-0098 VE3TCPRoboHack [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED] Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Branch mess, and starting a project with import
Greg A. Woods writes [re ignoring the vendor branch]: It's not really 100% safe though -- at minimum the default branch must be returned to the trunk _before_ any other branches are made. Why? What practical difference does it make whether the branch is rooted off the trunk revision or the identical revision on the vendor branch? -Larry Jones Mr. Subtlety drives home another point. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: CVS corrupts binary files ...
[ On Saturday, June 5, 2004 at 13:01:48 (-0700), Adrian Constantin wrote: ] Subject: Re: CVS corrupts binary files ... I don't wanna merge binary files, and I'm not likely to modify them in my module (project). I just want cvs to carry them along with the sources Then your better tool is called a directory (i.e. outside of CVS) and you use it with a simple reference to it from within your build system. -- Greg A. Woods +1 416 218-0098 VE3TCPRoboHack [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED] Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: CVS corrupts binary files ...
--- Forwarded mail from [EMAIL PROTECTED] Source files are any files that cannot be reproduced automatically. Nope, that's wrong too. Source files are those files written and edited by humans. That's exactly what I said. Read that sentence again. Source _code_ is human (and machine) readable. This is true, after a fashion. You still need a tool to read it. You seem to think that such a tool MUST be a text editor, but in fact such tools can edit data in other formats. Intermediate files that might be binary in nature are not source. ^^ ^^^ That is true. Doesn't matter what format they're in. --- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Any CVS tricks for creating patch files?
Spiro Trikaliotis writes [re -N]: As I said, this option is missing with cvs rdiff, while it exists with cvs diff (cvs 1.11.16). Is this difference by intention, or is it accidentially? I would find it very usefull for rdiff. It's not just useful, it's essential. The option doesn't exist because it's always assumed for rdiff! -Larry Jones Even my FRIENDS don't do what I want. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: CVS corrupts binary files ...
Oops, I omitted the Sept. 16 patch. Here it is at the bottom. --- Forwarded mail from [EMAIL PROTECTED] --- Forwarded mail from [EMAIL PROTECTED] [ On Saturday, June 5, 2004 at 20:52:06 (-0700), Paul Sander wrote: ] Subject: Re: CVS corrupts binary files ... Yeah, well, sending such hapless people away is easier than fixing the tool. The tool is not broken -- I.e. there's nothing to fix! CVS is designed _only_ for tracking changes in human written text files. So you say. I maintain that the diff and merge tools can be easily swapped out without making significant changes to the CVS design. With regard to merge tools, I proved my point with a patch posted to this forum on Sept. 16, 2001. I've included that patch at the bottom of this message. If you want to design (and implement) a new tool that does work well with non-text files then please do so. That'll give us yet another tool to recommend people use when they want to. No need. See the patch below. Demonstrating that such support could be added to CVS was done in less than eight man-hours; Nope -- it's just not possible, as you should well know. This is a fundamental and purposeful design limitation in CVS. The entire concept of concurrent editing, which is central to the design and goals of CVS, is completely antithetical to managing binary files. I don't believe it was a purposeful design limitation. CVS was initially designed before binary source formats were common, and it just didn't happen to include a plug-in method to support them. Keep in mind also that there's a difference between binary files and mergeable files. The two concepts are in fact orthogonal; there are mergeable binary types (given a suitable tool), and there are unmergeable text types. CVS is bad at storing unmergeable files, no matter whether or not they're binary files. CVS can be easily modified to support mergeable binary types, as I've demonstrated, without significant impact to its design. --- End of forwarded message from [EMAIL PROTECTED] --- End of forwarded message from [EMAIL PROTECTED] From [EMAIL PROTECTED] Sun Sep 16 01:42:14 2001 X-Delivered: at request of sendmail on bugs Received: from zul.wakawaka.com (zul.wakawaka.com [192.148.188.5]) by bugs.wakawaka.com (8.8.8/8.8.5) with ESMTP id BAA11555 for [EMAIL PROTECTED]; Sun, 16 Sep 2001 01:42:14 -0700 (PDT) Received: from fencepost.gnu.org (fencepost.gnu.org [199.232.76.164]) by zul.wakawaka.com (8.8.8/8.8.5) with ESMTP id BAA07411 for [EMAIL PROTECTED]; Sun, 16 Sep 2001 01:46:33 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=fencepost.gnu.org) by fencepost.gnu.org with esmtp (Exim 3.22 #1 (Debian)) id 15iXGh-0007cp-00; Sun, 16 Sep 2001 04:27:11 -0400 Received: from zul.wakawaka.com ([205.219.70.4]) by fencepost.gnu.org with esmtp (Exim 3.22 #1 (Debian)) id 15iXEG-0007Se-00 for [EMAIL PROTECTED]; Sun, 16 Sep 2001 04:24:40 -0400 Received: from bugs.wakawaka.com (bugs.wakawaka.com [192.148.188.8]) by zul.wakawaka.com (8.8.8/8.8.5) with ESMTP id BAA07400 for [EMAIL PROTECTED]; Sun, 16 Sep 2001 01:24:38 -0700 (PDT) Received: from localhost (localhost [[UNIX: localhost]]) by bugs.wakawaka.com (8.8.8/8.8.5) id BAA11542 for [EMAIL PROTECTED]; Sun, 16 Sep 2001 01:20:53 -0700 (PDT) Message-Id: [EMAIL PROTECTED] From: [EMAIL PROTECTED] In-Reply-To: [EMAIL PROTECTED] X-Mailer: Mail User's Shell (7.2.6 beta(4)+dynamic 03/19/98) To: [EMAIL PROTECTED] Subject: Demo of extensible merge (was Re: giving up CVS) Sender: [EMAIL PROTECTED] Errors-To: [EMAIL PROTECTED] X-BeenThere: [EMAIL PROTECTED] X-Mailman-Version: 2.0.5 Precedence: bulk List-Help: mailto:[EMAIL PROTECTED] List-Post: mailto:[EMAIL PROTECTED] List-Subscribe: http://mail.gnu.org/mailman/listinfo/info-cvs, mailto:[EMAIL PROTECTED] 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] List-Archive: http://mail.gnu.org/pipermail/info-cvs/ Date: Sun, 16 Sep 2001 01:20:52 -0700 Status: OR --- Forwarded mail from Greg Woods: CVS is perfectly capable of supporting even unmergable file types with only minor changes to its logic, specifically by adding an extensible mechanism to select the correct merge tool for the data type at hand. So you seem to claim. So far though you've only proposed the most superficial of functional specifications, and certainly there's been no appearance of running code to cloud the issue I call your bluff and raise you a nickel... This is only true as long as CVS treats everything as text files. There is nothing holding us back from modifying CVS to accomodate non-text files in a meaningful way and still retain the concurrent development paradigm intact. Go for it. I look forward to seeing your Binary CVS edition in the very near future!
Re: CVS corrupts binary files ...
--- Greg A. Woods [EMAIL PROTECTED] wrote: [ On Saturday, June 5, 2004 at 13:01:48 (-0700), Adrian Constantin wrote: ] Subject: Re: CVS corrupts binary files ... I don't wanna merge binary files, Then your better tool is called a directory (i.e. outside of CVS) -- You can't be serious about this... My module is a web site. The directory structure is already created, with a several directories for images. They have their place on the web server, with already done aliases. Even if I don't edit binary files like source code, sometimes I may add or remove a few images ro/from my site. And in the future when the site is ready I might want to redesign it and change image files. If images are outside of cvs, they won't be delivered by cvs checkout. This is not exactly recomanded. And I think my binaries are conceptualy part of the project like source file are. Now maybe developing a web site with cvs is not very common. What if I have a real project with some custom libraries, ordered especially for the project. Theese are also binaries not likely to be merged or changed, but I don't see an outside directory as a good place for them Adrian Constantin And I don't wanna miss a thing __ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: CVS corrupts binary files ...
--- Forwarded mail from [EMAIL PROTECTED] [ On Saturday, June 5, 2004 at 20:52:06 (-0700), Paul Sander wrote: ] Subject: Re: CVS corrupts binary files ... Yeah, well, sending such hapless people away is easier than fixing the tool. The tool is not broken -- I.e. there's nothing to fix! CVS is designed _only_ for tracking changes in human written text files. So you say. I maintain that the diff and merge tools can be easily swapped out without making significant changes to the CVS design. With regard to merge tools, I proved my point with a patch posted to this forum on Sept. 16, 2001. I've included that patch at the bottom of this message. If you want to design (and implement) a new tool that does work well with non-text files then please do so. That'll give us yet another tool to recommend people use when they want to. No need. See the patch below. Demonstrating that such support could be added to CVS was done in less than eight man-hours; Nope -- it's just not possible, as you should well know. This is a fundamental and purposeful design limitation in CVS. The entire concept of concurrent editing, which is central to the design and goals of CVS, is completely antithetical to managing binary files. I don't believe it was a purposeful design limitation. CVS was initially designed before binary source formats were common, and it just didn't happen to include a plug-in method to support them. Keep in mind also that there's a difference between binary files and mergeable files. The two concepts are in fact orthogonal; there are mergeable binary types (given a suitable tool), and there are unmergeable text types. CVS is bad at storing unmergeable files, no matter whether or not they're binary files. CVS can be easily modified to support mergeable binary types, as I've demonstrated, without significant impact to its design. --- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: CVS corrupts binary files ...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Folks, Greg writes: CVS is designed _only_ for tracking changes in human written text files. Paul writes: Keep in mind also that there's a difference between binary files and mergeable files. The two concepts are in fact orthogonal; there are mergeable binary types (given a suitable tool), and there are unmergeable text types. CVS is bad at storing unmergeable files, no matter whether or not they're binary files. CVS can be easily modified to support mergeable binary types, as I've demonstrated, without significant impact to its design. In my view, CVS was designed to add a model of concurrent modification and automatic merges on top of the previously existing Revision Control System representation of files. The removal of exclusive locking for changes is the fundamental reason that CVS exists. It may be that the diff3 algorithm is not always the best one suited to do such mergers. For example, using a UTF16 character set in a file for example may prove to be difficult to merge even if the text in the file is only a simple Chinese representation. Perhaps something like the xcin project will eventually provide a diff3 for use in this case. It may be desirable to mark UTF8 or UTF16 files as being 'binary' in order to preserve the text more exactly across operating systems that are not (yet) friendly to such text. For this reason, I take Paul's side on the issue of the orthogonal nature of the discussion of files that may or may not be merged using automatic tooling of some sort. I also share Greg's bias that using CVS to save arbitrary binary data and/or derived objects is not something that is a core competence of CVS. For myself, I have no objection to a few small icons being checked into a repository that will also be holding sources that use them (of course, I would usually favor them being convereted into a text representation such as xbm format or the like). I have seen where using very large binary objects can cause problems for both users and administrators. I have also seen problems where folks checkin derived objects such as PostScript files that are pure text files, but normally are not merged effectively by a diff3 program during a normal 'cvs update' of a file. I believe that adding flexibility to CVS as to what program should be used in place of diff3 for doing a merge operation is desirable. That said, I do not know the correct approach to take for allowing the cvs admin or user do such a merge with a non-diff3 tool. Some such tools are (by their nature) interactive and this does not seem to be a good fit with the CVS methodology. Some such programs may only be available on client machines while others would potentially be available on the server. I typically favor that such programs would be consdiered to be present on the server and NOT on the client. The exact semantics and rules under which a substitution for a different program than diff3 could be used for a merge operation need to be carefully considered before we jump into a change. I suspect that we would need to add a filetype recognizer into cvs as a preliminary step to help to classify the type of a file that is to be merged (or added or imported for that matter) in order to know which of the potentially large number of three-way merge programs and scripts should be used or considered for use during a given cvs merge operation. I do not consider filetypes driven by the name of a file to be useful in such deliberations. If anyone has any suggestions or other patches for this kind of feature, I would be interested in hearing about them. -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFAxknf3x41pRYZE/gRAsQtAJ0bBnvfNdF+2aPUzb/fr6qEuAFJcQCgluGR 7HTwfoQL1NFRQeQGeLosGP8= =9laK -END PGP SIGNATURE- ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: CVS corrupts binary files ...
--- Forwarded mail from [EMAIL PROTECTED]
Greg writes:
CVS is designed _only_ for tracking changes in
human written text files.
Paul writes:
Keep in mind also that there's a difference
between binary files and mergeable files.
The two concepts are in fact orthogonal; there
are mergeable binary types (given a suitable
tool), and there are unmergeable text types. CVS
is bad at storing unmergeable files, no matter
whether or not they're binary files. CVS can be
easily modified to support mergeable binary
types, as I've demonstrated, without significant
impact to its design.
In my view, CVS was designed to add a model of
concurrent modification and automatic merges on
top of the previously existing Revision Control
System representation of files. The removal of
exclusive locking for changes is the fundamental
reason that CVS exists.
It may be that the diff3 algorithm is not always
the best one suited to do such mergers.=20
Well said.
However, I'm not 100% convinced that automatic merges
is a prerequisite of the concurrency model. I see no
reason why a command like cvs update could not spawn
a graphical merge tool (even for C source code, for
example). However, such actions, should they stall,
must not stop others from doing their own merges or
from committing new changes.
For example, using a UTF16 character set in a file
for example may prove to be difficult to merge
even if the text in the file is only a simple
Chinese representation. Perhaps something like
the xcin project will eventually provide a diff3
for use in this case.
It may be desirable to mark UTF8 or UTF16 files as
being 'binary' in order to preserve the text more
exactly across operating systems that are not
(yet) friendly to such text.
For this reason, I take Paul's side on the issue
of the orthogonal nature of the discussion of
files that may or may not be merged using
automatic tooling of some sort.
Thanks! :-)
I also share Greg's bias that using CVS to save
arbitrary binary data and/or derived objects is
not something that is a core competence of CVS.
Saving derived objects is definitely not a best practice
in SCM, at least not in the source control system. Whether
or not arbitrary (or opaque) binary data should or should
not be stored in CVS is a sticky question, because it may
very well be source code (i.e. data that can be created or
modified only by human intervention), in which case I
believe it should be stored in the source control system.
For merges, opaque data must be handled appropriately. One
way is to take Greg's approach and boot it out completely.
I believe a better way is to apply a simple selection tool
that takes the place of a merge tool. (After all, any data
type is mergeable if you can swap out the entire contents of
a file in one chunk, right? :-)
For myself, I have no objection to a few small
icons being checked into a repository that will
also be holding sources that use them (of course,
I would usually favor them being convereted into a
text representation such as xbm format or the
like). I have seen where using very large binary
objects can cause problems for both users and
administrators.
It's important to note that xbm format is also an unmergeable
data type, at least with diff3, even if such files do not
contain non-printable ASCII characters. The reason is that
it's hard to edit an image without seeing it as an image.
I agree about storing large binary files in CVS; it would be nice
if there were multiple storage managers to choose from, depending
on their suitability to the data at hand. But given that RCS
works (though admittedly not necessarily well) in all cases, it's
good enough (for 95%+ of the files thrown at it) that I don't see
a reason to change at this moment. ('Course, I'd be happy to
participate in a separate discussion about creating an abstraction
layer over RCS and plugging in other storage managers... :-)
I have also seen problems where folks checkin
derived objects such as PostScript files that are
pure text files, but normally are not merged
effectively by a diff3 program during a normal
'cvs update' of a file.
I believe that adding flexibility to CVS as to
what program should be used in place of diff3 for
doing a merge operation is desirable.
That said, I do not know the correct approach to
take for allowing the cvs admin or user do such a
merge with a non-diff3 tool. Some such tools are
(by their nature) interactive and this does not
seem to be a good fit with the CVS methodology.
I believe that the data type should be stored in a
newphrase in the admin section of the RCS file.
The bad thing about that is that if the RCS file is
recycled with a new data type, or if it contains
different data types on different branches, there
is no correct value for the newphrase.
Others have stated that the data type should be
stored with each version of the file. That way
you can tell when a nonsensical merge is attempted.
But then the data type must be
