Harvey J. Stein wrote :
|| [EMAIL PROTECTED] writes:
||
|| > Let's take a break from the regularly scheduled passive-agressive
|| > flamefest and think about an imaginary Versioning System (iVS)
|| > that meets the features that are being talked about. Here's the
|| > first thought off the top of my head:
|| >
|| > 1) Use some kind of MIME file-type mapping to control settings
|| > for locking/concurrency (so that your source files are controlled
|| > concurrently but images use hard locks)
|| >
|| > 2) Use similar by-file-type mappings to controll the diff and
|| > sync algorithms used (standard text diff for ascii or unicode,
|| > something like Xdelta for your PNGs)
|| >
|| > Such a system could be configured to behave no differently than
|| > the current CVS, or it could be configured to always require
|| > hard locks, or something in between.
|| >
|| > I suppose you could set the mappings by project subdirectory too,
|| > in case you wanted specialized control somewhere.
|| >
|| > Ok, everybody tell me why this can't be done or why I'm talking
|| > to the wrong list.
||
|| If images are using hard locks, why should you diff them? For what
|| purpose?
Presumably the configuration file that mapped the file type into
diff/sync/access_method would choose an appropriate combination. If
the diff/sync mechanisms are capable of merging, concurrent access
would be used; if all they were capable of was detecting conflict but
not resolving it, locking access would be used. The person setting
up the configuration could decide whether the "locking" access to be
used at that site would be enforced exclusive locking or advisory
notification, and whether concurrent update would require advisory
notification (default to read-only until a "cvs edit" has been done)
or not (files always checked out as read-write).
--
Anyone who can't laugh at himself is not | John Macdonald
taking life seriously enough -- Larry Wall | [EMAIL PROTECTED]
