You might consider read over the archives at
and reading the project documentation for some answers to these questions.
Jimm Grimm <JGrimm@wiscomtech.com> writes:
> I'm glad to see that you are addressing binary/ascii file issues.
> Actually, it is that issue that led me to find out about your project.
> You probably have already looked at most of these questions, but I
> didn't have time to read your whole archive. So I'll just spout off a bunch
> of issues I'm aware of:
> If you have some complex auto-detection of binary files, are you
> going to have an easy way for people to see what it decided on each file?
> Is there going to be a way to manually override it if it makes the wrong
> decision? If an ascii file is mistaken for binary, most platforms have
> conversion programs to put it back in any format the user wants. But if a
> binary file is mistaken for ascii, it could be irrecoverably destroyed.
> Would it be a good idea to always check files back out in a hidden tmp
> directory, to make sure they were not corrupted? If they verify
> successfully, you should then delete the tmp copy. This might be a good
> option for paranoid people (like myself) in general. Maybe you could even
> patent it... Maybe it is patented already. ;-) You could have this as a
> verify option.
> I also saw that you are working on calling 3rd party software to
> diff binary files, such as WordPerfect documents. Do you plan to generalize
> this, to allow people to launch any other program before/after subversion
> commands? This could provide some very useful hooks for people to run
> regression tests, or put whatever kind of configuration management mumbo
> jumbo on top of subversion, etc.
> I just sent this email to email@example.com - I thought you might find it
> I've been reading the mailing lists a bit more on the binary file
> issue, and it seems to come up a lot. It seems to me like people have often
> merged two separate issues together:
> 1) eol conversions
> 2) mergeable and nonmergeable files
> There may be cases where people don't want eol conversions to take
> place, yet those files are still mergeable. For example, I don't want any
> binary files to get mistaken for ascii and destroyed, so I put
> * -k 'b'
> in cvswrappers. But then cvs won't do any merging, even on my text files,
> because it assumes they are binary. And there are cases of ascii files that
> are nonmergeable.
> > Examples of such files include Frame Maker MIF documents and uuencoded
> files. - Paul Sander
> There are four possible ways to treat files:
> 11 do eol conversion do merge
> 10 do eol conversion no merge
> 01 no eol conversion do merge
> 00 no eol conversion no merge
> Currently, 11 is the default option for all files. It is possible
> to do 00 on selected files using cvswrappers. It is also possible to make
> 00 the default option by specifying * -kb in cvswrappers, yet still specify
> some files to be ascii (11)
> Would it be possible to generalize the cvswrappers file to the other
> two options, 10 and 01? How far could this go towards resolving this raging
> debate? If someone just adds two more options to cvswrappers, it should
> still be backwardly compatible.
> Of course this would still not be 100% foolproof, because someone
> could name a binary file with a name that is normally used for ascii, or
> Also note: default treatment as ascii (11) is more dangerous, because if a
> binary file gets mistaken for ascii, it could get destroyed. On the other
> hand, if an ascii file gets mistaken for binary, it can easily be fixed up
> with dos2unix or unix2dos.
> moral: If you are using any binary files across platforms, default should
> be binary, not ascii.
> To unsubscribe, e-mail: firstname.lastname@example.org
> For additional commands, e-mail: email@example.com
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Sat Oct 21 14:36:37 2006