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
Received on Sat Oct 21 14:36:37 2006