Re: Proposal to fix CVS binary file implementation

[Derek R. Price]

Paul Sander wrote:

> >--- Forwarded mail from address@hidden
>
> >Paul Sander wrote:
>
> >> Oh yeah, there's that problem where different versions might contain
> >> different types of data.  Again, files containing different types of
> >> data should have different version histories.  Unfortunately, CVS in
> >> its current form requires a unique mapping between version histories
> >> and working files, so people use it improperly because they have no
> >> alternative that meets more pressing requirements.
>
> >There is the example of, say, GIF to JPEG.  That could be considered 
> >mergable with
> >a proper tool.
>
> In that case, create a generic "graphic" type that you can use to store
> either GIF or JPEG images, and invoke the proper merge tool.

You'd get more flexibility from the system that allows arbitrary data types.  
Then a
plugin or an application can register with merge types it can handle.  e.g. 
"GIF,
JPEG", "GIF, GIF", & "BMP, GIF", ... (of course a more succinct syntax is 
probably
desireable, e.g. "[GIF,JPEG,BMP],[GIF,JPEG,BMP]->[JPEG,BMP]").  Another 
application
could then register with types including PNG, JPEG, and BMP, w/o GIF and the 
user
could be offered a choice when two applications were found that could handle a 
merge.

Using existing Mime types &/or extensions is probably best.

Derek

--
Derek Price                      CVS Solutions Architect ( http://CVSHome.org )
mailto:address@hidden     OpenAvenue ( http://OpenAvenue.com )
--
I will return the seeing-eye dog.
I will return the seeing-eye dog.
I will return the seeing-eye dog...

          - Bart Simpson on chalkboard, _The Simpsons_