On 1/6/06, Alexey Yudichev <ayud@newmail.ru> wrote:
> 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).
Sure, it makes sense for your particular use case, but not for all use
cases, that's what I'm trying to say. In order to know for sure if we
should consider this a conflict or not Subversion really needs some
concept of a "rename", as a distinct operation from "copy and delete".
If something was renamed, then yes, I'm perfectly willing to
stipulare that something should be done to ensure that changes made to
it on the trunk persist after the merge, but Subversion doesn't do
that right now, it copies it and deletes it, which means it's
impossible to tell the difference between a "I deleted it because we
don't need it anymore" and a "I renamed it".
> >> 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 :)
CVS doesn't handle it at all, as CVS doesn't have the ability to
rename files ;-)
-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 02:01:55 2006