Details
-
Improvement
-
Status: Open
-
Major
-
Resolution: Unresolved
-
1.13.0
-
None
-
None
-
any client
Description
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 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?