Gale, David wrote:
> Since we support a large manufacturing floor/sales team/etc., deleting
> the production code and doing an "svn export" isn't an option. My best
> thought was to recursively drill through all subdirectories, deleting
> the .svn dirs--which would be a rather ugly manual process, I think. Is
> there a better way?
You can 'svn export .' in the working copy. That will change the working copy
into an export, ie. delete the .svn metadata.
> Also, is it possible to get a dump of the files as they've changed
> within the repository? That is, if a file ("foo.sql") was changed in
> revisions 2, 5, and 9, we'd like to have foo.sql.2, foo.sql.5, and
> foo.sql.9. Is there some easy way to get this information from
> subversion for an entire repository, or would we have to create some
> sort of script to do it?
I don't know of any script that does this currently, but my offhand feel is that
it could be done fairly simply by a tool parsing a dump file/repository. Check
out svndumptool, it already has python classes/functions to wade through a dump
file, that might prove helpful.
> Naturally, I *don't* want to do either of these, but some of the people
> in the team would be more willing to try the system if they knew they'd
> be able to back out if need be...
I believe that Subversion offers enough guarantees of being able to get at your
data with the combination of many layers of APIs exposed by the various
Subversion libs and the documented portable dumpfile format, which you could use
to extract your data if the APIs should become insufficient.
What VCS are you currently using? Another possibility for painless testing would
be to set up a hook script that mirrors changes made to the svn repository into
your other VCS. That way, your team works on Subversion, and should the test be
inconclusive, you can just delete the subversion repository and go back to your
(up-to-date) previous repository.
It does involve more overhead, as you'd be having both VCS systems live at the
same time (and should disable write access to your possibly-legacy VCS, to keep
properly in sync), but overall if your systems can take it resource-wise, that
seems to be the best solution to me.
- Dave.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Dec 2 00:13:45 2005