[
https://issues.apache.org/jira/browse/SVN-4845?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Orgis updated SVN-4845:
------------------------------
Environment: any client (was: 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
{{--allow-mixed-revisions}} switch. Maybe introduce
{{--allow-broken-mergeinfo}} for {{svn commit}}?)
> 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
> {{--allow-mixed-revisions}} switch. Maybe introduce
> {{--allow-broken-mergeinfo}} for {{svn commit}}?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
