On Tue, Mar 15, 2005 at 01:41:05PM -0600, Ben Collins-Sussman wrote:
> On Mar 15, 2005, at 12:10 PM, Volker Hejny wrote:
> > The request to delete these
> >files - to my opinion - must give a conflict. The user than knows
> >that he has to take care of that.
> Well, running 'svn status' will show your file as '?'. That's a pretty
> clear indication that it's something to take notice of.
As described in the initial example: Both files in question, the
changed one and the added one, are deleted by svn, i.e. no longer
there. There are not just 'unversioned'. There are no files any more
which can be marked as '?' and taken care of later.
What you describe is the behaviour on locally modified files when
issue an 'svn update'. That's fine.
The problem is in 'svn merge':
| | merge
At (1) the branch the created, at (2) a file is modified in trunk,
at (3) the corresponding file in branch is deleted. During merge
at (4) (which would look like 'svn merge 1:3 branch' the file is delete
in trunk, too, although is has been changed between revision 1 and 3
Well, one can argue, that since the file has been deleted in branch,
any changes are no longer important. However, in reality the file
has not just been deleted but copied and deleted. The changes in
trunk would be of interest for the copy.
At the moment, the only solution is to manually track down any
of these copy/delete-change problems, i.e. actually do the
code-management again manually and search what files are copies
The one thing, which subversion could do during merge, is to warn the
user that a file is going to be delete which was changed meanwhile.
At the moment, the file is going to be deleted independent of whether
is still unchanged or not. There is no way to find out from the
output. However, subversion has all the information to give this
Of course, a real 'move' would solve this problem, too, but I think
including such a warning would be a very helpful intermediate
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Wed Mar 16 12:04:31 2005