You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Jimm Grimm <JG...@wiscomtech.com> on 2001/08/29 20:18:30 UTC
eol conversions, merging
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
Re: eol conversions, merging
Posted by Branko Čibej <br...@xbc.nu>.
Jimm Grimm wrote:
>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:
>
Look at
http://subversion.tigris.org/servlets/ReadMsg?msgId=33491&listName=dev
and the following thread. I think you'll find all your questions answered.
--
Brane �ibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: eol conversions, merging
Posted by kf...@collab.net.
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 <JG...@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