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.
>
>>> The developers who get conflict, know that they have a problem and
>>> that they have to handle it.
>>
>> Well, running 'svn status' will show the old file as '?', so there's
>> still an indication that *something* is new in the working copy.
>
> The developer didn't add anything. Why should there be anything new?
> We have big trees of source files (Java development). We wouldn't know
> where to run svn status.
Your developers don't run 'svn status' before they commit, to see what
they're committing? Even GUIs show you what you're about to commit,
which includes displaying unversioned files.
> Modern IDEs wouldn't notice because either they add your file to
> Subversion when you create it or they'll ignore it forever.
I don't understand what you mean here. Are you saying there's an IDE
out there which doesn't display unversioned files?
>
> Isn't it a textual conflict too? Someone deleted the whole content of
> a file - someone else changed a view lines.
> OK - I know that there is a difference between an empty file and no
> file. But why is it so important for a conflict?
>
The problem is that libsvn_wc currently has a narrow definition of a
conflict: it thinks that a conflict is always the result of trying to
merge 3 files. Even if there are no conflict markers, it expects to
create 3 fulltext backup files.
So, one possible solution is to expand the design so that a file can be
in a state of conflict, yet somehow indicate to the user that the
server wants to delete the file; that's definitely not the same as
saying, "the server wants the file to be empty".
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.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Apr 17 03:46:45 2005