Hi Stefan!
Some comments inline and at the end an attempt to show the options given
in the tree conflict resolver.
On Fri, Jan 22, 2010 at 01:43:51PM +0100, Stefan Sperling wrote:
> On Fri, Jan 22, 2010 at 12:12:26PM +0100, Daniel Näslund wrote:
> > Local add, incoming add
> > -------------------------
> > THEIRS: Put new BASE file/dir in WORKING.
> > MINE: Keep current WORKING file/dir.
>
> In the MINE case, what do you do with the file in BASE which
> the update just brought in? It needs to be deleted because it
> already exists at HEAD in the repository. I think we want
> the WORKING file to replace the file in BASE if the user
> picks the MINE option. Correct?
When we're doing an update, the WORKING files and dirs are rescheduled
to match the state of WORKING before the update. The file in BASE should
be scheduled for deletion.
> > RENAME-MINE:
> > Move WORKING file/dir to <user-suggest>. Replace WORKING
> > file/dir with the BASE-TARGET file/dir.
>
> The file is already added (or maybe even "added with history" in
> wc1 terms). So rather than "moving the added WORKING file",
> we may want to phrase this as "adding the WORKING file at a
> different location".
Ok, I easily forget that a move is really an add and delete action. But
I will be _very_ aware of it if I pursue down this road.
>
> > MERGE Merge BASE file1 onto WORKING file2.
> > ### There may exist copyfrom info and it may not. How handle the
> > ### different cases?
>
> If any copyfrom info is present (i.e. at least one of the files
> was copied), the user needs to select a copyfrom source:
>
> WORKING file | BASE file | Options
> has copyfrom | has copyfrom |
> Yes Yes Pick one copyfrom of 2, or none.
> Yes No Use WORKING copyfrom, or none.
> No Yes Use BASE copyfrom, or none.
I need to think of a good way to present that to the user. There should
probably be an public function that other clients can access. Perhaps
there already is? I don't know of any.
> > Local del, incoming del
> > -------------------------
> > THEIRS: Nothing to do.
> > MINE: Nothing to do.
> > RENAME: If renamed to two different names.
>
> You don't if the file was renamed, let alone if two people
> renamed it to different target paths.
> I'd say just always show the options to handle rename cases
> for deleted files, for now.
>
Ok
> > Merge BASE-TARGET <moved> onto WORKING <moved>.
> > ### We need the user to tell us the add-half of a rename until
>
> It's worse, we need the user to figure out if there was a rename
> at all.
Doh!
> > ### editor-v2 is here. Until then <moved> must be a user suggestion.
> >
> > Local del, incoming edit
> > -------------------------
> > THEIRS: Replace the deleted WORKING file/dir with edited BASE file/dir.
> > MINE: Keep current WORKING file/dir.
> > ELSEWHERE:
> > Merge BASE file/dir onto WORKING <user-suggest>.
> > ### editor-v2 will automatically find a move. No need for this
> > ### option?
>
> Let's keep the option in for now. I hope to get the local move case
> working automatically before 1.7 release. I'm not sure if information
> about local moves is already being recorded in wc-ng right now.
>
> >
> > Local edit, incoming del
> > --------------------------
> > THEIRS: Delete the file/dir from WORKING and ACTUAL.
> > MINE: Keep current WORKING file/dir.
> > MOVE-MY-MODS:
> > Schedule BASE add-half for addition. Merge WORKING file/dir to
> > add-half. (Must be suggested by user. We can't track add-halfs
> > right now.
>
> OK.
>
> >
> > Use cases merge
> > =======================
>
> I think we should get update sorted out completely before
> trying to tackle the merge cases. The merge cases are much
> more complex!
[...]
I will let the merge stuff hang loose for a while. The update scenarios
is more than I can keep in my head. Adding the merge stuff will probably
be too much.
> > API changes
> > ==================
> > We need
> > --------
> > 1) svn_cl__conflict_handler must use svn_wc_conflict_description2_t for
> > some additional tree conflict info.
> >
> > 2) Handle the cases we can in svn_cl__conflict_handler, let the other fall
> > through. (Or return svn_wc_conflict_choose_postpone). I'm thinking of
> > letting all dir conflicts fall through as a first step.
>
> Good idea :)
>
> >
> > 3) Add some choises to svn_wc_conflict_choise_t.
> > svn_wc_conflict_choose_{rename,elsewhere,my_moved_mods}?
>
> Those names confuse me even after reading the above spec :)
Yup, me too!
> >
> > 4) Add calls to eb->conflict_resolver if check_tree_conflict() returns a
> > conflict in:
> > libsvn_wc/update_editor.c
> > do_entry_deletion()
> > add_directory()
> > open_directory()
> > add_file_with_history()
> > open_file()
> > Or are we supposed to call the conflict resolver after we have done the
> > whole operation?
>
> I think resolving as early as possible should be fine.
> If there are problems with this we can worry about it later.
>
> >
> > 5) Create code to handle and execute the svn_wc_conflict_choise_t
> > choises. in libsvn_wc/update_editor.c
> >
> > 6) Test to verify the interactive callback. Some detection tests needs
> > to use the --non-interactive flag.
> >
> > 7) It would be nice to be able to store the THEIRS tree in the wc db
> > when we get a tree conflict during a merge operation.
> >
User interface
======================
I will focus on the update stuff for files. These are the options I'm
suggesting. We need to supply paths at a couple of places. Perhaps some
bash-completion stuff would be useful. We're on the limit here of what's
a good CLI. There shouldn't be too much interactivity.
Perhaps something more than diff-full for viewing changes. Something
like what svn info ^/trunk/conflicting_path, svn info wc_path can
provide?
Local add, incoming add
-------------------------
Tree conflict discovered in 'path'
local add, incoming add upon update
Select: (p) postpone, (df) diff-full,
(mc) mine-conflict, (tc) theirs-conflict,
(mr) mine-rename, (m) merge,
(s) show all options: s
(e) edit - change merged file in an editor
(df) diff-full - show all changes made to merged file
(r) resolved - accept merged version of file
(dc) display-conflict - show all conflicts (ignoring merged version)
(mc) mine-conflict - accept my version for all conflicts (same)
(tc) theirs-conflict - accept their version for all conflicts (same)
(mr) mine-rename <to-path>
- Move my file to <to-path> and put their
file at my files old place
(m) merge - merge their file onto my file. You may be
asked to choose copyfrom
(mf) mine-full - accept my version of entire file (even non-conflicts)
(tf) theirs-full - accept their version of entire file (same)
(p) postpone - mark the conflict to be resolved later
(l) launch - launch external tool to resolve conflict
(s) show all - show this list
Local del, incoming del
-------------------------
Tree conflict discovered in 'path'
local del, incoming del upon update
Select: (p) postpone, (df) diff-full,
(mc) mine-conflict, (tc) theirs-conflict,
(r) rename, (m) merge,
(s) show all options: s
(e) edit - change merged file in an editor
(df) diff-full - show all changes made to merged file
(r) resolved - accept merged version of file
(dc) display-conflict - show all conflicts (ignoring merged version)
(mc) mine-conflict - accept my version for all conflicts (same)
(tc) theirs-conflict - accept their version for all conflicts (same)
(r) rename <from-path> <to-path>
- Move my file to <to-path> and put their
file at my files old place
(m) merge - merge their file onto my file. You may be
asked to choose copyfrom
(mf) mine-full - accept my version of entire file (even non-conflicts)
(tf) theirs-full - accept their version of entire file (same)
(p) postpone - mark the conflict to be resolved later
(s) show all - show this list
Local del, incoming edit
--------------------------
Tree conflict discovered in 'path'
local del, incoming edit upon update
Select: (p) postpone, (df) diff-full,
(mc) mine-conflict, (tc) theirs-conflict,
(me) merge-elsewhere,
(s) show all options: s
(e) edit - change merged file in an editor
(df) diff-full - show all changes made to merged file
(r) resolved - accept merged version of file
(dc) display-conflict - show all conflicts (ignoring merged version)
(mc) mine-conflict - accept my version for all conflicts (same)
(tc) theirs-conflict - accept their version for all conflicts (same)
(mr) mine-rename <to-path>
- Move my file to <to-path> and put their
file at my files old place
(m) merge - merge their file onto my file. You may be
asked to choose copyfrom
(mf) mine-full - accept my version of entire file (even non-conflicts)
(tf) theirs-full - accept their version of entire file (same)
(p) postpone - mark the conflict to be resolved later
(s) show all - show this list
Local edit, incoming del
--------------------------
Tree conflict discovered in 'path'
local edit, incoming del upon update
Select: (p) postpone, (df) diff-full,
(mc) mine-conflict, (tc) theirs-conflict,
(mm) mine-move-mods
(s) show all options: s
(e) edit - change merged file in an editor
(df) diff-full - show all changes made to merged file
(r) resolved - accept merged version of file
(dc) display-conflict - show all conflicts (ignoring merged version)
(mc) mine-conflict - accept my version for all conflicts (same)
(tc) theirs-conflict - accept their version for all conflicts (same)
(m) merge <their-file>- merge my file onto their file.
asked to choose copyfrom
(mf) mine-full - accept my version of entire file (even non-conflicts)
(tf) theirs-full - accept their version of entire file (same)
(p) postpone - mark the conflict to be resolved later
(s) show all - show this list
cheers,
Daniel
Received on 2010-01-22 18:33:44 CET