[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [tree conflicts] Dropping user-visible files from the design

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: 2007-12-18 23:15:33 CET

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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.