Hi Fitz,
Thanks very much. If it is known to work okay, I will use the option.
BTW, the source of my confusion is this paragraph about svn:mime-type
(http://svnbook.red-bean.com/en/1.1/ch07s02.html#svn-ch-7-sect-2.3.2)
[Sorry, for cut-pasting a rather large paragraph here. I am also
CC-ing the subversion group]
"For example, if a file's svn:mime-type property is set to a non-text
MIME type (generally, something that doesn't begin with text/, though
there are exceptions), Subversion will assume that the file contains
binary—that is, not human-readable—data. One of the benefits that
Subversion typically provides is contextual, line-based merging of
changes received from the server during an update into your working
file. But for files believed to contain binary data, there is no
concept of a "line". So, for those files, Subversion does not attempt
to perform contextual merges during updates. Instead, any time you
have locally modified a binary working copy file that is also being
updated, your file is renamed with a .orig extension, and then
Subversion stores a new working copy file that contains the changes
received during the update, but not your own local modifications, at
the original filename. This behavior is really for the protection of
the user against failed attempts at performing contextual merges on
files that simply cannot be contextually merged."
I think svn assumes the file to be text based unless otherwise
specified by mime-type. So if during the cvs2svn conversion, if
eol-style and mime-type are set to nothing (as it will do if
--no-default-eol and --keywords-off are used), then wouldn't binary
files be considered text while merging as explained by the above
paragraph? Is that a problem? While it may not be a problem, I assumed
it is.
Can someone help me understand this a little more clearly?
[This is not a big issue as I do not anticipitate a merge situation
for any binaries. But I just want to understand how it works, thats
all]
Thanks very much
-Hari
On Mon, 07 Feb 2005 17:01:05 -0600, Brian W. Fitzpatrick
<fitz@collab.net> wrote:
> On Mon, 2005-02-07 at 16:14, Hari Kodungallur wrote:
> > Hi Fitz,
> >
> > That was part of my original question.
> > I am not sure what the implications of setting --no-default-eol are.
>
> cvs2svn just doesn't set the eol-style on these fileSee the Subversion
> book for more info on eol-style:
> http://svnbook.red-bean.com/en/1.1/ch07s02.html#svn-ch-7-sect-2.3.5
>
> > If the eol-style and mime-type are not set, will svn consider it to be
> > text file, when in fact the file is binary? And in that case will it
> > be a problem when a new version of that binary is checked in (will it
> > try to merge, in that case, or will it just replace the new binary)?
>
> Subversion handles binary flies efficiently, so the amount of storage
> needed will be proportional to the size of the change.
>
> > I do not know what the behavious in such a case is. If there is no
> > after effect of using these options, I will definitely use it.
>
> I used both when converting my personal repository, and I'm fine. :)
>
> Remember that you can always set these properties on the files in your
> Subversion repository at any time.
>
> -Fitz
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Feb 8 01:14:35 2005