Ben Collins-Sussman wrote:
>
> On Apr 16, 2005, at 9:24 PM, Branko Čibej wrote:
>
>> 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.
Maybe you have the perfect file layout from the beginning, maybe you
only have first-class developers. We don't have either. So we have to
refactor our code from time to time, which involves moving and deleting
files.
You claim:
"Directories, renames, and file meta-data are versioned.
Lack of these features is one of the most common complaints against CVS.
..."
Maybe CVS doesn't track the history for moves, but it works much better
in this important and difficult situation: conflicts.
>> 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.
When a "svn commit" would change the state to "?" in some buggy
situation, would this be a P1?
>> 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.
Right.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Apr 17 10:38:52 2005