>> change. In a big project with many files removed "correctly", i.e.
>> removed in the branch and unchanged in the trunk, this "incorrect"
>> deletion will be lost among them. This can be sometimes acceptable,
>> for example if removal is a result of a large scale refactoring, and
>> the change made in the trunk is no more relevant. In other cases, this
>> can create a long outstanding problem, for example, if the deletion in
>> the branch was made by mistake.
> Sure it can be sometimes unacceptable, but it can also be sometimes
> correct, this is why you have to verify a merge is correct before you
> commit it. Renames and merges are tricky business, but I honestly
> can't see how subversion can do the right thing in 100% of the cases,
> at some point a user needs to look at the diff and say "yep, that
> looks right".
But it seems that all the information is at hand. Subversion knows
that the file was changed in the target tree since starting revision.
I understand however that currently this information is not used.\
Another option would be, before deleting the file, build a diff between staring
revision and an empty file (which will look like all the lines of the
starting revision removed) and try to apply this diff to the local
(trunk) version of the file? In case file was not changed in the trunk
since starting point, this patch would apply cleanly which is the sign
of safe deletion, otherwise it would create a conflict which can and
should be reported. (Hope the idea makes sense).
> One idea that did occur to me is that you can avoid some such issues
> by merging changes from the trunk into the branch prior to merging
> back into the trunk, but in this case you're likely to fall into the
> trap of merge not being especially smart about renames. Hopefully
> that will be fixed in the future, when the work on atomic renames
> within the filesystem happens.
In our case, merging trunk into branch is not acceptable: branch
should not have any changes made in the trunk.
>> Couple of our developers called this feature a show stopper for
>> employing subversion in our company.
> Out of curiosity, do you know of another system that avoids this
> issue? If so, what kind of behavior does it have?
I am curious myself how it is done in CVS. If it isn't any better I
would be satisfied, because this would sound like an argument :)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sat Jan 7 01:51:47 2006