[
https://issues.apache.org/jira/browse/SVN-4608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15044708#comment-15044708
]
Bert Huijben commented on SVN-4608:
-----------------------------------
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.
> Files are labeled as 'deleted' when the version brought by an update collides
> with the pre-existing file
> --------------------------------------------------------------------------------------------------------
>
> Key: SVN-4608
> URL: https://issues.apache.org/jira/browse/SVN-4608
> Project: Subversion
> Issue Type: Bug
> Reporter: Yuri
>
> 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.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
