Peter N. Lundblad wrote:
> In r14401, an issue (2224) was fixed making commands like
> svn cp wcdir wcdir
> not get stuck in an infinite loop. This was fixed by allowing this
> operation as a special case. This operation will result in a directory
> wcdir begin created as a child of wcdir (as one could expect).
> Does anyone feel we have to maintain this special case, or is it OK to
> just remove it and fix copy_test 29 to expect failure?
Half of me says "Just remove it; it's silly and shouldn't have been done."
The other half of me says: We keep on coming across situations like this, where
a silly behaviour has been in place and we'd like to remove it. Each
individual case seems fairly harmless, but if we keep on doing this we're going
to end up with a reputation for breaking our compatibility promise. We'll end
up having a Subversion v1.10 that can hardly run any of the scripts that were
written for v1.0, because of a multitude of tiny incompatibilities. Therefore
I think we need to be careful to preserve compatibility when we can.
When we do keep such a quirk for compatibility, I would like to see the main
code written cleanly, without the special behaviour, and a single, clearly
marked compatibility block that implements the special case. Also, ensure that
the documentation (e.g. "svn help", API doc-strings) clearly states that this
is a special case (probably deprecated).
In this case, the behaviour has only been in place since v1.2.0 and was only
announced as "fixed: 'svn copy dir dir' infinite recursion (issue #2224)". To
me, that doesn't imply that any particular behaviour is now specified, so maybe
we could just remove it. On the other hand we can't argue that we can remove
it because it is undocumented, because most of the behaviour of "svn copy" is
undocumented any yet we expect people to discover how it works and use it and
rely on it.
So... I don't know. I just needed to say all that. Either way will suit me in
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Thu Jan 26 03:15:33 2006