Quoting Stefan Sperling <stsp@elego.de>:
> I propose the following:
>
> When an update that caused tree conflicts has completed,
> tree conflict information is stored in the entries file.
> (This is no change of plan).
>
> Now, instead of having a text file that mirrors that state of the data
> in the entries file lying around in the working copy, we could have either
> a separate svn command (unlikely) or an option to an existing svn command
> such as "svn status" or "svn info" display the human readable tree conflict
> description to the user. Any suggestions about what colour the exact command
> should be?
>
> We could also add an libsvn_wc API to query the working copy about
> tree conflict data, so 3rd party tools like tortoiseSVN could easily
> implement their own tree conflict information display, instead of
> having to redirect the user to a text file.
>
> "svn resolved <tree-conflict victim path>" would clear data about
> the tree conflict victim from the entries file, instead of removing
> the user visible file.
>
> Oh, and if the temporary file really is desirable, we can still
> re-add it to the design later. But keeping it in sync with the
> entries file may turn out to be a bit of a burden in the long run...
>
> Does this change sound reasonable?
Yes! And here are two extra reasons to be shy of this temporary file.
Regards,
Steve
1. The temporary marker file is IMHO not a good way to control the
resolution of tree conflicts.
A text or property conflict is marked by unversioned marker files
(with file extensions ".mine", ".copied", ".prej", etc.). If the
marker files have been deleted manually, Subversion will silently
remove the conflict data in the corresponding entries file. In other
word, marker files override Subversion 's internal data. Note that
deleting a single marker file affects only one conflict.
A tree conflict is rather different. Since a tree conflict may refer
to paths that no longer exist in the user's working copy, we store the
conflict data in the parent directory's entries file. A temporary
marker file would naturally list all tree conflicts in the directory.
Deleting the file could affect many conflicts, which may not be
desired.
Manually removing one conflict description from the marker file would
have no effect. Because the descriptions are localized, we can't
reliably parse them to discern the user's intent.
2. The temporary marker file might be locked by the user when we want
to update it.
The safe solution is to create new, unique filenames each time. It
rarely causes confusion for text and property conflicts, because
Subversion generally doesn't have to update the marker files for those
types of conflicts.
For tree conflicts, we expect that user may resolve them one at a
time. This would require refreshing a tree conflict marker file
several times, leading to multiple marker files on disk. It might
not be obvious which file is current.
--
Stephen Butler | Software Developer
elego Software Solutions GmbH
Gustav-Meyer-Allee 25 | 13355 Berlin | Germany
fon: +49 30 2345 8696 | mobile: +49 163 25 45 015
fax: +49 30 2345 8695 | http://www.elegosoft.com
Geschäftsführer: Olaf Wagner | Sitz der Gesellschaft: Berlin
Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Dec 14 10:24:08 2007