Re: renames under CVS

[Kaz Kylheku]

In article <address@hidden>, Noel Yap wrote:
>--- Kaz Kylheku <address@hidden> wrote:
>> Before I published Meta-CVS 0.0, I had already
>> renamed a bunch of
>> files in its own source code.
>
>Do you think Meta-CVS can be made part of CVS proper?

Everything has its place; to Meta-CVS, CVS provides the features of a
database with versioned elements. I don't see any need to integrate
the two.  That would probably cause more problems than it would solve.

It would be nice to have better interfaces to some things in CVS, that
are not exposed in the right way at the command line level.  I don't
mean bypassing the command line, just having some alternate syntax.

For example, when Meta-CVS adds a whole dumpload of files, Meta-CVS
the latest version identifies their types, and allows the user
to interactively specify the keyword expansion mode for each one.
The problem is that the underlying cvs add cannot handle that, it takes
one -k parameter, followed by a list of files which all share that same
one. (Of courwse there is .cvswrappers, but that's besides the point). So
the program simply categorizes the files into buckets according to their
expansion mode and generates as many cvs add commands as necessary to
get the files in.  A different interface would allow it to be done in
one operation.  No big deal, really, at least not in this example.

If ever I want to store tags in a separate metafile, it would
turn into a problem. For instance, updating to such a tag would involve 
invoking a separate update command for each unique file version number
because update takes only one -r and a list of files. You can't
cvs update -r 1.1 this.c -r 1.14 that.c and so on. The problem is that
issuing update commands separately over the network is inefficient.
It would work in principle, but users would probably hate it. :)

-- 
Meta-CVS: version control with directory structure versioning over top of CVS.
http://users.footprints.net/~kaz/mcvs.html