In article <[EMAIL PROTECTED]>, Greg A. Woods wrote: >[ On Saturday, October 13, 2001 at 01:23:14 (GMT), Kaz Kylheku wrote: ] >> Subject: Re: [[EMAIL PROTECTED]: Re: rename in cvs] >> >> The problem is, I wouldn't hold my breath. > >You'll certainly turn blue if you try. > >CVS cannot easily ever support renaming to any extent that something >like BitKeeper or Perforce does, at least not without breaking backwards >compatabilty of the repository structure. > >There's simply no place to put the extra meta data necessary except in >the commit comments themselves, and you can much more easily build >simple little wrapper scripts to do renaming and to drive "cvs log", >"cvs diff", "cvs annotate", and "cvs update" if that's all you're going >to do. I've already started the ball rolling, yet again, by posting yet >another version of the first such wrapper needed.
You're working on this too? I'm going through the design stages of a full blown CVS front end called Meta CVS. The idea is that all you store in CVS is a flat database of files that have completely cryptic, machine-generated names. Along with that, you store a mapping which assigns path names to these objects. On checkout, Meta CVS obtains a sandbox, and then processes the mapping file to create the tree. When you do updates, Meta CVS calculates the difference between the old mapping file and the new (after the user resolves any conflicts) and then rearranges your tree accordingly. If you want to move something, you do it thorugh Meta CVS. It updates its working copy of the mapping file and performs the move. You can then commit to ``make it so''. If the up-to-date check fails on the mapping file, you update, and resolve the conflict. Meta CVS will then move local files around as necessary to reflect your resolution, always keeping a prior version of the mapping file stashed somewhere to determine what rearrangements must be done. I'm thinking of also post-filtering the output of certain cvs commands like rdiff and log. For example, the output of rdiff could be edited to replace the machine-generated names with the mapped pathnames. Not only that, but a POSIX shell script could be prepended or appended to the output, containing mv commands. The idea is that someone with an old version of a tree could execute the renaming script, and then apply the rest of the patch to get to the new version of the tree. Thereby the powers of patch would be effectively extended to doing renaming and directory reshaping. Another idea I have is to implement a whole new tagging system. The project contains a special tag file. When you create a tag with Meta CVS, it adds an entry into the tag file and commits. The entry contains the tag name, and a list of files and their versions. So instead of rewriting every darn tagged file, the baseline information is recorded in one place, so tagging is much cheaper. Moreover, the tag store is itself versioned, so you know when the tag was created and can attach a comment to a tag creation or deletion. Meta CVS can checkout or update to a selected tag by individually pulling out the right revision of each file; an optional patch can be provided for CVS to make this expressible in a single CVS command. _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
