On 1/6/06, Alexey Yudichev <ayud@newmail.ru> wrote:
> > Anyway, I'm pretty sure that deleting the file was the right thing for
> > merge to do in this case, as it was applying the tree delta to the
> > trunk. If you didn't want the file deleted, you have a chance to
> > revert that part of the change before committing.
>
> From point of view of a developer working in a trunk, this is a lost
> 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".
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.
> 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?
-garrett
---------------------------------------------------------------------
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:07:24 2006