Re: Merge bug(let)

"Sander Striker" <striker@apache.org> writes:

> > <Whisper>
> > Or how about we abandon eol-conversion as a bad idea?
> > </Whisper>
>
> *grin* One can always keep trying ;) But I think you realise how important
> a 'feature' our users regard this.

I guess we will just have to fix the bugs.

There appears to be way to get CRLF line endings into the repository
together with an svn:eol-style of native. Try

   svn co -r5007 http://svn.collab.net/repos/svn/trunk/build/win32 5007

and look at 5007/.svn/text-base/build_neon.bat.svn-base, it has CRLF
line endings, but the svn:eol-style is set to native. I don't know
exactly how to reproduce this, I haven't been able to do it on my Unix
box. I *think* it can be done on a Windows box by committing a file
with extra CR characters, something like

        fooCRCRLF
        barCRCRLF

which gets converted to

        fooCRLF
        barCRLF

before being sent to the repository. From what Bill has told me
that's how it happened in the past. The real problem is that this
illustrates how fragile the system is, it relies on the "good
behaviour" of the clients. Is it going to work when plain WebDAV
clients can commit to a Subversion repository?

Having a file like this causes problems, the merge bug in this thread
being one. When the next change to the file's text is committed, the
client will convert all the CRLF to LF, so the commit will change
every line even though the user may only have changed one. Running
'svn diff' on the working copy before the commit doesn't show the
problem, because diff works on files in the working copy form, not in
the repository form.

-- 
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org