[Top][All Lists]

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

Re: Proposal to fix CVS binary file implementation

From: Paul Sander
Subject: Re: Proposal to fix CVS binary file implementation
Date: Fri, 29 Dec 2000 16:33:42 -0800

>--- Forwarded mail from address@hidden

>Paul Sander wrote:

>> --- Forwarded mail from address@hidden (Greg Woods)
>> >Think about it: You've got some changes you are about to commit that
>> >include changes to a file which you've tagged as un-mergable (i.e. it is
>> >a binary, opaque, file).  As you run "cvs commit" you discover that
>> >someone else has simultaneously made changes to that file.  Now what?
>> >You can't even use "cvs diff" to find out what the heck they did!  You
>> >can only guess by investigating their revision comments and/or by asking
>> >them out-of-band.  If the file has some structure that's visible in some
>> >other medium than a text editor (eg. it's a JPEG) then you can perhaps
>> >visually compare your revision, the ancestor revision, and the other
>> >person's new revision.
>> Okay, now suppose you have a type manager that can invoke the proper merge
>> tool for the file's content.  The merge proceeds and the user resolves
>> conflicts normally.  No big deal.
>> 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 
>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.

>--- End of forwarded message from address@hidden

reply via email to

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