Duncan says, svn is for revision management and EOL conversion is not the
goal of it, i totally agree but EOL conversion is a part of revision control
system also and has to be improved..
I want to give my own example;
Our software developers are working on windows. They use perl (cgi) and the
files has no extension. Then they commit their files (whic has no extension)
to the repository which is on Linux. Subversion is not able to automaticaly
convert dos file format into linux format. It needs extensions as you know.
We get errors when we test our web site which is hosted on the same linux
machine where also svn located.
I told the developers that when they add a new file, first convert it into
linux format then add the file. Also if i see newly added files i control
the files, if it is not in linux format i convert them manually and
recommit them. ( I also have a cron job for this which in every 1 minute
checks the the repository. When it sees files which has DOS file format it
converts and recommits them)
So only for the conversion change, our revision also increases and produce
unnecessery logs..
As i said before this whole cycle is a part of revision management and i
think this EOL conversion area can be improved..
AS
-----Original Message-----
From: Duncan Murdoch [mailto:murdoch@stats.uwo.ca]
Sent: Thursday, February 01, 2007 1:10 AM
To: Jeff Smith
Cc: users@subversion.tigris.org
Subject: Re: What do you Hate about Subversion?
On 1/31/2007 4:34 PM, Jeff Smith wrote:
> On Tuesday 30 January 2007 13:15, Oliver Betz wrote:
>> Les Mikesell wrote:
>>
>> [...]
>>
>>>> That's an option, and a good one: just say no to tools that
>>>> care too much about EOL. I work on Windows, and almost all of
>>>> the tools I use (all of them that I use more frequently than
>>>> once a month) handle CRLF or LF fine. If I came upon a tool
>>>> that didn't, I'd consider it a flaw in the tool.
>>> Was that intended to be humorous? If you don't want do deal with
>> I agree with Duncan.
>>
>> How do you access "non CRLF" files without the help of SVN?
>>
>>> portability issues, just work on one platform?
>> No, as Duncan wrote: use the right tools.
>>
>>>> There are plenty of flawed tools out there, but just don't use
>>>> them.
>>> Sorry, but most people would chose a revision control system that
>>> will handle the job they need to do, not choose their job based
>>> on what their revision control system happens to make convenient
>>> for them.
>> You missed the point.
>>
>> SVN can not protect "flawed" tools from the reality in any
>> situation.
>>
>> Oliver
>
> This is my argument for needing a better feature to handle diverse
> text files: Since I am trying to track vendor updates (a very common
> case), then
>
> 1. I do not have a choice how the vendor or any of his opensource
> helpers edit there source, nor what tools they use.
>
> 2. This is a strong argument: "reality is that text is represented
> differently" everywhere. My conclusion is that we MUST deal with it
> in Subversion.
>
> So to just expect svn to crash and burn because one of the files is
> mixed EOL styles is NOT dealing with it.
>
> I am surprised this "EOL style" thread is still going on since that is
> obvious. Is anyone arguing that svn need NOT be improved in this
> area??
I would put this at a low enough priority that "svn need not be improved
in this area". If you're dealing with a project where automatic EOL
conversion doesn't work, then turn it off. There are cases where it
works (most), cases where it doesn't (cross-platform work where the
files are accessed directly from diverse platforms, source under someone
else's control, etc.), and in the cases where it doesn't work you just
shouldn't use it. If you really want some specialized form of EOL
translation, then write a specialized tool to do it yourself.
svn is for revision management. It's nice that it can handle the common
cases of text format translation, but that's not its main goal, and if
the simple thing it does doesn't work for you, turn it off.
Duncan Murdoch
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Feb 1 14:28:46 2007