Re: Outdated check in import?

On 04/19/2012 11:44 AM, Hyrum K Wright wrote:
> This is a good description of the rationale, and I agree that
> committing .svn directories is probably a bad idea. It's just that
> the check quoted above feels woefully single-minded: "Check the
> immediate precursor to the import target, and reject if it is an
> administrative directory. Don't worry about other parents, and don't
> bother with the target itself. Just put the blinders on and focus on
> a single path component."

I *think* this code existed before 'svn import' was modified to do automatic
creation of intermediate parents, so that's certainly one place where the
age of the code has an ill effect. The check should probably be adjusted to
ensure that *none* of the items in the new_entries array is an
administrative directory.

Note that import does also check for .svn/ directories deeper within the
to-be-imported dataset, and skips those (with notification).

> If the objective is to disallow .svn
> directories in the repository, then lets solve the problem generally,
> rather than playing whack-a-mole with 'svn import'.

I'm fine with trying to find a more general solution, but be wary of the
overly general -- that is, the outright overreaching -- solutions.

For example, we could try to tweak our server-side code to disallow .svn/
directories from being versioned. But that misplaces the decision-making
for this situation. Again, the server doesn't care if the repository has
.svn/ directories. To prevent that at the server side would be unnecessary.
 The concern about .svn/ directories in the versioned data set is a client
concern. After all, ".svn" is merely a convention that can be changed with
a small code tweak or the documented SVN_ASP_DOT_NET_HACK approach.

I guess I don't see this as "whack-a-mole with 'svn import'". 'svn import'
is treated uniquely because it is genuinely unique -- no other Subversion
operation tries to directly replicate unversioned data in the repository
without first "staging it" in the working copy state. The only other thing
that comes close is 'svn mkdir URL' (which, by the way, doesn't appear to be
disallowing the creation of .svn/ directories ... oops!).

-- 
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand