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.
The file lost its handle to Subversion. You cannot ask it anymore, where
it's gone, who deleted it and so on. I know that you can find the
information somehow. But why should I look for it in the first place.
Don't just think about moving. Think about deletion too. Someone
restructured the code and the changed code moved to another file with
cut and paste.
There is no automatic way to solve this situation. But the developer has
to get a hint, that something important happend.
When the average developer finds the new file, he will add it again,
because he thinks, that either he forgot the file or Subversion lost the
connection somehow.
Or when he doesn't find the new file, he will delete it later (by
getting a clean update or whatever).
In the mean time he will strungle with strange bugs that only he has or
reappearing bugs in the bug reports.
>>>> 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?
Developers rely on their IDE, which lists the changed files before
committing. The important file is not shown, because it's not under
Subversion control anymore. And if it's shown, he'll probably add it again.
I like simple rules:
When a source file is not under version control - add it.
When there is a conflict - solve it, it can be difficult.
Not:
When a source file is not under version control - ask all your
co-workers, if someone moved or deleted it; check the repositiory, if
that's true; wait a few hours maybe someone will remember later; if you
are really certain add it or solve the conflict.
>>
>> 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.
I like the first solution better. It's proven to work in CVS. If you
really need three files, create them with content that states what
happend ("file xy moved to, or file xy deleted").
The second solution (bailing out) is not as good because the developer
wouldn't know where he should merge his changes because he wouldn't get
the moved file's target.
---------------------------------------------------------------------
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:22:07 2005