Stefan Sperling wrote:
[...]
> 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.
You already know I'm in favour of this approach.
> Any suggestions about what colour the exact command
> should be?
Natural extensions of the existing commands, I should hope:
To get a brief indication
-------------------------
$ svn status
! file-locally-missing-or-wrong-type
C file-with-text-conflict
C file-with-property-conflict
CC file-with-text-and-property-conflict
CC file-with-tree-conflict
# This last line is my suggestion for "status".
$ svn commit
svn: Commit failed (details follow):
svn: Aborting commit: '/home/julianfoad/tmp/sandbox/file-with-tree-conflict'
remains in conflict
# I think this same message is (and should be) produced for any type of conflict.
To get more detail
------------------
$ svn info file-with-property-conflict
[...]
Schedule: normal
[...]
Conflict Properties File: dir_conflicts.prej
$ svn info file-with-text-conflict
[...]
Schedule: normal
[...]
Conflict Previous Base File: f.r1000
Conflict Previous Working File: f.mine
Conflict Current Base File: f.r1368
$ svn info file-with-tree-conflict
[...]
Schedule: normal
[...]
Conflict Schedule: delete
# This last line is the sort of thing I'd expect in "info".
$ svn status -v
# Could possibly print more info on conflicts than plain "svn status" does.
$ svn resolve
Conflict discovered in 'file-with-tree-conflict'.
M file-with-tree-conflict (mine)
DD file-with-tree-conflict (theirs)
Select: (p)ostpone, (d)iff, (e)dit, (h)elp for more options : d
[... some sort of diff ...]
Select: (p)ostpone, (d)iff, (e)dit, (h)elp for more options : mine
M file-with-tree-conflict
# it's resolved as "mine"
Of course, we don't yet have a "resolve" command, only "resolved"... but we
could have one. (I've been thinking we need one anyway, to be able to re-visit
the resolutions that were postponed during an interactive merge or update.)
For now, would you consider the "info" command a sufficient way to see the
detailed description of the conflict?
> 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.
Definitely. (And if we can define an API to report all types of conflict, not
just tree conflicts, in a consistent way, so much the better.)
> "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?
Absolutely.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Dec 18 23:16:13 2007