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?
> 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".
> 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.
> ### We don't want any svn:mergeinfo recorded.
For WC->WC copies we don't create mergeinfo anymore.
> 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.
> 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.
> ### 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!
But anyway, some comments inline (though I would not object
to simply leaving this section blank during the first iteration).
> ### Should we give a message telling the user to not merge with local
> ### changes in wc?
>
> ### julianf wrote: How can we most easily implement an extension of "svn
> ### merge" that achieves a copyfrom-history-sensitive diff (between WC
> ### items) rather than an unaware diff?
>
> We often have to do a new merge after the original operation. We want to
> rename a file/dir or apply changes elsewhere. Then we don't want to use
> merge-tracking for the subsequent merge operations. More of an
> implementation issue I guess.
Users could use svn merge --ignore-ancestry to merge edits
into a moved file without getting mergeinfo on the file.
>
> Local add, incoming add
> -------------------------
> THEIRS: Replace WORKING with BASE. Merge START to END into WORKING.
Let's assume that the merge is going to add the file before merging
more changes into it. Depending on the type of merge, the file the
merge wants to add may already contain all textual edits made since
the file was created in the remote branch. So something like
"Replace WORKING with INCOMING" is what we want, I think.
> MINE: Keep current WORKING file/dir.
> RENAME-MINE:
> Move WORKING file/dir to <user-suggest>. Merge START to END into
> WORKING.
Again, "Merge START to END into WORKING" is unclear, and probably not
necessary.
>
> Local del, incoming del
> -------------------------
> THEIRS: Nothing to do.
> MINE: Nothing to do.
> ELSEWHERE:
> MERGE START to END from THEIRS <user-suggest> into WORKING
> <user-suggest>.
> ### This will be handled automatically when we can handle moves.
Again, we probably don't want to create subtree mergeinfo
in the ELSEWHERE case.
>
> Local del, incoming edit
> -------------------------
> ### Should we need some way to merge with copyfrom info?
> THEIRS: Copy THEIRS to ACTUAL. Add to WORKING.
> MINE: Nothing to do.
> ELSEWHERE1:
> Merge WORKING add-half onto THEIRS file/dir. Copy THEIRS to
> WORKING delete-half.
> ### This is in case of a move with mods. The user would have to
> ### supply the path to the add-half. Editor-v2 will resolve this
> ### automatically.
> ELSEWHERE2:
> Merge THEIRS file/dir onto WORKING add-half.
> ### The add-half would have to be supplied by the user.
>
> Locale edit, incoming del
> --------------------------
> THEIRS: Remove WORKING file/dir.
> MINE: Nothing to do.
> RENAME1: Merge START to END from THEIRS add-half onto WORKING.
> RENAME2: Merge START to END from WORKING file/dir onto THEIRS add-half.
>
> API changes
> ==================
>
> We have
> --------
> 1) We already know which operations has caused the conflict. It's in
> svn_wc_operation_t. In case some cases will need to differ between sw/up
> and merge which I think will be the case.
>
> 2) We know which type of tree conflict svn_wc_conflict_reason_t,
> svn_wc_conflict_action_t
>
> 3) We have conflict choises already svn_wc_conflict_choise_t {
choiCes
> svn_wc_conflict_choose_postpone
> svn_wc_conflict_choose_base, /* original version */
> svn_wc_conflict_choose_theirs_full, /* incoming version */
> svn_wc_conflict_choose_mine_full, /* own version */
> svn_wc_conflict_choose_theirs_conflict, /* incoming (for conflicted hunks) */
> svn_wc_conflict_choose_mine_conflict, /* own (for conflicted hunks) */
> svn_wc_conflict_choose_merged /* merged version */
> }
>
> 4) A code structure for invoking interactive commands, displaying diffs
> and choosing versions.
>
> 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 :)
>
> 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
> ======================
> TODO:
> We need a way to allow the user to tell us the add-half path of a
> rename.
Looks good to me.
Stefan
Received on 2010-01-22 13:44:43 CET