• RuntimesUnity

  • Can materials and animator controllers be moved to its own folders in Unity

    anglais
Related Discussions
...

The checkout happens in Unity and looks like it is because of Line 698 which marks assets dirty even though there are no changes.

@belovedquestioningly Sorry, the term checkout I used might have been misleading here. I don't mean "checkout for editing" but in git terminology meaning "download and setup of your local files by your version control system".

In general your version control system should not care whether Unity's asset database marks anything as modified if there is no actual diff of the files. That is, unless Unity is configured to lock or check-out-for-modification any files in your version control system upon marking them dirty and performing the asset database save operation. However, you said that these files are marked as modified and not as checked out / locked (and the icons in your earlier posting look like that as well).

Do you and your colleage (where you get the differences) perhaps work on MacOS and the other one on Windows? As Unity seems to always use LF line endings for asset files regardless of platform, it might be that one of you has your version control system configured to convert line endings to a common format different than Unity's LF. This line ending conversion typically happens either upon checkout (local download) or upon commit.

Both me and my colleague work on a Window Machine, the project was also developed on a windows machine.

Sorry I should be clearer, by modified I mean it marks the asset as modified for Perforce to pick up. With my experience with SetDirty function, it is possible that using it will mark it modified for Perforce to pick up even if there is no differences.

Here I have attached a dummy script that marks selected asset dirty:

using UnityEngine;
using UnityEditor;
public class MarkAssetDirty : MonoBehaviour
{
    [MenuItem("Assets/Mark Selected Asset Dirty")]
    private static void MarkSelectedAssetDirty()
    {
        Object selectedObject = Selection.activeObject;

        if (selectedObject != null)
        {
            // Mark the selected object as dirty
            EditorUtility.SetDirty(selectedObject);
            // AssetDatabase.SaveAssets();

            Debug.Log("Asset marked as dirty: " + selectedObject.name);
        }
    }
}

I have run this script on my prefab, which in perforce turning off line ending difference shows no changes,


and if I turn on line endings

but the asset is checked out

    belovedquestioningly With my experience with SetDirty function, it is possible that using it will mark it modified for Perforce to pick up even if there is no differences.
    ..
    which in perforce turning off line ending difference shows no changes,
    [image of no differences]
    and if I turn on line endings
    [image of full file marked as different]

    I'm not sure I understood you correctly, as the above seems contradictory: If turning off line ending difference shows no changes, but turning on showing line ending difference displays the whole file, it means that there are line-ending differences comparing the old and new file state.

    This would easily be explained if beforehand line endings were e.g. CRLF (e.g. due to Perforce downloading or committing files in CRLF line ending), and after Unity writes the same file, they are LF.

    Could you perhaps send us one of the problematic files in the two versions, once before they are touched by Unity, and once afterwards (when perforce lists them as checked out or edited). You could attach the files to a forum posting or send them to us via email to contact@esotericsoftware.com, briefly mentioning this forum thread URL so that we know the context.

        Harald This would easily be explained if beforehand line endings were e.g. CRLF (e.g. due to Perforce downloading or committing files in CRLF line ending), and after Unity writes the same file, they are LF.

        This behaviour would also be confirmed by the default line ending settings in Perforce here, which are to use local, meaning CRLF on windows. So every time you get the latest revision from the p4 server, you get CRLF files, and when Unity touches the file it's LF.

          File in state before opening in Unity:

          When Unity is opening and since I have notepad++ open during this process, it shows file modified

          after Opening in unity:

          File 1: Before Unity

          spineboy-pro-atlas-preunity.txt
          632B

          File 2: After Unity

          spineboy-pro-atlas-postunity.txt
          632B

            belovedquestioningly When Unity is opening and since I have notepad++ open during this process, it shows file modified

            Note that Notepad++ uses the file modification date for that, not actual diffs.

            Thanks for sharing the additional files, these are now identical and display no diff in Perforce Merge:

            Unfortunately this still does not answer the important question: When viewing the version control state of the file, did this file show as "not modified" or "not checked-out" before opening Unity and show as "checked-out for editing" afterwards?

            I'm asking mainly because the above (no line ending diff) contradicts what you've posted previously, the screenshot of the Perforce diff showing line ending differences:

            belovedquestioningly and if I turn on line endings

            The important remaining question is the following:
            Whether when committing the file you sent us with LF line endings to your repository, then checking in e.g. Notepad++ that there are LF line endings, and then opening Unity, is the file afterwards marked as "changed" or "checked out for editing"?

                Yes originally I had my workspace set to be on local (which is windows and made it look like there were line ending changes in my first screenshot), but after I manually set it to use Unix and force got latest before opening in Unity which sets the line endings of file as LF on my local machine, when Unity opens, files are marked "Checked out" that has this tick symbol in unity

                When viewing the version control state of the file, did this file show as "not modified" or "not checked-out" before opening Unity and show as "checked-out for editing" afterwards?

                Yes

                Here is a video of the whole process:

                  belovedquestioningly (which is windows and made it look like there were line ending changes in my first screenshot)

                  The Perforce diff showed 1 line ending or whitespace diff. If there were no line-ending differences, then it must have been other whitespace differences.

                  Here is a video of the whole process:
                  ..

                  Thanks for making the GIF. This video however again shows that you are having 1 diff of line endings or whitespace:

                  The two files that you sent us earlier showed no diff even with comparison method - line ending and whitespace differences enabled.

                      @belovedquestioningly I have just performed some tests locally with Unity's perforce integration. It indeed seems as if the line endings are not the problem, but just the Unity integration which performs an auto-checkout.

                      The non-zero diff likely comes from CRLF line endings on the server file revision, which just shows when comparing the server's head revision (displayed as having CRLF line endings, even though according to config should not be using CRLF strangely) against the local workspace copy (correct LF lineendings). As a result you never saw the CRLF line endings in the Assets folder or in the files you sent us, since it's only the temp server-revision file which shows CRLF endings.

                      We'll see if it can somehow be avoided that a checkout is triggered (by re-serializing the assets, even if the result is the same) even though leaving an unmodified file. You could of course use "Revert unmodified", but I understand that that's somewhat inconvenient and could be forgotten.