[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Unnoticed conflicts when moving or deleting

From: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2005-04-17 04:34:33 CEST

On Apr 16, 2005, at 9:24 PM, Branko Čibej wrote:

> Ben Collins-Sussman wrote:
>> On Apr 16, 2005, at 6:02 PM, Ingo Adler wrote:
>>>> It's not marked as a conflict, but the data isn't lost either. The
>>>> file becomes unversioned.
>>> Information is lost. Is data information?
>> How is information lost? Subversion certainly isn't losing any
>> information. The edited file becomes unversioned, but nothing's
>> *deleting* that data.
> Ben, don't you think you're taking a slightly too relaxed view of this
> bug?

Maybe so. I'm not arguing that there's no bug here, there's definitely
a bug. But on the other hand, we've gotten along for 5 years with it
too, with no huge detrimental results. So I don't feel like this is a
P-1 fire to put out.

> Let's take a slightly more complex change, where the file gets both
> renamed and modified in the repository. You update, your local chages
> become unversioned ... and there's no way to merge the changes into
> the renamed file without using external diff/patch tools. I call that
> fundamentally broken.

Agreed, the behavior is broken and unfriendly to users. But no data is
lost. That's what I'm challenging. It may be "mentally lost" in the
shuffle, but not *actually* deleted.

>> Another possible solution is to just have 'svn update' bail out when
>> it tries to delete a file that has local edits. It's already bails
>> out when it tries to add a file that already exists. Maybe that's
>> just the simplest thing to do... in both cases, the user has to move
>> the file out of the way before resuming the update.
> This could work, *if* the user could just reproduce the "svn mv"
> locally and have the next update merge the contents of the renamed
> file.

Forget about the move scenario, it's just a more complex example of the
unfriendly deletion behavior. Even if svn had true-moves, and the
server were able to make libsvn_wc really move things during an update,
the problem will still exist in the simplest form: that is, 'svn up'
trying to delete a modified file. That's what we should focus on.

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Apr 17 04:36:15 2005

This is an archived mail posted to the Subversion Dev mailing list.