Ryan Schmidt wrote:
> On Sep 24, 2008, at 21:32, David Weintraub wrote:
>
>> On Wed, Sep 24, 2008 at 9:40 PM, Andy Levy <andy.levy_at_gmail.com> wrote:
>>> On Wed, Sep 24, 2008 at 21:22, David Weintraub <qazwart_at_gmail.com>
>>> wrote:
>>>> On Wed, Sep 24, 2008 at 5:28 PM, Steve Whitson
>>>> <steven.whitson_at_gmail.com> wrote:
>>>>> One other issue here is that in order to maintain softlinks I have
>>>>> to keep
>>>>> the master working (reference) copies on unix, which leads to
>>>>> problems when
>>>>> auto-props is turned on and eol-style is native... especially when
>>>>> expectation is that the eol doesn' t change between platforms.
>>>>> For some
>>>>> tools/languages/scripts that's not an issue, for others it is.
>>>>
>>>> Have you looked at svn:eol-style=share?
>>>>
>>>> That keeps the line endings in the repository as Unix LF, but changes
>>>> them in your working copy depending upon the platform you use. On
>>>> Unix, they'll be LF, on Windows, they'll be CRLF.
>>>
>>> I don't see share as a valid value for this property in
>>> http://svnbook.red-bean.com/en/1.5/svn.advanced.props.file-portability.html#svn.advanced.props.special.eol-style
>>>
>>>
>>> What you describe is how svn:eol-style=native behaves.
>>
>> Sorry. I've been up pretty late, and I'm getting this mixed up with
>> Perforce. Yes, I'm thinking of snv:eol-style=native.
>>
>> That's a problem when you work with a bunch of different systems all
>> at the same time.
>
> Well it sounds like Steve is already using svn:eol-style=native, and
> the problem he's running into is that he wants to share a working copy
> between Windows and Unix computers. He needs to check out the working
> copy on Unix (so that the Unix part can use the symlinks that are
> checked into his repository). But since the eol translation only
> happens at checkout / update time, this means that the line endings
> are Unix (because the checkout was done on Unix) but this means when
> you access the working copy from Windows, Windows programs won't know
> how to deal with it.
>
> Where I worked, we set svn:eol-style=LF instead so it didn't matter
> where it was checked out. And we trained all our Windows software to
> know how to deal with files with LF line endings.
Thanks for the feedback! :)
My initial problem was to understand why eol-style was being set to
native. This was being done by smartsvn, the gui I used on unix
(auto-props are on and this is its default). If I had used only the svn
client, this issue would never have come up (using the config defaults,
as I did in another repository). I have many text-files that the format
should not be touched, but left as the tool wrote them. These are not
to be readable and are basically xml format, and frequently over 60meg.
Some of these files were set to native, and some were not. So, while
correcting these I discovered that anything of type text was (pretty
much) set to native (not good!). So, I destroyed this new database and
started again, this time using auto-props and haveing everything
explicilty set. Ok, somewhat of a trivial pain, but this will help keep
things in order (as they should be). We have some (text) files which
are best keep with LF eol, and others that should be kept with CRLF eol
(for human readability, espeically when considering customers). Our
developers know how to use editors that are support both, but usually
don't keep up with this issue (since their editor does). I end up with
a mixed set in the repositories depending on the defaults for the editor
they used, or on which platform they wrote the file. I must say,
explicitly setting the eol-style is much better than where I came from
(leaving everything as the developer left it, or as their tools left it).
So, all in all, this was a good exercise for me, just not one I wanted
to face while bringing across an initial baseline to create this
repository with.
I see the discussions on 'auto-props' and the need for a feature
allowing for clients to get these settings from the server. I look
forward to that feature being implemented, since my setting of these
only fixes what I put in this repository today. Ensuring each
developer's client environment sticks to our defined auto-props
configuration is not going to be easy.
Thank much,
-Steve
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-09-25 12:50:08 CEST