David Anderson wrote:
> 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.
That's cool. Never would've occurred to me to try that!
> 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.
Well, the issue is that, up until now, they've just been copying &
renaming the files, and ftp'ing them from the test environment to
production whenever they felt ready to "release". Most of our changes
are maintenance fixes or small feature additions, so this works decently
well--but there are some times where we've got a major project forcing
its way through the pipeline, and things get a bit uglier. Naturally,
I'm of the opinion that, if they get used to using subversion for the
small stuff, then the big stuff won't require them to change how they
work--but I need to convince them of that before the next big project!
:-)
So, to effectively "mimic" the current system, I think I'd need a
client-side wrapper script instead of a hook, which would basically:
copy new file;
svn revert new file to old file;
move old file;
tell svn to ignore old file;
move new file back;
and finally, commit.
Which is, of course, doable...I'll give it some thought, and maybe
bounce it off of one of my more reluctant co-workers.
Thanks,
-David
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Dec 2 13:20:45 2005