info-cvs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Extending CVS without breaking RCS ,v files


From: Frederic Brehm
Subject: Extending CVS without breaking RCS ,v files
Date: Tue, 25 Sep 2001 17:58:01 -0400

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, address@hidden



reply via email to

[Prev in Thread] Current Thread [Next in Thread]