On Tue, Mar 15, 2005 at 08:43:18AM -0600, Ben Collins-Sussman wrote:
>
> Subversion doesn't have moves; it has copies and deletes. And as a
> result, it can lead to a lot of confusion.
Ok, concerning the copy I see the difference. Actually I was aware of
that, but didn't see the consequence that clear.
> For example, if a user does 'svn mv A B', it's really exactly the same
> as running 'svn cp A B; svn rm A'. Let's say this user then commits
> the change.
> Meanwhile, a different user has made edits to A. He now runs 'svn
> update', and receives not a 'move', but a 'copy and delete' from the
> server. His edited A gets deleted (well, not really -- because it's
> edited, it merely becomes unversioned), and he receives this new file
> called B. But when he looks inside B, he sees it's just a copy of a
> *older* version of A.
Well, does subversion really delete an edited file without giving
a conflict?
However, in my case it's merge instead of update. And the changes in
trunk were committed, so subversion IS aware of the fact that these
files were changed/added since branching. 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.
In my example the changes are deleted without further notice. In a
large project there is no way to keep track of that.
> So no, you're not crazy. Your situation with 'svn merge' is just
> another variant on this. When you 'svn merge' your
> directory-reorganization branch to a different place, you're not
> getting 'moves' of what happens to be there already. You're getting a
> bunch of deletes and adds of older things.
The adds of older things are ok, but the current behaviour when
deleting changed files I would consider as a bug.
Best regards,
Volker
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Mar 15 19:12:51 2005