You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Eric Hanchrow <of...@blarg.net> on 2006/08/18 23:59:52 UTC

The bug that r20892 attempted to fix seems to be back on the trunk

lgo asked me to report this: The bug that r20892 attempted to fix
seems to be back on the trunk ... or, at least, the trunk is behaving
in a confusing way.

This is using r21125 from http://svn.collab.net/repos/svn/trunk.

I merged a branch into the trunk:

        $ /usr/local/stow/svn-trunk/bin/svn merge -r10043:10070 svn://10.10.10.37/branches/soodo-cleanup-2/ . 

I noticed some conflicts:

...
        CU   client/build.pl
        $ 

I exmamined the .merge-left, .merge-right, and .working files, and
couldn't tell what the conflict was -- here's what "svn diff" shows
(I've replaced actual carriage-returns with the two-character sequence
^M):

        Index: build.pl
        ===================================================================
        --- build.pl	(revision 10070)
        +++ build.pl	(working copy)
        @@ -1,3 +1,4 @@
        +<<<<<<< .working
         # Copyright 2003-2006 Dategrity Corporation. All Rights Reserved.^M
         #!perl^M
         ^M
        @@ -169,3 +170,109 @@
         print "\n=============== Build completed at " . scalar (localtime (time ())) . " ===============\n";^M
         ^M
         1;^M
        +=======
        +# Copyright 2003-2006 Dategrity Corporation. All Rights Reserved.
        +#!perl
        +

... I've deleted many lines of "diff" output here; almost the entire file, in fact

        +
        +print "\n=============== Build completed at " . scalar (localtime (time ())) . " ===============\n";
        +
        +1;
        +>>>>>>> .merge-right.r10070

        Property changes on: build.pl
        ___________________________________________________________________
        Name: svn:eol-style
           + native

It looks as if the entire file is in conflict, presumably because of
the line endings (I am pretty sure that I added the "svn:eol-style"
property, with a value of "native", on that file, in the branch; and
did that on a Windows machine.)

Curiously, none of the files

    build.pl
    build.pl.merge-left.r10043
    build.pl.merge-right.r10070
    build.pl.working

contain any carriage-returns at all.  However, the trunk version does
-- that is, if I do "svn revert -R .", file client/build.pl indeed
contains carriage returns.

The repository isn't going anywhere, so feel free to ask for further
details.  I'm sure I'm leaving out something important :-| 

-- 
As economics is known as "The Miserable Science", software
engineering should be known as "The Doomed Discipline"
        -- Edsger Dijkstra

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

Re: The bug that r20892 attempted to fix seems to be back on the trunk

Posted by Lieven Govaerts <lg...@mobsol.be>.
Daniel Rall wrote:
> On Sun, 27 Aug 2006, Lieven Govaerts wrote:

>> Revision r20892 solved the problem of the svn:eol-style propchanges 
>> during update, apparently the same thing during merges isn't fixed yet. 
>> I've added two new tests in merge_tests.py in r21280 for testing 
>> eol-style issues.
> 
> Does an issue still need to be filed for the 'merge' portion of this
> problem?

I think so. both Erik (eh) and I have looked at it. It's not that 
difficult to solve as far as I'm concerned, although it may require 
revving a public function. But if I remember well Erik wanted to propose 
an alternative solution to the list.

Lieven.

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

Re: The bug that r20892 attempted to fix seems to be back on the trunk

Posted by Daniel Rall <dl...@collab.net>.
On Sun, 27 Aug 2006, Lieven Govaerts wrote:

> Eric Hanchrow wrote:
> >lgo asked me to report this: The bug that r20892 attempted to fix
> >seems to be back on the trunk ... or, at least, the trunk is behaving
> >in a confusing way.
> >
> >This is using r21125 from http://svn.collab.net/repos/svn/trunk.
> >
> >I merged a branch into the trunk:
> >
> >        $ /usr/local/stow/svn-trunk/bin/svn merge -r10043:10070 
> >        svn://10.10.10.37/branches/soodo-cleanup-2/ . 
> >I noticed some conflicts:
> >
> >...
> >        CU   client/build.pl
> >        $ 
> >
> ..
> >It looks as if the entire file is in conflict, presumably because of
> >the line endings (I am pretty sure that I added the "svn:eol-style"
> >property, with a value of "native", on that file, in the branch; and
> >did that on a Windows machine.)
> 
> Revision r20892 solved the problem of the svn:eol-style propchanges 
> during update, apparently the same thing during merges isn't fixed yet. 
> I've added two new tests in merge_tests.py in r21280 for testing 
> eol-style issues.

Does an issue still need to be filed for the 'merge' portion of this
problem?

Re: The bug that r20892 attempted to fix seems to be back on the trunk

Posted by Lieven Govaerts <lg...@mobsol.be>.
Eric Hanchrow wrote:
> lgo asked me to report this: The bug that r20892 attempted to fix
> seems to be back on the trunk ... or, at least, the trunk is behaving
> in a confusing way.
> 
> This is using r21125 from http://svn.collab.net/repos/svn/trunk.
> 
> I merged a branch into the trunk:
> 
>         $ /usr/local/stow/svn-trunk/bin/svn merge -r10043:10070 svn://10.10.10.37/branches/soodo-cleanup-2/ . 
> 
> I noticed some conflicts:
> 
> ...
>         CU   client/build.pl
>         $ 
> 
..
> It looks as if the entire file is in conflict, presumably because of
> the line endings (I am pretty sure that I added the "svn:eol-style"
> property, with a value of "native", on that file, in the branch; and
> did that on a Windows machine.)

Revision r20892 solved the problem of the svn:eol-style propchanges 
during update, apparently the same thing during merges isn't fixed yet. 
I've added two new tests in merge_tests.py in r21280 for testing 
eol-style issues.

Thanks for the report!

Lieven.

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