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]
Received on 2020-03-26 23:21:32 CET