On Thu, Aug 18, 2011 at 08:41:44PM +0200, Stein Somers wrote:
> On 18-Aug-11 19:05, Daniel Shahaf wrote:
> >What copyfrom would the single directory have, in the case of an add/add
> >conflict?
>
> The same as if you resolve an add/add file conflict by manually
> throwing the two file contents into one file: you may wish a double
> copyfrom, to trace back to both origins later. I bet our beloved SVN
> developers are not eager to support multiple copyfroms, so at most
> one of them gets the honor.
Indeed, multiple copyfroms would be nasty.
But I don't see the need. Because, ideally, copyfrom info should always point
to a node in the same branch, even if the copy was merged from another branch.
> To be accurate, the first add/add resolution strategy has three subplots:
> - put all files in the same directory ("Markus Schaber's strategy")
> - and pretend it's a copy from local
> - and pretend it's a copy from incoming
> - and pretend it's brand new
I think a copy source should always be from the local branch, or an add if
no suitable copy source node exists in the local branch. The copy source
will exist, at least it the branch's history, if the branches have common
ancestry and all revisions are merged (i.e. no cherry-picking).
But it won't exist in all cases. Hence the current strategy of having
the copyfrom point to the merge source. It is an easy way out but I
don't like it. It is the most reasonable thing to do if you don't want
to worry about copy sources that don't exist, but it's quite stupid and
non-intuitive at the semantic level.
> In any case, even if there was an automatic add/add resolution for
> directories, it's still possible to have an add/add conflict of a
> directory versus a file, and I dare Markus to come up with an
> automatic resolution for that...
Agreed. The tool should not try to outsmart people in complicated
cases like this. Whenever there is more than one option to resolve
a conflict, all options should be offered.
Received on 2011-08-18 21:02:05 CEST