On Tue, Dec 18, 2007 at 10:15:33PM +0000, Julian Foad wrote:
>> 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".
The current plan is to just show C in the first coloumn for a directory
containing one or more tree conflicts. AFAIK only the second column is
used for directories so far (to indicate property conflicts on directories).
$ 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
C directory-with-tree-conflict(s)
# This last line is my suggestion for "status".
I haven't yet thought much about what to print for a tree conflict victim,
but I don't think it's necessary to print something special because
commits from tree-conflicted directories will fail anyway, no matter what
the status of files inside it is.
> $ 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.
Yes.
> 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".
Oh, we haven't looked at those Schedule fields 'info' prints yet.
Nice hint, thanks.
> $ svn status -v
> # Could possibly print more info on conflicts than plain "svn status" does.
Currently we have this (I'll try to commit this tomorrow):
stsp@ted [update_tests-44.2] $ pwd
/home/stsp/elego/svn-tree-conflicts-elego-trunk/subversion/tests/cmdline/svn-test-work/working_copies/update_tests-44.2
stsp@ted [update_tests-44.2] $ export PATH=/tmp/svn-tree-conflicts-elego-trunk-prefix/bin:$PATH
stsp@ted [update_tests-44.2] $ svn st
A + A/D/G/pig
D A/D/G/pi
M A/D/G/rho
D A/D/G/tau
A + A/D/G/tiger
stsp@ted [update_tests-44.2] $ svn up
D A/D/G/rho
D A/D/G/tau
A A/D/G/rhino
A A/D/G/tapir
U A/D/G/pi
C A/D/G <--- note the 'C'
Updated to revision 2.
stsp@ted [update_tests-44.2] $ svn help st | grep tree
-t [--show-tree-conflicts] : show tree conflicts in directories, if any.
stsp@ted [update_tests-44.2] $ svn st -t A/D/G
==== Tree conflicts in 'A/D/G' ===
The update wants to delete the file 'rho'
(possibly as part of a rename operation).
You have edited 'rho' locally.
The update wants to delete the file 'tau'
(possibly as part of a rename operation).
You have deleted 'tau' locally.
Maybe you renamed it?
The update wants to edit the file 'pi'.
You have deleted 'pi' locally.
Maybe you renamed it?
stsp@ted [update_tests-44.2] $
Does this look OK?
We still need to add support for xml output.
Also, there is a little catch we haven't fully figured out yet:
case 't':
opt_state.show_tree_conflicts = TRUE;
/* '-t' implies '-v', otherwise svn_wc_client3() won't return
the entries we need. This hack isn't user-visible. */
opt_state.verbose = TRUE;
break;
It's not user-visible because we modified the print function
to only be verbose if -v is set and -t is not.
This is not ideal, but having the tree conflict info output in-between
lines produced by svn status -v does not look very pretty either :-/
Note that we print this from a callback that is called once per file,
so delaying the tree conflict info output to the very end is hard...
> $ 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.)
Interactive resolution will have to come later, I don't think this is
within the scope of our current branch. Very nice idea though.
>> 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.
The API was comitted today, and it is used by "svn st --show-tree-conflicts"
which as already said I plan to commit tomorrow.
>(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.)
For text conflicts, it's safe to assume that the presence of text files
used by the user for resolving (e.g. file.mine) because there is only
ever one text conflict per file. The same applies to property conflicts.
This is different for tree conflicts, because they are rooted at a directory,
and there may happen more than one tree conflict in a single update/merge
operation. Hence the need to track them in the entries file, hence the need
for an API to get at that information.
--
Stefan Sperling <stsp@elego.de> Software Developer
elego Software Solutions GmbH HRB 77719
Gustav-Meyer-Allee 25, Gebaeude 12 Tel: +49 30 23 45 86 96
13355 Berlin Fax: +49 30 23 45 86 95
http://www.elego.de Geschaeftsfuehrer: Olaf Wagner
- application/pgp-signature attachment: stored
Received on Wed Dec 19 00:27:48 2007