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

Re: Tree conflicts - command-line UI

From: Stefan Sperling <stsp_at_elego.de>
Date: Mon, 15 Sep 2008 23:00:56 +0200

On Fri, Sep 12, 2008 at 02:48:16PM +0100, Julian Foad wrote:
> Some sketches of what I think the UI should be.
> ...

Some comments inline.

>
> The UI of "svn" with respect to tree conflicts consists of (primarily
> the output of):
>
> RAISE
> - svn update
> - svn switch
> - svn merge
>
> ENQUIRE
> - svn status (1-char/1-line summary)
> - svn info (details)
> - ls, cat (disk state, outside of Subversion)
>
> COMMIT
> - svn commit (failure because of unresolved conflict)
>
> RESOLVE
> - svn resolved
> - svn resolve --accept=X
> - svn up/sw/merge (interactive resolution)

There is a huge can of worms with resolution, and interactive
resolution in particular. This is going to be tricky.

Some cases are simple (e.g. modify vs. delete),
some are not (e.g. modify vs. missing path).

Especially cases which need repeated merges to be resolved are
going to be hairy. Users may end up having to resort to
--record-only reverse-merging individual revisions, or manual
patching of files. See the thread, which is currently still
a monologue, entitled "Mergeinfo for skipped paths?":
http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=142942

You have made a list of resolution recipes based on 1.5 behaviour
in notes/tree-conflicts/resolution.txt. Is this file still current?

>
> XML output is not considered here.
>
> n.b. The "Ready now" output shown here is indicative of what the
> tree-conflicts branch currently does (around now), but not an actual
> transcript.
>
>
> =============================================================
> == RAISE: svn update / switch
> =============================================================
>
> Desired:
> [[[
> $ svn update # incoming mod onto local del
> C parent/victim
> ]]]

So you want 'C' in the first column to mean either
text or tree conflict?

Note that we're currently allowing merges into text-conflicted
files. It's not impossible to run a series of merges that
make a file end up being both text-conflicted and the victim
of a tree conflict.

>
> Ready now:
> [[[
> $ svn update # incoming mod onto local del
> U parent/victim
> C parent
> ]]]
>
> To do:
> - report a conflict only on the victim
> - skip processing in conflicted dirs

+1, only victims should be reported, containing directories
are redundant.

>
> =============================================================
> == RAISE: svn merge
> =============================================================
>

Same as update?

>
> =============================================================
> == ENQUIRE: svn status
> =============================================================
>
> Desired:
> [[[
> $ svn status
> CC parent/victim1
> CC parent/victim2
> ]]]

What is 'CC' supposed to mean?

>
> Ready now:
> [[[
> $ svn status
> A parent/victim1
> M parent/victim2
> C parent
> ]]]
>
> Alternatives:
> - Other status letters (T, V), and/or a third column.

I have not yet made up my mind about this.

>
> =============================================================
> == ENQUIRE: svn info
> =============================================================
>
> Ready now:
> [[[
> $ svn info svn-test-work/working_copies/info_tests-1/A/D/G
> Path: svn-test-work/working_copies/info_tests-1/A/D/G
> URL:
> file:///home/julianfoad/build/subversion-tc3/svn-test-work/repositories/info_tests-1/A/D/G
> Repository Root:
> file:///home/julianfoad/build/subversion-tc3/svn-test-work/repositories/info_tests-1
> Repository UUID: 85eb87c9-d755-0410-942d-75d89e77a365
> Revision: 2
> Node Kind: directory
> Schedule: normal
> Last Changed Author: jrandom
> Last Changed Rev: 2
> Last Changed Date: 2008-09-01 17:06:35 +0100 (Mon, 01 Sep 2008)
> Tree conflicts:
> The update attempted to delete 'rho'
> (possibly as part of a rename operation).
> You have edited 'rho' locally.
>
> The update attempted to delete 'tau'
> (possibly as part of a rename operation).
> You have deleted 'tau' locally.
> Maybe you renamed it?
>
> The update attempted to edit 'pi'.
> You have deleted 'pi' locally.
> Maybe you renamed it?
>
> $ svn info svn-test-work/working_copies/info_tests-1/A/D/G/rho
> [...]
> # nothing unusual shown
> ]]]
>
> Desired:
> - Rather than listing multiple conflicts on a parent dir, list the
> single conflict of which this node is the victim:

+1

> [[[
> Tree Conflict Operation: update
> Tree Conflict Incoming Change: delete
> Tree Conflict Older URL:
> file:///home/julianfoad/build/subversion-tc3/svn-test-work/repositories/info_tests-1/A/D/G/rho_at_120
> Tree Conflict Newer URL:
> file:///home/julianfoad/build/subversion-tc3/svn-test-work/repositories/info_tests-1/A/D/G/rho_at_130
> Tree Conflict Previous Working File: rho.mine
> ]]]
>
> Alternatives:
> - provide copies of the conflicted items, rather than URL_at_REV references
> to them. Or provide both.

I'd say both, if it's not too much effort.
If I had to pick one, I'd pick local copies.

> [[[
> Tree Conflict Operation: update
> Tree Conflict Incoming Change: delete
> Tree Conflict Previous Base File: 'rho.r120'
> Tree Conflict Previous Working File: 'rho.mine'
> Tree Conflict Current Base File: <none>
> ]]]
>
>
> =============================================================
> == ENQUIRE: disk state
> =============================================================
>
> Scenario: incoming edit onto local delete of file 'rho'.
>
> Desired:
> [[[
> $ ls
> # 'rho' is absent: is scheduled for delete
> # 'rho.mine' also absent: was scheduled for delete
> rho.r120
> rho.r130
> ]]]

+1

> Ready now:
> [[[
> $ ls
> rho # but is scheduled for delete!
> ]]]

Oh my, this needs doing!

>
>
> =============================================================
> == COMMIT: failure because of unresolved conflict
> =============================================================
>
> Ready now:
> [[[
> $ svn commit
> svn: Commit failed (details follow):
> svn: Aborting commit: 'tree_conflict_tests-1/branch1/fP' remains in
> conflict
> ]]]
>
> Alternatives:
> - List all the nodes still in conflict.
> - Give full details of each unresolved tree conflict.
>
> Status:
> - Good enough for now.

I'd like to make it at least say what kind of conflict
is causing the problem.

And if it's a tree conflict, it should print the same information
as 'svn info' is printing.

>
>
> =============================================================
> == RESOLVE: svn resolved
> =============================================================
>
> Ready now:
> [[[
> $ svn status
> C branch1/fP
> A + branch1/fP/F2-local
> D branch1/fP/F
>
> $ svn resolved branch1/fP # fP is the parent dir of the victims
> Resolved conflicted state of 'branch1/fP'
> ]]]
>
> To do:
> - The target of the "resolved" command should be a single victim rather
> than a parent dir.

Yes.

I think 'svn resolved' should also accept a parameter to
indicate the type to conflict to be resolved. If an item
has multiple types of conflicts, this parameter should be
mandatory.

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-09-15 23:01:21 CEST

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.