Wrap sqlite3_stmt inside a svn_fs__sqlite_stmt_t struct, which also
[svn.git] / notes / tree-conflicts / scratch-pad.txt
blob64a631eb21820fdcdc830aacec50a9ce05f4649c
1                                -*- text -*-
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).
12 ===================
13 BACKGROUND THOUGHTS
14 ===================
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 
59      annotated as such.
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?]
70 ===================
71 SCENARIO PLAYGROUND
72 ===================
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
95         from the repository?
97 'svn update' pulls dir deletion atop dir containing deep text mods
99   NOW:  Directory is removed save for modified files (left
100         unversioned).
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
107         directory.
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
125         that location).
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).
135   NEW:
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).
143   NEW:  
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
159         wc working files.  
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
168         carry conflict info.
170 'svn merge' pulls file modification atop missing file
172   NOW:  "Skipped missing target" message.
174   NEW:  
176 'svn merge' pulls file modification atop added file
178   NOW:  Conflict!
180   NEW:  Conflict!