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
Received on 2010-02-07 01:23:54 CET