>--- Forwarded mail from Greg Woods: >[ On Sunday, October 14, 2001 at 01:49:56 (-0700), Paul Sander wrote: ] >> Subject: Re: [[EMAIL PROTECTED]: Re: rename in cvs] >> >> Assuming that some kind of rename capability is built into CVS that >> stores additional metadata in the repository, then THAT version of >> CVS would become the standard. And presumably, the new standard CVS >> would also provide a means to at least examine and perhaps modify >> the new metadata.
>That's not how the real world works, and you should know that by now. Which part? The part that each shop adopts one version of its tools at a time (and that that version is fairly up to date), or the part that tools provide access to their meta-data? Everyone I know goes to great effort to use just one (recent) version of the tools that provide their process infrastructure. The tools usually provide some kind of access to examine their data, and the good ones provide admin functions to modify them, usually in the name of error recovery after corruptions. This does not necessarily mean that the format of the file is published, only that the data can be read and modified in a correct and coherent way. >> As for RCS, who cares? >Excuse me? Everyone _should_ care, and I for one certainly care an >incredible amount. I was only placated into accepting the integration >of RCS management inernally to CVS because it meant there could be an >incredible boost of performance in some circumstances (eg. those where >multiple external operations were previously required). I still worry >about the differences in implementation and the supposedly innocuous >differences in resulting RCS file contents. If I'd had the time I would >have contributed code and tests to ensure that CVS produced ,v files >indistinuishable in every way from those produced by doing the same >operations with plain RCS. Maybe someday someone will still get around >to doing this. Why are you so concerned about CVS internal format? Do you do stuff to the repository outside of CVS? If you do, then shame on you; best practice is to use CVS' interfaces exclusively. >The fact that CVS is simply a wrapper for RCS (even if only conceptually >now) is one of its major features! The fact that CVS used RCS is an artifact of its implementation. At the time that CVS was designed, the authors needed a tool that did text deltas, and RCS was the only one freely available at the time that was stable enough to use. CVS continues to use the RCS file format to keep itself compatible with existing repositories. And there is precedent for adding new metadata; CVS did not always track "dead" versions, and the fact that the version "state" attribute is used now has the possibility of causing grief in cases where the RCS files are maintained by two different systems. >(and it's not just because you can >move RCS projects easily into CVS -- but also the other way around, and >not just back to plain RCS, but to other tools that might use RCS as an >underlying repository structure) Even if some new metadata are adopted, both transfers will continue to work as well as they do today. The ,v files copied into a CVS repository will still be compatible with CVS. The fact that the pointers that implement a rename capability will be absent just means that no renames have been done. As for going the other way, tools that read RCS files will still have the same data they get today. They'll also get more that they won't know what to do with. If they were implemented according to the RCS standard then they should ignore the CVS metadata, or perhaps set some kind of attribute and carry it in without interpretation. If the tool breaks, then report it as a bug or write a filter to remove the CVS meta-data. >> And if for some reason someone >> really does need to read the contents of the CVS repository using >> RCS, perhaps as a means to converting to something else, who cares? >Anyone with any long-term investment in CVS _should_ care. If CVS provides interfaces to all of the metadata it uses that are stored in the RCS files, and users do not have direct access to the CVS repository, then why would they care that the repository is in RCS format? It's just an implementation detail that's hidden from them. (Well, "cvs status" hints at RCS files that are somehow related to the sandbox, but again the user has no access to it anyway.) >> RCS can still process the stuff it knows about. >Of course -- that's the problem because the new, and in this case >incredibly important, metadata is effectively hidden from its view. It's only important for features that fall outside of RCS' pervue. RCS still operates just fine on what it understands. If the new metadata are important to you, then use the tool that manages it: CVS. >> Whatever process >> lives outside of RCS will be ignorant about the new metadata and >> won't use it anyway. >Of course -- and that wouldn't be as big a problem if it didn't affect >the fundamental structure of the repository. >(or perhaps you don't care about the renamed files when you go to >recover your CVS repo and/or convert it to some other format?) Recover the CVS repo... That suggests that I should have good backups. I do, and so should everybody else. If by "recover" you mean to repair corruptions in the absence of a suitable backup, then certainly this adds to the complexity. But it's not much more difficult than recovering dead versions and deciding the properly location of the RCS files (i.e. whether or not the RCS files belongs in the Attic or not). As for converting to some other format, the conversion is imperfect as it is. Companies that provide tools to convert from CVS to their format will need to update their tools. In any case, CVS has not traditionally provided tools to assist with conversions to competing systems. >yes CVS won't go away or be unusable in the same way that could happen >to commercial software, but that doesn't change the fact that RC Sorry? That sentence was garbled. Would you repeat your point, please? >> (If someone uses RCS to modify the repository, >> then it's certainly possible to get the new metadata wrong. But >> again, who cares? CVS repositories should be modified only by CVS >> anyway.) >That's where you're going wrong in your thinking here I think. >Yes during production CVS repositories should only be modified by CVS. >However that's not the only concern of anyone with an investment in a >CVS repository. Would you name a few concerns that people may have, other than having complete access to all of CVS' metadata via CVS' interfaces, and IT concerns (i.e. keeping the repository's filesystem robust, without concerns for the internal format of the files)? >--- End of forwarded message from [EMAIL PROTECTED] _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
