On Fri, 2010-01-22, Daniel Näslund wrote: > Hi Stefan! > > Some comments inline and at the end an attempt to show the options given > in the tree conflict resolver.
Hi Daniel. Can you insert a "Terminology" section that says "In this document, WORKING means the user's version, which possibly has text, property and/or tree modifications relative to the BASE; it does not mean the WC-NG database concept that is known as WORKING." Can you post an updated RFC that incorporates the responses to my and Stefan's comments so far? Thanks. - Julian > 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