feature requests: svn import --overwrite --prune --replicate

Hi,

I don't know if these ideas have already been discussed but anyway here they
are...

I've been messing around with the "svn import" function and I believe that
the following three options could dramatically improve the user experience
while importing vendor branches into a subversion repository

--overwrite

With this option set, rather than having "svn import" spit out an error
message saying "svn: file '/xxx/xxx' already exists", svn would commit the
new file '/xxx/xxx' into the repository replacing the existing '/xxx/xxx'
file.

--prune

With this option set, "svn import" would prune all files and directories
that don't exist in the source directory so that they are correspondingly
removed from the destination directory.

--replicate

With this option set, svn import would perform as if both --overwrite and
--prune had been set.

Why would these options be so cool? Well "--replicate" would allow the user
to import vendor branch directories that are exact replicas of the user's
source directories. Also, it would probably eliminate the need for the
external "svn-load-dirs.pl" perl script in 95% of use cases...

Now, maybe I'm missing something, but it seems that to get this same
"--replicate" functionality today without using the perl script, I'd have
to:

1) svn import my source dir minus all the already existing files

2) svn checkout the destination dir

3) recursively copy my source dir over my destination dir's working copy

4) svn remove all the files and dirs from my destination dir's working copy
that do not exist in my source dir

5) svn commit the destination dir working copy

If you have a better way to achieve the same ends with currently available
commands please tell me...

Please correct me if I'm wrong, but it seems like all it would take, to
implement these options, is some code that would allow "svn import" to
create the requisite metadata on the fly using the source directory and a
connection to the repository, and then to perform a commit by using that
temporary metadata.

From my 50 mile high vantage point, these features seem like they may not be
so hard to implement, since it seems like a) most of the requisite directory
tree comparison stuff has already been implemented for doing the directory
tree change detection during commits and updates and b) most of the
complicated user-side metadata creation stuff has already been implemented
for the simpler case of doing checkouts.

What are your Thoughts? Comments? Questions?

Kind regards,

-Steffen
Received on Fri Dec 12 01:52:21 2003