Ok, the problem did in fact turn out to be that I was running /bin/sed
instead of /usr/local/bin/sed.
I would like to comment on the concept of 'human readable' though.
Although emacs (for example) can easily handle binary files just
dumped into the output file, including 8-bit data sure doesn't make
the dump file human readable anymore. It also makes processing the
dump file with text (or more accurately line) oriented tools error
prone.
SVN is already, in my opinion, somewhat handicapped by the fact that
it uses a database backend and thus a binary file format that puts you
at the mercy of the decode/repair tools specifically designed for
it. It would be nice if at least the dump file format would stick to
an ASCII only representation that makes processing of dump files with
'standard' utilities easy and less error prone.
Max Bowsler made the interesting comment that "Personally, I think
that uuencoding (or similar) doesn't increase human-readability, it
just wastes processing time" which I completely disagree with. Who
cares about minute incremental decoding time or even file size in
this age of multi-GHz processors and 100GB disks. Human readable
is a term that should not be taken literally. To me it means that it
is an ASCII/text based representation I can feed any tool like sed or
awk with.
I want to be able to modify, cut, splice n dice the dump file at will,
using line oriented utilities and not get surprised by the odd junk of
binary data in it.
roland
"Dale Worley"<dworley@pingtel.com> writes:
> I expect that your problem is coming from sed's effect on binary input. As
> others have mentioned, it's likely that it is not reacting well to what it
> perceives as excessively long lines, or line-ending characters that are not
> in the correct configuration for your platform. (This will be particularly
> grim for programs (like sed) that are written in C when run on platforms
> that use CR-LF for end-of-line, as the C I/O library is required to
> translate EOLs into LF upon input and back into CR-LF on output.)
>
> One possibility would be to use Gnu Emacs, which is quite robust against
> these problems (provided you use find-file-literally to make sure that it
> doesn't try to be intelligent about the character encoding of your file).
> I've successfully used it to patch the character strings in executable
> files, so it should work for you.
>
> Another thing which might help is to not rewrite the file names. Instead,
> dump and svnfilter the data to extract the files you want, then load that
> into the new repository. Then use svn commands to adjust the file names.
> For instance, you want to change "documentation/trunk/dir/file" into
> "trunk/dir/file", so you could do "svn mv documentation/trunk trunk". That
> sequence of operations would use only software that was already proven on
> the tasks in question.
>
> Dale
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Dec 30 20:22:39 2004