On May 22, 2007, at 17:51, Bruce Wilson wrote:
> I have a small local repository where I've been maintaining
> versions of a certain ColdFusion application. The app is written
> by another vendor, and most of the code is distributed in
> ColdFusion's native "encrypted" format. (A largely binary
> format.) The encrypted form is the official release, and the one I
> install at clients, but I have access to a decrypted version as
> well. Subversion makes it very easy for me to track their changes
> between versions, or to get back any particular release I need. I
> guess I don't need to spend long on the benefits of Subversion.
>
> I'm running on Windows, but ColdFusion is (I hear) from Unix roots,
> and some of the tools I and others rely on use Unix line endings.
> I'd had some occasional problems where CF was unhappy with a file
> because of mixed line-endings. Reading some of the wisdom from
> this list and other places, I modified my svn config file, with
> *.cfm = svn:eol-style=native
> (among many other entries) and patted myself on the back for using
> SVN correctly. I thought a bit about the encrypted files, but I
> figured that since I would only access the repository from a
> Windows client, "native" would always mean the same thing.
>
> Just today, one of my clients had a problem with a file that had
> come through my SVN repository. The encrypted version was
> corrupted - it couldn't be decrypted, nor could it be parsed by
> ColdFusion. I compared the bad file with a known-good encrypted
> version and found many changes. Most notably 0A (hex) translated
> to 0D0A, but also low-ASCII characters (02 thru 1E on a quick skim)
> translated to 2E.
>
> Sadly, I didn't track my SVN config file in SVN, so I can't be sure
> when exactly I made the change relative to other commits. The
> config change was about two months ago, but I have been actively
> using this repository for most of a year. Since the code is not my
> own I could start over, but I can think of more fun things to do
> than reliving about 200 commits worth of my life.
>
> So my questions are:
> Are these changes consistent with the effects of "svn:eol-
> style=native" on a binary file?
Yes. Subversion applies the requested eol translation on all files of
the indicated extension, whether they are text or binary. If you do
not want the eol translation to occur on binary files, do not set the
svn:eol-style property on those files. If both binary and text files
share the same extension, that that seems nearly broken by design...
> How can I tell if SVN was the cause or the result of a different
> tool? (E.G. transferring the file via FTP in ASCII mode) I knew
> about 0A to 0D0A translation, but the control characters surprised me.
The control characters surprise me too.
> What is the appropriate way to figure out which files in my
> repository may have been affected by this configuration?
You could check out the entire repository (if feasible; if not, check
out parts at a time) and look for files that have svn:eol-style set
to anything. For all those files, determine if they are text or
binary. For example, on UNIX, the "file" command should tell you. For
all the files that are binary, they are probably corrupted.
> Once I figure out which files are affected, is there a clean way to
> extract the files out of SVN again, reversing any damage?
For files where you have requested eol translation, Subversion stores
the files in a normalized form in the repository, translating CR,
CRLF or LF to just LF on import. There's no way to know which of
these translations has occurred, so the files are probably
irrevocably corrupted. You must restore them from elsewhere.
> How do others deal with file extensions which could be either ASCII
> or binary?
> Has anyone worked out a good way to work with mixed encrypted and
> plaintext ColdFusion files and still benefit from automatic EOL
> handling?
You could probably handle this by moving the responsibility to the
developer to ensure that text CF files have the correct eol style,
and you could install a pre-commit hook to enforce this. The pre-
commit hook would check the files in the incoming transaction, and
for each CF file, determine (again, using the "file" command, for
example) which ones are text, and for those, ensure that only one
kind of eol style appears in the file, and reject the commit
otherwise. The pre-commit hook could also optionally complain if CF
files are committed with svn:eol-style set -- either for all CF
files, or just for the binary ones, as you wish.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed May 23 01:08:15 2007