C. Michael Pilato wrote:
> Julian Foad wrote:
[...]
>> * Update: permits adding a file already scheduled for add
>> subversion/libsvn_wc/update_editor.c: add_file()
>>
>> /* When adding, there should be nothing with this name unless
>> unversioned
>> obstructions are permitted or the obstruction is scheduled for
>> addition
>> without history. */
>>
>> Why do we allow "update" to add a file that is locally scheduled for
>> add-without-history? (And why not also add-with-history?)
>
> The with/without history inconsistency seems odd. The behavior as it
> stands today sounds like it would be useful in one somewhat common
> scenario:
>
> * you make local changes which include adding new files
> * send those changes to someone else as a patch
> * the other person applies and commits the patch
> * you update atop your still-modified working copy
>
> But I'm not sure that one use-case justifies the risk of effectively
> having your local addition automatically and silently transformed into a
> potentially every-line-touching text mod (in the case where the file
> you've added is nothing like the one someone else added).
Good thoughts. Agreed. And I don't suppose that's the only case which wouldn't
work well in a somebody-else-commits-your-patch scenario without more
special-casing. So we can't see much good reason for this.
>> * Update: silently undeletes a deleted file
>> subversion/libsvn_wc/update_editor.c: add_file()
>>
>> /* sussman sez: If we're trying to add a file that's already in
>> `entries' (but not on disk), that's okay. It's probably because
>> the user deleted the working version and ran 'svn up' as a means
>> of getting the file back.
>>
>> This sounds like something we do only because CVS users got used to
>> doing it. Normally, "update" only applies changes that have happened
>> in the repository. It's presumptious to assume that the user didn't
>> actually want the file to go away (but maybe just forgot to use "svn
>> delete").
>
> Nonsense. It's just as presumptuous to assume that just because a file
> has gone missing from a working copy that the user intended to remove
> that item from version control. We don't automatically add new files
> when unversioned ones show up in a working copy tree, do we? Of course
> not. By the same logic, we shouldn't remove files that go missing from
> disk either.
Er... did you read my following paragraph? It said:
> I would like to convert this case to a tree conflict. Is there any
> serious benefit to not doing so, and keeping this special case?
In other words, yes I agree that making the opposite assumption (that it should
be scheduled for delete) would be equally wrong. We can't know what the user
wanted, so we should ask the user what to do.
Better?
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-04-18 15:18:18 CEST