On Thu, Dec 10, 2009 at 1:17 PM, Tobias Hahn <tobias.hahn_at_ableton.com> wrote:
>> You do not want your version control system removing files
>> willy-nilly. Imagine if someone has private files that contain data
>> used for testing or configuration. Doing a clean revert would get rid
>> of these files too. And, since they're not revisioned, they'll be
>> permanently lost.
>
> I do want to and I know I am not the only one :) I agree I would not be a good default, but I truly really honestly do want that behavior :)
I know you want this behavior, and we understand why you want this
particular behavior at this particular time. The problem is that most
people don't want this behavior at most times. If you give a complete
clean option, people will use it as their default way of doing a
clean. And, they will delete things they don't want even though you
warn them and made them put all sorts of flags and other things not
to.
At one time, I would write shell scripts for people to do this type of
stuff, but many people used my shell script for everyday cleaning of
their work area, and then yelled at me that my script destroyed their
work even though the script did exactly what it was designed to do,
and even though that's what I told people what the script would do and
why they shouldn't use it all the time.
>> * Have a "clean" target in your build system that gets rid of all
>> build artifacts. I configure my build systems to put all artifacts
>> under a "target" directory. Cleaning up builds is simply a matter of
>> removing this directory.
>
> Well, it's test artifacts and not build artifacts, but like I mentioned before that would need to be planned tested etc. and would not be trivial to implement.
No, clean isn't easy to implement, but it is possible and usually can
be done in such a way as not to delete everything except what was
actually created.
>> * Use two working copies and have both of them around at all times.
>> Use one for merging and one for working. The merging working copy
>> would always be clean. You simply have to do a "svn update" and then
>> "svn merge".
>
> Yes, I guess that's possible. But I would prefer having a way to tell subversion to revert my working copy to a clean state. After all, it is a best practice to only merge clean working copies, and so IMHO it is not too absurd if svn supported getting there.
Exactly why best practice tells you to have a second working copy for
merge work. With 1 Tetrabyte drives less than $100, people have more
room on their work PCs than they know what to do with. It's easy to
create an few extra working copies just for things like this. I don't
even bother with "Switch" anymore. Why bother with the confusion? Why
not simply have multiple working directories?
>> * Use a real operating system and not Windows.
> I'm not sure I understand your point here. I am using Mac OSX and we're not talking 300 files, but 60000.
The 100 files in Subversion Repository /300 files in Subversion's
working copy was just to show you one of the main issues with
Subversion: Checkouts on Windows is painfully slow due to the sheer
number of files created. In your case 60,000 files to checkout means
180,000 files created in your working copy. If you have a Windows
machine and anti-virus, you should do the checkout at about noon and
go out for lunch. Heck, you can go out for lunch in Paris and it'll
still be checkout files by the time you come back.
You have a Mac? Then, you have Bourne shell on it. Write yourself a
shell script. Roscoe "Blame me if you accidentally deleted your files"
Tyler suggested a little shell script:
svn status | grep '^?' | awk '{print $2}' | xargs rm -rf
And (confession) I too use an extremely similar little ditty if I need
to clean up my working copy to pure condition. However, I now know the
next time I do that and I accidentally delete files I wanted to keep,
I can blame Roscoe.
--
David Weintraub
qazwart_at_gmail.com
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2429605
Please start new threads on the <users_at_subversion.apache.org> mailing list.
To subscribe to the new list, send an empty e-mail to <users-subscribe_at_subversion.apache.org>.
Received on 2009-12-10 23:15:25 CET