How can I view files with a specific tag in CVS?
Hi! Anyone knows if there is a CVS command that can be used to see which files (and their version) that has been tagged with a specific tag? If I do "cvs status -v" I get a lot of info on every file, including *all* tags. I guess I could write a script that extracs file name with tag, using awk/nawk/grep etc. But does it have to be that complicated? Rgds Peter ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Merge Confusion
Ok, Based on 2 emails from this list, the CVS manual, and the Essential CVS book, I'm confused about the whole merge what tag where stuff. I hope I craft this email to get a clear answer to unfog my head. Project Name: testproj Local Sandbox is: rel_1/testproj while in local sandbox, issued cvs tag rel_1-before-branch then issued cvs tag -r rel_1-before-branch -b rel_1 then issued cvs tag rel_2_start Still in the rel_1/testproj sandbox I issue the the cvs update -r rel_1 command. This now updates the rel_1/testproj sandbox to contain the branch. I then backup a couple of directories and create a new directory called rel_2 and issue the command cvs checkout testproj (this then creates a local sandbox rel_2/testproj that contains the trunk. Now, I make bug fixes to rel_1/testproj and want to merge these changes into rel_2/testproj. The files in rel_1/testproj contain a mix of added, modified, and deleted lines. At this point, I'm not overly concerned about deleted or added files (to me they are much easier to deal with since the entire file is involved). I go into the rel_1/testproj sandbox and issue the following commands: make sure i have the latest sources - cvs -q up -dP tag the repository - cvs tag rel_1-20040630 I go into the rel_2/testproj sandbox and issue the following commands: make sure i have the latest srouces - cvs -q up -dP tag the repository - cvs tag rel_2-20040630 Now I'm ready to merge. Since I want to merge from the branch into the trunk, I'll be in the rel_2/testproj sandbox. Which command do I issue? 1 - cvs up -j rel_1-20040630 -j rel_2-20040630 2 - cvs up -j rel_2-20040630 -j rel_1-20040630 3 - cvs up -j rel_1 -j rel_1-20040630 4 - cvs up -j rel_2 -j rel_1-20040630 5 - cvs up -j rel_1-20040630 -j rel_1 6 - cvs up -j rel_1-20040630 -j rel_2 7 - cvs up -j rel_1-20040630 8 - cvs up -j rel_1 -j rel_2-20040630 9 - cvs up -j rel_2 -j rel_2-20040630 10 - cvs up -j rel_2-20040630 -j rel_1 11 - cvs up -j rel_2-20040630 -j rel_2 or something completely different? This looks something like a quiz, but I'm not the teacher, I'm just a horribly confused student and really don't want to screw up 10,000+ files that are under cvs control. I need all changes from the rel_1 environment to be merged into the rel_2 environment. I understand that after the merge, I'll have to resolve any conflicts and merge the files back into the respository from the local sandbox. I'm trying to follow the basically unstable philosophy with a long branch merging to the trunk. TIA, Rick Feldmann [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
RE: How can I view files with a specific tag in CVS?
[EMAIL PROTECTED] wrote: > Anyone knows if there is a CVS command that can be used to > see which files (and their version) that has been tagged with > a specific tag? cvs -nq up -r tag-you-are-interested-in -- 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
CVS tags
I have tags assigned to some of my files in the repository to mark them for something different. Now if one of these files is updated and committed, how do I get the tag on the latest version? Or get rid of it from the old and add it to new? Thanks Khyati___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
RE: Merge Confusion
work wrote: [snip details] > while in local sandbox, issued cvs tag rel_1-before-branch > then issued cvs tag -r rel_1-before-branch -b rel_1 > then issued cvs tag rel_2_start [...] > I go into the rel_1/testproj sandbox and issue the following > commands: > > make sure i have the latest sources - cvs -q up -dP Excellent - people sometimes forget this important step > tag the repository - cvs tag rel_1-20040630 > I go into the rel_2/testproj sandbox and issue the following > commands: > tag the repository - cvs tag rel_2-20040630 > > Now I'm ready to merge. Since I want to merge from the > branch into the > trunk, I'll be in the rel_2/testproj sandbox. Which command > do I issue? Remember that, unless you are doing something extremely unusual, both tags in the update command should be on the same branch. This eliminates any of your options involving tags on the trunk, leaving only: > 3 - cvs up -j rel_1 -j rel_1-20040630 > 5 - cvs up -j rel_1-20040630 -j rel_1 > 7 - cvs up -j rel_1-20040630 'cvs update -jX -jY' says "take the delta from X to Y and apply it to the current directory". Now, because you applied the tag rel_1-20040630 to the tip of rel_1 branch, that means rel_1 and rel_1-20040630 refer to the same revision (unless somebody checks something into the branch while you're doing this, but we'll leave that aside for now). This means that 3 and 5 are no-ops: there is no difference to apply. This leaves option 7. In this particular case, it will work. With only one -j option specified, CVS will automatically determine the correct base point to use. CVS will act as if you had issued the command: cvs up -r rel_1-before-branch -j rel_1-20040630 As I said, *in this case* it will work. In subesequent merges, it will not work: you must explicitly specify the starting point, otherwise CVS will again use the common ancestor as the starting revision, and you'll get the same changes merged twice. Thats why I prefer to always use both -j options when merging. > At this point, I'm not overly > concerned about > deleted or added files (to me they are much easier to deal > with since the > entire file is involved). You will have to use 'cvs add' and 'cvs remove' to have these files added or removed from the trunk. > This looks something like a quiz, but I'm not the teacher, I'm just a > horribly confused student and really don't want to screw up > 10,000+ files > that are under cvs control. For these situations, you can always set up a test portion of the repository. Create a directory, say $CVSROOT/cvs-test, and try it out there. The understanding is that anything in cvs-test can be deleted without warning, and nothing of value should go in there. Also, remember that even if you mess up on some of the commands, nothing gets committed until you issue the "cvs commit" command. So, if worse comes to worst and you've really mucked it up, just blow away your working copy, check out a fresh copy and try again. Happy merging ;) -- 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: CVS tags
Khyati Nayak wrote: > I have tags assigned to some of my files in the repository to > mark them for something different. Now if one of these files > is updated and committed, how do I get the tag on the latest > version? Or get rid of it from the old and add it to new? Use the -F option. -- 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: Merge Confusion
"work" <[EMAIL PROTECTED]> writes: > Ok, Based on 2 emails from this list, the CVS manual, and the Essential CVS > book, I'm confused about the whole merge what tag where stuff. I hope I craft > this email to get a clear answer to unfog my head. Project Name: testproj > Local Sandbox is: rel_1/testproj while in local sandbox, issued cvs tag > rel_1-before-branch > > then issued cvs tag -r rel_1-before-branch -b rel_1 > then issued cvs tag rel_2_start Still in the rel_1/testproj sandbox I issue > the the cvs update -r rel_1 command. This now updates the rel_1/testproj > sandbox to contain the branch. I then backup a couple of directories and > create a new directory called rel_2 and issue the command cvs checkout > testproj (this then creates a local sandbox rel_2/testproj that contains the > trunk. Now, I make bug fixes to rel_1/testproj and want to merge these changes > into rel_2/testproj. The files in rel_1/testproj contain a mix of added, > modified, and deleted lines. At this point, I'm not overly concerned about > deleted or added files (to me they are much easier to deal with since the > entire file is involved). I go into the rel_1/testproj sandbox and issue the > following commands: make sure i have the latest sources - cvs -q up -dP > > tag the repository - cvs tag rel_1-20040630 I go into the rel_2/testproj > sandbox and issue the following commands: make sure i have the latest srouces > - cvs -q up -dP > > tag the repository - cvs tag rel_2-20040630 Now I'm ready to merge. Since I > want to merge from the branch into the trunk, I'll be in the rel_2/testproj > sandbox. Which command do I issue? Well, I didn't find a correct one in the list you've provided, so here is how I would do it: All you've made so far is OK, but I'd add one more tag that marks the last revision on the branch you've merged up to so far. For now, set it to the root of the branch as we didn't merge anything yet: $ cvs rtag -F rel_1-merge -r rel_1-before-branch testproj (maybe rel_1-last-merge is even better name for the tag) Then, the merge itself would be: 1. Tag current branch state with rel_1-tmp tag. $ cd ~/rel_1/testproj $ cvs update -d -P ... make sure you have no local changes ... $ cvs tag -F rel_1-tmp 2. Merge changes between rel_1-merge and rel_1-tmp into rel_2: $ cd ~/rel_2/testproj: $ cvs update -d -P ... make sure you have no local changes ... $ cvs update -d -P -j rel_1-merge -j rel_1-tmp 3. Resolve conflicts, commit changes back. 4. Move the rel_1-merge tag to the rel_1-tmp tag to record the point in the branch for the next merge: $ cvs rtag -F rel_1-merge -r rel_1-tmp testproj That's it. Rather simple in fact. Please note that all this business with rel_1-tmp tag is there to prevent troubles when some other developer commits something on the branch after you've invoked merge command but before you've moved the rel_1-merge tag. In your particular case, rel_1-tmp is the same as your rel_1-20040630, so you can substitute the former by the latter in the last two commands above. However, for me it seems easier to remember how to merge when involved tags are always called the same for given branch. This way every next merge of changes made on the rel_1 branch will look exactly the same. -- Sergei. ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: listing new files in a local directory
[EMAIL PROTECTED] (John Hanny) writes: > I'd like a cvs command that tells me what files in the current > directory are new. One hack that I've been using is "cvs update." The > files that are prefixed by '?' are new. Unfortunately, this has the > side-effect of updating my local directory files if they have been > changed in the repository. Is there another way to do what I need to > do without causing the udpates? The local "cvsdelta" utility is useful if you want to avoid a slow connection to the repository for cvs -n update http://www.gnu.org/directory/cvsdelta.html -- Brian Gough Network Theory Ltd, Publishing the CVS Reference Manual --- http://www.network-theory.co.uk/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Merge Confusion
"Jim.Hyslop" <[EMAIL PROTECTED]> writes: > work wrote: [...] > > At this point, I'm not overly concerned about deleted or added files > > (to me they are much easier to deal with since the entire file is > > involved). > You will have to use 'cvs add' and 'cvs remove' to have these files added or > removed from the trunk. I don't think he will. At least for me it works automatically. I mean all the files are already added/removed after the merging command has been executed, so I only need to commit (after resolving conflicts, if any). -- Sergei. ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Merge Confusion
Jim.Hyslop writes [re merging]: > > You will have to use 'cvs add' and 'cvs remove' to have these files added or > removed from the trunk. Not so -- a merge with two -j options should handle that automatically. -Larry Jones What a stupid world. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
RE: Merge Confusion
Sergei Organov wrote: > "Jim.Hyslop" <[EMAIL PROTECTED]> writes: > > You will have to use 'cvs add' and 'cvs remove' to have these files > > added or removed from the trunk. > > I don't think he will. At least for me it works > automatically. I mean all the files are already added/removed > after the merging command has been executed, so I only need > to commit (after resolving conflicts, if any). Good thing you and Larry are here to keep me honest ;-) Sorry about the misinformation, Rick. -- 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: CVS corrupts binary files ...
[ On Monday, June 28, 2004 at 18:31:58 (-0700), Paul Sander wrote: ] > Subject: RE: CVS corrupts binary files ... > > On three separate occasions, Greg actually *recommends* intalling and > treating such code drops as uncontrolled sources! Paul, please stop mirepresenting what I have said. (A) they're not "sources" -- they're intermediate product files. (B) installing third-party intermediate files on the build systems doesn't mean they are "uncontrolled" -- only in _your_ mind could that be true. > Dropping stuff in > a directory and pointing makefiles at it is just plain bad CM. Indeed it would be, if that was all one did. Let me repeat again since you obviously don't grasp the full and deep meaning of this statement: CVS is _NOT_ a _complete_ software configuration management system. Obviosly anyone interested in good SCM will have external procedures to account for these third-party files, just as they should have procedures for dealing with _all_ attributes of their build environment. > (Well, that last statement has limits in practicality; there's a break- > even point where the the benefit of automation exceeds the cost of > automation, but that point is usually relatively low, especially in the > CM domain.) Exactly. You've been riding your high horse for so long now that you're clearly having troubles dealing with real-world issues. -- 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: Smoke, FUD (was Re: CVS corrupts binary files ...)
[ On Monday, June 28, 2004 at 19:02:19 (-0700), Paul Sander wrote: ] > Subject: Re: Smoke, FUD (was Re: CVS corrupts binary files ...) > > I have never, ever advocated changing the format of an RCS file in a > way that would break the ci, co, rcs, or rlog programs. And although > I strongly advocate the replacement of user-exposed diff and merge > tools, I have never, ever advocated the replacement of the diff tool > that computes the deltas stored in an RCS file. Indeed -- instead you would rather use different algorithms for storing deltas and for using them. That would be just plain stupid, if indeed not eventually dangerous to the integrity of a repository. The tools we now have for calculating and handling deltas are all designed to work _together_, not in isolation of each other, and that uniformity is as valuable to CVS as it is to RCS alone, if not more so. How about you go off and spend the next, say, two years or so intensively using such a scheme as you propose on a massively huge variety of projects. That should give you about 10% of the experience the rest of the world has with using diff and diff3 and rcsmerge uniformly for both purposes. Then if you still think it's wise to use disparate techniques for storing deltas and for using deltas then you can show your results and raise your proposal here again. In the mean time please keep in mind that there are not just a plethora of tools for using diff-style deltas, but there's also an enormous amount of human experience with them too. You (and a few others) seem to want to throw the baby out with the bath water, and all just so that a few hair-brained and lame mis-uses of CVS will work "better". In the mean time if you (and others) had learned to use the best tool for the job in the first place then you'd never have had to dream up such a half-baked idea. -- 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
User name on commit is not what I want
Whenever a module is checked in, the username is whoever did the commit. I want the user to always be cvs:cvs. I know there is a way to do this -- something in the passwd file I think -- but I cannot find it in the manual. I use cvs 1.11.1p1 witjh both :pserver: and :ext: connections -- Stephen Carville Unix and Network Adminstrator DPSI 6033 W.Century Blvd. Los Angeles, CA 90045 310-342-3602 ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Smoke, FUD (was Re: CVS corrupts binary files ...)
[ On Tuesday, June 29, 2004 at 02:18:26 (-0700), Paul Sander wrote: ] > Subject: Re: Smoke, FUD (was Re: CVS corrupts binary files ...) > > >I.e. How do you propose to make it possible for the standard RCS tools > >alone to re-create _every_ revision from all files created by this > >hacked system? > > Simple: The delta text would not change. See above. It would be extremely short-sighted, if not downright stupid, to not keep the delta format compatible with that used by the new delta tools. You seem to have no appreciation whatsoever for the depth and breath to which this format (and its easily computed variants) is used and understood. -- 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: Smoke, FUD (was Re: CVS corrupts binary files ...)
[ On Monday, June 28, 2004 at 14:58:03 (-0700), Mark D. Baushke wrote: ] > Subject: Re: Smoke, FUD (was Re: CVS corrupts binary files ...) > > Yes, but diff is not diff3. diff is used for the > delta format. diff3 is used by rcsmerge, not for > fundamental version deltas. I think you're confused -- the differencing algorithms used are fudamentally intertwined (and fundamentally based on units of lines of text). Pretending you can do merges using some other algorithm while still trying to store your deltas in unix diff format is just leading everyone down the garden path to a dark dank corner no-one really wants to be in. The uniform use of differencing algorithms and their corresponding merge algorithms (which are of course just "editing" scripts), is what makes it worthwhile to use something like RCS as the foundation for CVS in the first place. I.e. it is not sufficient to just use the RCS delta format as a means of archive compression -- that format is integral to the whole idea of detecting, reporting, and merging, changes in any RCS-compatible tool. > Are there really utilities out there that try to > to read RCS formats directly and do not allow for > rcsfile(5) syntax to be used? If so, could you > name any of them? Humans, for one. :-) (I know some folks can do manual merges of SCCS files, and though the same techniques won't work quite so well on RCS files because of the reverse delta thing, there are still a great many other valid reasons to read and even repair RCS files by hand.) There are a number of commercial software pacakges which are "GNU RCS compatible", apparently without using RCS source code, with the most "popular" perhaps being CS-RCS (though I've not confirmed 100% that it does not use RCS source code). SourceCodeManager is apparently another, and P4D yet another. Perforce also uses RCS compatible files as its archive format, but I'm not sure if its core RCS handling was derived from RCS source code or not. I think I've just scratched the surface too, if any of the rumours I've heard are close to true. -- 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: Project in a cvs, library in another
[ On Monday, June 21, 2004 at 17:50:49 (-0500), Ababccc wrote: ] > Subject: Project in a cvs, library in another > > I'm wondering what people usually do, in case there is a project on CVS > which uses a C++ library which is in a completely separated CVS. > > If the library gets changed (for its own purposes) the project might get > screwed... CVS is not a complete software configuration mangagement system. You'd do best to keep your management of third party libraries (and tools and other such things) separate from the management of your source code itself and to then use some additional procedures or processes to integrate these components into your final software products. -- 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 Tuesday, June 29, 2004 at 19:34:25 (-0700), Paul Sander wrote: ] > Subject: RE: CVS corrupts binary files ... > > When you speak about how great NASA is and mention the antiquity of some > of their processes, remember that the paper checklists have since > contributed to the failure of several missions (some of which missed > entire planets) and the loss of 14 lives. Have you not read the investigation reports on all those incidents? The concept of using "paper checklists" as part of their process did not contributed in any way to those failures. Indeed their ability to investigate those incidents is in no small part aided by the existance of those paper checklists. > NetBSD is awesome! Of course -- that's why I've come to use it almost exclusively. ;-) > But keep in mind that the reason they can do what they do is that they > literally own the entire environment, from the OS and system libraries > on up. Well, Duh! That's the whole point here! If you want to control your software development process from top to bottom then you must "own" the whole environment -- from the build environment and tools and such through to all directly included components of the system. > Yes, they have to build cross environments, but after they've > built the cross compiler twice the runtime environment of the build > system really doesn't matter as long it can schedule CPU time and access > files. Most of us don't have that luxury. You create the situations you yourself must live with. NetBSD is only interesting in this respect because the whole project, and indeed multiple working branches of it, can be checked out entirely from one big CVS repository. (keeping in mind that the manual rules for developers dealing with that repository are not exactly trivial, especially in the special-case situations I mentioned) In fact in in all successful development environments for critical software, and most for embedded software, that I've ever encountered there's a similar level of "ownership" over all tools and components -- however it's extremely rare to find anyone using CVS as exclusively as NetBSD is able to do (unless they are also using NetBSD :-), partly because few groups are willing to live under the restrictions this causes (it's far easier to use a manual checklist to ensure the right versions of all the right tools and third-party components is installed on a build system). (So far it's been the unsuccessful, or struggling, development groups I've encountered who have been the ones who have failied to take "ownership" over all their software components.) -- 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: binary files bad idea? why?
I want to play with the diff & patch tools a bit myself just to see if I could see something go wrong with CVS and binary files if those files were run through something that would binhex them (similar to uuencoding) via a CVS wrapper. Everything seemed to work as I expected. If I understand what CVS does, when to check in a file, it does a diff with the previous version and stores that diff. To do the comparison, it must also use the patch tool. So, I took two very different binary files (well a mix of binary and text files in a special folder under MacOSX called a NIB) and binhexed them. I then did: diff -u filea.hqx fileb.hqx > difference.txt I then did: patch filea.hqx difference.txt and the resulting file was equivalent to fileb.hqx. So, I'm sorry...what can go wrong here? If diff, patch and a binhex tool are the only tools which CVS requires when dealing with binary files, I don't see the problem as long as I never compare the differences between filea.hqx and fileb.hqx and select which ones to keep and which ones to throw away. ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
"inflate: unknown compression method" after server upgrade to 1.11.16
When I use a client which inserts the global '-l' option together with my newly upgraded server, I get the expected "global `-l' option ignored" warning. However, if I also specify a compression level, I get the following: [EMAIL PROTECTED] tools] cvs -nq -z1 up cvs update: inflate: unknown compression method cvs [update aborted]: reading from server: Input/output error Server: cvs 1.11.16 RedHat 7.2 Client: cvs 1.11.1p1 RedHat 7.2 Note that I have many clients deployed, so I'd like to understand the problem (not just deploy newer clients). Thanks, David Please respond to this newsgroup, not my e-mail address. ___ 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 Monday, June 28, 2004 at 18:31:58 (-0700), Paul Sander wrote: ] >> Subject: RE: CVS corrupts binary files ... >> >> On three separate occasions, Greg actually *recommends* intalling and >> treating such code drops as uncontrolled sources! >Paul, please stop mirepresenting what I have said. >(A) they're not "sources" -- they're intermediate product files. They're not "intermediate product files" unless they can be reproduced from some other source using an established process. The code drops we're discussing come from outside and are the definitive *sources* of the data that they contain, and can't change (or be recovered if lost) without human intervention. By definition, they are source files. >(B) installing third-party intermediate files on the build systems >doesn't mean they are "uncontrolled" -- only in _your_ mind could >that be true. They are, if there's no control over them. Simply installing them is not controlling them. If you can't control them, then you must remember all aspects that you can measure. If you don't then something will break as a result an uncontrolled change being introduced, and the problem will be potentially very hard to detect, correct, and prevent in the future. >> Dropping stuff in >> a directory and pointing makefiles at it is just plain bad CM. >Indeed it would be, if that was all one did. In all of the articles posted so far on this thread, you have suggested nothing more. What do you have in mind, in addition to what you've said? >Let me repeat again since you obviously don't grasp the full and deep >meaning of this statement: CVS is _NOT_ a _complete_ software >configuration management system. READ MY KEYS: I agree that CVS is not a complete software configuration system. In the very message that you snipped above, I listed a number of things that must be done with files like this, starting with a tuning/build/installation/deployment method that itself undergoes good CM. CVS is used only for the version control part, archiving the incoming sources and providing a convenient extraction method that happens to be the same one that tracks all other sources in the product. >Obviosly anyone interested in good SCM will have external procedures to >account for these third-party files, just as they should have procedures >for dealing with _all_ attributes of their build environment. Cool. We agree on something. It's good when you say what you mean. >--- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
