Hello,
I'd like to stress this stuff - it would be _very_ usefull in automated
builds environment (like ccnet.sf.net). Those environments could have alot
of "build artifacts" that is unversioned files but have to begin with clean
copy. Should we leave cleanup for makefiles? No - we are suppose to prepare
clean environment for builders. Delete all+fresh chekout is _very_ costy
operation and "svn revert -R;svn update" works only sometimes.
Scripts? Ok - they work well. But! Our ccnet is writen in c# and should run
at all platforms, so we'd not force Perl installation. Moreover it should
work on Windows and other platforms where "rm" and "rmtree" commands are not
present. So portability issue. Of course - we could rewrite that script into
c# and incorporate it into our product, but it's simmilar to reinvent the
wheel (need to maintain the code twice)
Is it pottentionally harmfull operation? I dont think so. In our case
(automated environment) there are no files, which should be commited back to
repository, so we know, all local files / changes should be discarded in any
case. In real working copies it could be different, but I think it is
simmilar to revert [in fact what about impement it as revert switch (svn
revert --clean)? ]. So if I type "svn revert" or "svn clean" in mine wc, I'd
like to remove mine local changes (that's why I type it, dont I?)
Martin
btw: give me direct copy, if you have questions, since I'm not subscriber.
> When working on a change that requires a full rebuild to be properly
> tested
> or when making releases would be very helpful to be able to convert an
> existing working copy into what would have resulted from a clean checkout
> from the repository. Svn clean would basicly be a superset of svn
> revert -R.
> In addition to revert, it would delete all unversioned (usually generated)
> files in the working copy.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Mar 21 15:18:03 2005