Re: address@hidden: Re: rename in cvs]

[Kaz Kylheku]

In article <address@hidden>, Greg A. Woods wrote:
>[ On Saturday, October 13, 2001 at 01:23:14 (GMT), Kaz Kylheku wrote: ]
>> Subject: Re: address@hidden: 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.