Jimm,
You might consider read over the archives at
http://subversion.tigris.org/servlets/ProjectMailingListList
and reading the project documentation for some answers to these questions.
-Karl
Jimm Grimm <JGrimm@wiscomtech.com> writes:
> Hi!
>
> 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 info-cvs@gnu.org - I thought you might find it
> interesting.
>
> 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)
> (http://mail.gnu.org/pipermail/info-cvs/2001-August/019343.html)
>
> 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
> vice-versa.
>
> 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.
>
> Thanks!
>
> Jimm
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:37 2006