At 15:47 -0400 9/25/01, Greg A. Woods wrote:
>There's no way to handle _any_ file attribute change tracking without
>extending the RCS file format. Period. Take it up with the RCS
>maintainers if you want to do something productive about it.
Suppose that along with the foo,v files in the repository, there were
foo,w files that defined extended behavior for CVS to apply to the
foo file. If the foo,w file does not exist, then the usual CVS
semantics applies. If the foo,w file does exist, then it contains
some description (in XML or whatever) of extended behavior that gets
applied before or after the standard operations. The extra operations
could even be performed by an external program that CVS simply
invokes the correct (platform dependent) way.
Design is needed. Some mechanism would have to be implemented to
manage the contents of foo,w. CVS would have to read the foo,w file
at the appropriate times to take the correct actions. Some actions
may not be effective on different client platforms, but the
repository maintainer would be responsible for sorting that out. The
client-server protocol would need to be extended to send some subset
of the foo,w file contents to the client for each CVS operation. The
number of files in the repository would increase, but only for files
that need more than the standard CVS semantics. You can even imagine
an optimization (similar to $CVSROOT/cvsignore) that can minimize the
number of extra files.
It seems like this could be a reasonable way to extend CVS' behavior
in ways that many people have been asking for without violating the
RCS file format. It could perhaps replace the broken cvswrapers
mechanism as well as specifying file metadata (permissions, owners,
...) and even alternative diff/merge mechanisms.
Would this be a reasonable compromise (use config.h to enable the
extensions) between the "RCS is inviolate" and the "CVS needs more
semantics" crowds? Can this be added to CVS without doing major
damage to the overall architecture? Are there any show-stoppers here
(other than lack of people to do the work)? Can this be discussed
without flames from those two camps?
Fred
--
Fred Brehm, Sarnoff Corporation, [EMAIL PROTECTED]
_______________________________________________
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
