3 This file is a scratch pad for working out current and expected
4 behaviors for various tree-conflict situations. It may be considered
5 unfinished at best -- scatterbrained is more like it.
7 NOTE: As Subversion does not actually have real 'move' functionality,
8 please try to express move-ish use-cases in terms of deletes and
9 adds-with-history (copies).
16 This whole thing is, I think, basically about ensuring that the
17 history of a file isn't allowed to fork and then suffer the
18 unceremonious death of one of the two resulting lines of history when
19 the streams are rejoined.
21 When doing an update, we don't have to worry that the working copy
22 base file has deviated from the line of history that's being deleted
23 -- other processes prevent the this from happening (you can't commit
24 to a deleted file; you can't delete a file that's been modified since
25 you last updated). But you do have to worry about local mods, which
26 are a "different path" in the file's line of history than the path
27 that led to its deletion.
29 When doing a merge, though, stuff gets really complicated. Now you
30 have an arbitary line of history as the source which you are trying to
31 "lay down" overtop the line of history of the stuff in your
32 repository, and the goal remains the same: don't assume that
33 deviations in those lines should by resolved by disregarding one side
34 of the fork or the other -- that's ungood. In the best case you are
35 trying to append segments of one fork in the history road to the
36 other, and hopefully you don't leave gaps or cause deviations. In the
37 worst case, though, you're dealing with a "line of history" that's
38 made up on-the-fly (due to your left- and right-side merge sources
39 being unrelated, or only related as second cousins twice removed, or
40 something). This is where the "merge = diff + patch" paradigm really
41 starts to show its weaknesses (and maybe, just maybe, should have been
42 a use-case that Subversion disallowed ... if only it weren't so darned
43 useful for vendor branches...).
45 Anyway, there appear to me to be some pretty clear goals:
47 * Conflicting operations should be marked as such and require user
48 interaction to resolve
50 * In such a conflicting situation, users would like to be able to
51 easily do the following:
53 - determine what local mods they've made
54 - apply those mods elsewhere if necessary
55 - determine what mods conflict with the ones with they
56 - overrule the conflict and make their changes anyway
58 * Tree conflicts appear to be something special, and should be
61 So a tree conflict is really just a conflict on the content of a
62 directory, much like a regular conflict is on the content of a file,
63 and a prop conflict is on the properties of a file or directory. To
64 annotate a tree conflict, we recycle the 'conflict-new' conflict file
65 slot pointing to a dropped file named dir_contents.trej. It's
66 contents can note the details of the tree conflict. [### TODO: Do we
67 need to be able to mark files as tree-conflicted, too?]
74 'svn update' pulls file deletion atop file with local text mods
76 NOW: File is silently unversioned.
78 NEW: File is marked as added-with-history (as of the revision
79 previously in the working copy), and placed into a state of
80 conflict. There are no conflict markers, but the .trej file
81 notes that our file was deleted in the repository. User can
82 see mods with 'svn diff'; revert still works; resolved+commit
83 undoes the deletion and commits the users's mods.
85 'svn update' pulls text mods onto schedule-delete file
87 NOW: Text mods are silently merged into file's text-base and file
88 remains scheduled for deletion.
90 NEW: File remains scheduled for deletion, text-base is up-to-date,
91 but file is marked as conflict, and .trej file notes that
92 the file was modified in the repository.
94 QUESTION: Should .trej file contain the diff of those mods
97 'svn update' pulls dir deletion atop dir containing deep text mods
99 NOW: Directory is removed save for modified files (left
102 NEW: Modified files are marked as added-with-history (as of their
103 working copy revisions), placed into a state of conflict, with
104 .trej files noting the deletion of the parent directory.
105 Intermediate directories are marked as added (no history) and
106 in conflict, with their .trej files noting the deletion of the
109 'svn update' pulls file replacement atop modified file
111 NOW: Behaves as a two-step action: delete over modified file (see
112 above), then file add over existing file (which is obstructed
113 unless --force is provided.
115 NEW: If the 'delete' step goes as recommended above, we'll wind up
116 in a state of conflict already with a schedule-added file.
117 Once the 'add' step hits, the operation will be obstructed
118 even if --force is provided.
120 QUESTION: Is this desirable? What's the final state of the
121 file after the failed update? How do the recovery options
122 play out from here? For example, we wouldn't want the file
123 scheduled for add-with-history because that commit can't
124 succeed (another file already exists in the repository at
127 'svn update' pulls dir replacement atop deep-modified directory
129 'svn update' pulls file-to-dir replacement atop modified file
131 NOW: Behaves as a two-step action: delete over modified file (see
132 above), then directory add over existing file (which is
133 disallowed, even if --force is supplied).
137 'svn update' pulls dir-to-file replacement atop deep-modified directory
139 NOW: Behaves as a two-step action: delete over deep-modified
140 directory (see above), then file add over existing directory
141 left over from delete step (which fails).
145 'svn merge' pulls file deletion
147 NOW: If there's nothing at the target location to delete, the
148 target is "skipped" (?); otherwise the target is removed from
149 version control and, if not locally modified, deleted.
151 NEW: All file deletions that would affect a local file and that come
152 via merge get sanity-checked, with the client pulling the
153 left-side source version of the file down and comparing its
154 contents with the to-be-deleted working file. If they are
155 equivalent and there are no local mods to the file, it is
156 removed from version control. Otherwise, we have two sets of
157 data we'd like to keep easy track of: diffs between
158 deleted-source and wc base file, and diffs between wc base and
160 NOTE: Need more thinkin' 'round these parts...
162 'svn merge' pulls file modification atop schedule-delete file
164 NOW: "Skipped missing target" message.
166 NEW: File remains scheduled for deletion, but working file is
167 restored (if missing), marked as conflicted, and contents
170 'svn merge' pulls file modification atop missing file
172 NOW: "Skipped missing target" message.
176 'svn merge' pulls file modification atop added file