Announcement

Collapse
No announcement yet.

Is there a way to specify the line ending style for merge output?

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Is there a way to specify the line ending style for merge output?

    I am using P4V (windows client for PerForce) with BC3 as my diff/merge tool. I did a merge recently, with the left and center files pulled from the PerForce repository, and apprently moved to my local disk with PC line endings (CRLF), and the right file (my version) from a network attached Linux drive with Unix line endings (LF only). After the merge, the output file was saved with PC line endings. When I checked this in, it was stored the same way.

    Unfortunately, our corporate standard is Unix line endings.

    I cannot use the setting to always consider line ending differences during compares, since the windows PerForce client always converts repository files to PC style when creating temp files for compare and our checked out versions on Linux always have Unix style line endings. I just need to make sure that when I save the merged output, is uses Unix-style line endings (or I need someplace I can specify this as a default, or specify which of the input file's style the output should conform to).

  • #2
    You can use File->Save As to then specify the Line Ending. In the example you describe, however, it should have picked Unix (since it would determine that the ancestor had changed to Unix from the Right file).

    Did one of the files possibly have a mixed line ending? If a mix is detected it would default to your System line ending.
    Aaron P Scooter Software

    Comment


    • #3
      No, the left and center files were CRLF line endings and the right file (mine) was LF only.

      Comment


      • #4
        That seems a bit odd.

        If you Save As... the files locally, and then open them in a merge, what do you see?

        Would it be possible to get screenshots and example files sent to support@scootersoftware.com ?
        Aaron P Scooter Software

        Comment


        • #5
          Since the code is proprietary, I can't easily send screen shots. I've also already fixed the problem, so the files I used are no longer available. I'll try to collect more information if this happens again.

          Comment


          • #6
            Ok, thanks.

            In the meantime, if it picks 'incorrectly,' is it a suitable solution for you to override it with a Save As and manually picking the type?
            Aaron P Scooter Software

            Comment


            • #7
              It's not ideal, but better than nothing.

              I've been trying to think of ways that you could indicate a difference like this without affecting the comparison. Possibilities include making line endings visible, but unimportant (this could also apply to tabs or other non-printable characters), or adding a file type indicator somewhere on the screen (I don't like this one much, because it adds clutter that would be irrelevant in most cases).

              Comment


              • #8
                Would the default encoding settings in Tools|File Formats|Conversions(Tab) help you? I would assume that it would enforce the output file to be that format, but I haven't tried it to see what happens when a file of a different format is opened.

                Comment


                • #9
                  - Select "View -> Visible Whitespace" to show line endings.
                  - The file type indicator is listed in the status bar of the input editors (MAC, PC, UNIX, MIX).
                  - "Compare line endings" in the "Session Settings" dialog will treat differences in line endings as important. This is most useful for mixed line endings.
                  Erik Scooter Software

                  Comment


                  • #10
                    The encoding setting would only affect which code page was used to write the file (eg UTF-8 vs ANSI). It wouldn't control the line ending style.
                    Tim T Scooter Software

                    Comment


                    • #11
                      I had forgotten about the visible whitespace option. Assuming this shows up in the merge window as well, this will at least give me a heads up if I am going to write the wrong style file after a merge.

                      Comment


                      • #12
                        Ummm yeah it's pretty obvious that the encoding wouldn't help. I quickly pulled it up, saw DOS in the list and assumed it was talking about EOL characters. Sorry about that.

                        Comment


                        • #13
                          Just had this happen again

                          I did two merges this morning, using the copy of build 459 I downloaded today. In both cases, the left and center had PC-style line endings and my version, the right file, had Unix-style line endings (had visible whitespace on to verify this). In the first merge, the output file displayed with Unix-style line endings, and in the second, it displayed with PC-style. The only difference between the two merges (other than the files involved) was that the first, where my line-ending style was used in the output, did not have any conflicts between the left and right files, and the second, where the left/center line-endings were used in the output, did have conflicts between the left and right files. This is consistent, as the first time I had this problem was also when I was resolving conflicts between two versions of a file.

                          What criteria does BC use to determine which side's line endings to use?

                          Comment


                          • #14
                            Originally posted by tlscales View Post
                            What criteria does BC use to determine which side's line endings to use?
                            if L=R then use L {unchanged, same change}
                            else if C=R then use L {left change}
                            else if L=C then use R {right change}
                            else use C {conflict}

                            However, if the chosen file has a mixture of line endings, it will use the system default.

                            I am unable to reproduce the problem with the steps you've given. Please send your settings and the files you are having trouble with to support@scootersoftware.com
                            Erik Scooter Software

                            Comment


                            • #15
                              Sending settings

                              I am sending a copy of my settings as requested. I cannot send copies of the files, as they contain proprietary information and I cannot easily sanitize them. I am unable to duplicate the problem by starting the merge from the BC3 home screen or from the command line, only while initiating a merge of a file with conflicts from the Perforce Windows client (P4V). Is there a command line setting that P4V might be adding in the event of a conflict merge that might be affecting the output format?

                              Comment

                              Working...
                              X