[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Feature request - SVN command to clean a working copy of all unversioned and ignored files and directories

From: Giulio Troccoli <giulio.troccoli_at_mediatelgroup.co.uk>
Date: Fri, 09 Mar 2012 14:50:31 +0000

On 09/03/12 14:35, Simon Dean wrote:
>> From: Giulio Troccoli [mailto:giulio.troccoli_at_mediatelgroup.co.uk]
>>
>> Sorry, but to me this has got nothing to do with Subversion. Your CI tool is
>> should clean up itself.
>>
>> Having said that, if someone wants to implement such feature I don't think I
>> would have anything against it. But I doubt it will (be implemented)
>>
>> Giulio
> Thanks for the reply. There are 5 or 6 popular CI tools out there (and there's probably more of them than that). If implemented in the CI tool, each tool would have to implement it for themselves.
>
> Plus a CI tool would have to implement a separate solution for each VCS it supports (e.g. git, perforce, mercurial etc).
>
> As this is a feature that requires an SVN specific implementation and isn't a feature specific to CI builds - it's just a feature to restore a working copy to pristine state - SVN seems like a good place for it?
>
> I suspect developers would also benefit from such a feature on their development PCs too and not just on CI servers?
>

[CC to the list, remember to reply-to-all]

Why would the CI implement a different solution for each VCS? Those, I
understand, are files created during the build process, they have got
nothing to do with SVN or any other VCS. And it's not a SVN specific
implementation as, again, the files were not created by SVN so they've
got nothing to do with it.

 From Subversion's point of view the the WC is absolutely fine. The
unversioned files are ignore and there are no missing files (and if
there are a simple svn up will restore them)

But maybe I'm missing something?
Received on 2012-03-09 15:51:05 CET

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.