Uploaded image for project: 'Subversion'
  1. Subversion
  2. SVN-4608

Files are labeled as 'deleted' when the version brought by an update collides with the pre-existing file

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 1.10.0
    • Component/s: None
    • Labels:
      None

      Description

      Here is the situation:

      I create the new sub-directory within the repository where I don't have commit rights without 'svn add'. Later, when this directory is committed by somebody else and repository is updated by me, the files that are coming with update are immediately labeled as 'deleted' when they collide with their copies that are pre-existent on disk.

      This behavior doesn't make much sense. If the file brought by an update is already on disk, it should be silently overwritten in case the contents are the same, or the user should be asked the question what to do: accept the new version, keep the pre-existing version, or launch the merge tool.

        Activity

        Hide
        rhuijben Bert Huijben added a comment -

        In the Subversion project we use the buddy system for creating issues. Please e-mail users{AT}subversion.apache.org first, before creating an issue.

        This behavior is by design and as such not 'just a bug'. The incoming tree is unrelated with what is in the working copy, and a tree conflict is created to explain you that this is the case.

        The deleted state in Subversion (in the background) then tells that whatever is in the working copy is not related to what the repository thinks is in the working copy. It is obstructed.
        If we wouldn't mark it as such further operations might just delete your hard work as part of a further operation because it thinks it is already managed by Subversion.

        As subversion currently doesn't have a dedicated obstructed state that allows files obstructing files and directories obstructing directories we use the deleted state to handle this case. You usually change the tree by either accepting your local state as the state you want (mark resolved), or by reverting the entire tree (svn revert) which changes both the deleted state and removes the tree conflict state.

        Show
        rhuijben Bert Huijben added a comment - In the Subversion project we use the buddy system for creating issues. Please e-mail users{ AT }subversion.apache.org first, before creating an issue. This behavior is by design and as such not 'just a bug'. The incoming tree is unrelated with what is in the working copy, and a tree conflict is created to explain you that this is the case. The deleted state in Subversion (in the background) then tells that whatever is in the working copy is not related to what the repository thinks is in the working copy. It is obstructed . If we wouldn't mark it as such further operations might just delete your hard work as part of a further operation because it thinks it is already managed by Subversion. As subversion currently doesn't have a dedicated obstructed state that allows files obstructing files and directories obstructing directories we use the deleted state to handle this case. You usually change the tree by either accepting your local state as the state you want (mark resolved), or by reverting the entire tree (svn revert) which changes both the deleted state and removes the tree conflict state.
        Hide
        yurivict Yuri added a comment - - edited

        In general in such situation one can lose one's work. But the way that I suggested prevents this. Ex. if no files are different between the new and pre-existing, keeping them can't cause the data loss.

        Making new files 'deleted' certainly damages.

        Show
        yurivict Yuri added a comment - - edited In general in such situation one can lose one's work. But the way that I suggested prevents this. Ex. if no files are different between the new and pre-existing, keeping them can't cause the data loss. Making new files 'deleted' certainly damages.
        Hide
        rhuijben Bert Huijben added a comment -

        As noted before: this is not a discussion forum. We don't make design decisions here... we do that on mailing lists.

        Your new files aren't added yet... That is the reason the repository files are marked deleted. They could match what is in your working copy... or they might be unrelated. That is why you have a tree conflict.

        You have to tell subversion what you want to do.

        • You can either add your files (svn add <files>) over what is already there after marking the conflict as resolved.
        • Or you can revert your local changes (which resolves the conflict as resolved in a single step)

        Not marking the files as deleted would make the decision for you... Essentially we then already reverted your local changes for you, by just marking them as a modified version of what is in the repository. (You can actually get this behavior by passing --force)

        And if you use 'svn' it would have already invoked the interactive conflict resolver before you can even see that the files are marked as deleted... So something is missing in your report. Perhaps you are using a different client? (And then your question might belong there)

        Show
        rhuijben Bert Huijben added a comment - As noted before: this is not a discussion forum. We don't make design decisions here... we do that on mailing lists. Your new files aren't added yet... That is the reason the repository files are marked deleted. They could match what is in your working copy... or they might be unrelated. That is why you have a tree conflict. You have to tell subversion what you want to do. You can either add your files (svn add <files>) over what is already there after marking the conflict as resolved. Or you can revert your local changes (which resolves the conflict as resolved in a single step) Not marking the files as deleted would make the decision for you... Essentially we then already reverted your local changes for you, by just marking them as a modified version of what is in the repository. (You can actually get this behavior by passing --force) And if you use 'svn' it would have already invoked the interactive conflict resolver before you can even see that the files are marked as deleted... So something is missing in your report. Perhaps you are using a different client? (And then your question might belong there)
        Hide
        stsp Stefan Sperling added a comment -

        This problem should be fixed by the new conflict resolver to be released in 1.10:
        https://subversion.apache.org/docs/release-notes/1.10.html#conflict-resolver

        The new resolver offers an option to merge directories added on both sides automatically, for updates and for merges between branches.

        I am closing this issue. Once 1.10 is released, please let us know if you still see a problem.

        Show
        stsp Stefan Sperling added a comment - This problem should be fixed by the new conflict resolver to be released in 1.10: https://subversion.apache.org/docs/release-notes/1.10.html#conflict-resolver The new resolver offers an option to merge directories added on both sides automatically, for updates and for merges between branches. I am closing this issue. Once 1.10 is released, please let us know if you still see a problem.

          People

          • Assignee:
            Unassigned
            Reporter:
            yurivict Yuri
          • Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development