[
https://issues.apache.org/jira/browse/SVN-4845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17016223#comment-17016223
]
Thomas Orgis commented on SVN-4845:
-----------------------------------
ML thread: https://svn.haxx.se/dev/archive-2020-01/0085.shtml
> Avoid partial commits that break mergeinfo
> ------------------------------------------
>
> Key: SVN-4845
> URL: https://issues.apache.org/jira/browse/SVN-4845
> Project: Subversion
> Issue Type: Improvement
> Components: cmdline client
> Affects Versions: 1.13.0
> Environment: any client
> Reporter: Thomas Orgis
> Priority: Major
>
> I stumbled over a bogus tree conflict in a merge attempt, and managed to
> create the source of the next tree conflict on the other side while trying to
> get around the bogus tree conflict by committing those parts that merged fine
> and wanting to deal with the concerned conflict later. It did not occur to
> me, as a user, that the mergeinfo system requires the merge to be committed
> with all concerned mergeinfo-carrying entities in one go.
> Or the other way around: as a user, it did not occur to me that it is
> actually _possible_ to break the association of mergeinfo with the merged
> data by selectively committing files, or even directories without the files
> within. Fixing this design is a greater task. An easier target is to tune the
> client (also pointing at GUI clients) in a way that it discourages commits
> that disconnect mergeinfo from corresponding data.
> There is an [IRC
> discussion|https://colabti.org/irclogger/irclogger_log/svn?date=2020-01-13#l18]
> coming to the conclusion that it should actually be feasible to protect the
> user from accidentally breaking mergeinfo this way. I see a similarity to the
> {{merge --allow-mixed-revisions}} switch. Maybe introduce {{svn commit
> --allow-broken-mergeinfo}}?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
