Ben Collins-Sussman wrote:
> On Apr 16, 2005, at 2:42 AM, Ingo Adler wrote:
>
>> Szenario:
>> Markus moves a file and commits his changes.
>> Andreas changes the same file in the mean time, updates and commits.
>> There is no conflict no, warning - nothing. The changed files of
>> Andreas are not unter subversion's control anymore - very bad.
>
> This scenario has been described over and over. It's one of our
> classic examples of why subversion needs "true renames" rather than
> copy/delete actions. It's even documented in our merge-tracking
> brainstorm doc, in section C-2:
>
> http://svn.collab.net/repos/svn/trunk/notes/merge-tracking.txt
No - it's not. Maybe when you solve the problems described in that
document my problem is solved too. My problem is not "repeated merging"
and so on.
It's even not "svn merge' needs to track renames better". That would be
a possible solution but not the only one.
CVS doesn't have true renames. It doesn't have this problem either. And
it's merge doesn't track renames at all.
>> This wouldn't happen in CVS. A changed but deleted file is marked as
>> a conflict, which is probably the best way except defining a new state.
>
> It's not marked as a conflict, but the data isn't lost either. The
> file becomes unversioned.
Information is lost. Is data information?
>> 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.
Modern IDEs wouldn't notice because either they add your file to
Subversion when you create it or they'll ignore it forever.
>> What's the solution?
>
> Either wait for svn to implement true move operations, or start a
> discussion about how libsvn_wc might be able to mark the file
> conflicted. It would require some new design; up till now, 'C'
> always represented textual-conflicts, not tree-conflicts.
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?
Ingo.
---------------------------------------------------------------------
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:29:49 2005