Stefan Sperling wrote on Thu, 26 Mar 2020 22:02 +0100:
> On Thu, Mar 26, 2020 at 08:46:35PM +0000, Daniel Shahaf wrote:
> > Stefan Sperling wrote on Thu, 26 Mar 2020 10:45 +0100:
> > > Renames are modelled as copy+delete in SVN.
> >
> > They are, but we can behave differently depending on whether or not the
> > adding-with-history was accompanied by a deletion in the same revision.
> > That is, if cwd is a working copy of foo, we'd behave differently in the
> > case that foo had been created by «svnmucc cp HEAD bar foo» and in the
> > case that foo had been created by «svnmucc cp HEAD bar foo rm bar».
>
> 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.
>
> All instead of requiring the user to simply type one simple argument on
> the command line to run a merge!
Stefan, you're being emotional and you're using strawman arguments. We
don't do that here.
To the point, in cases such as «svnmucc cp HEAD foo bar cp HEAD foo baz
rm foo», we could, as you say, error out and require the user to specify
the URL explicitly. I think that would be reasonable. I think there
are several other things we could specify as the behaviour for this case
that would likewise be reasonable.
At any rate, I don't think that case is very common.
> The ultimate goal here is to allow users to type less characters when
> starting merges. Scripting tab-completion for SVN URL arguments into
> your favourite shell would also be a usable and effective solution.
Received on 2020-03-26 22:33:34 CET