Stefan Sperling: > It's not that simple, as the conflict resolver demonstates. > You're not taking cases into account where multiple copies within > a signle revision correspond to a single deletion. > > So if you want to handle that then you must either error out when > the heuristic fails, or morph 'svn merge' into an interactive > question and answer game with the user, much like the conflict > resolver can behave when it finds ambiguity trying to match up > copies and deletions.
I do not think the first usable version should implement such smart logic. Even the most primitive algorithm that uses the source of the last `svn cp', if it has not been `svn rm'ed later, will cover 95% or more of cases when SVN copies are used as true branches, that is as lateral lines of development that are merged back into the trunk when the task is considered complete. OK, let the user specify the source if it has been moved, even though with more work even that can be traced. > All instead of requiring the user to simply type one simple > argument on the command line to run a merge! In a way, yes -- because it is a difference between delegating work to SVN or doing it manually. An SVN developer or contributor can spend, say, five hours and save thousands of hours for the users. > The ultimate goal here is to allow users to type less characters > when starting merges. Not only to type less, but also to think less. In the pure branch usecase, the origin URL may be thought of as being part of the branch metadata, so that sync-merge and reintegraion merge are well-defined without *any* additional arguments: each branch "knows" its parent bow or trunk, from which it sprouts. > Scripting tab-completion for SVN URL arguments into your > favourite shell would also be a usable and effective solution. I do not think it a good idea because there is only one SVN but many shells. There are already similar short-cuts in SVN, such as the caret symbol. They belong to SVN rather than to external automation, because the most basic and frequent operations should be supported natively and in the most efficient manner possible. -- () ascii ribbon campaign - against html e-mail /\ http://preview.tinyurl.com/qcy6mjc [archived]
