Am 10.12.2009 um 18:48 schrieb David Weintraub:
> On Thu, Dec 10, 2009 at 10:52 AM, Tobias Hahn <tobias.hahn_at_ableton.com> wrote:
>> I am frequently unnerved by the fact that revert does not remove unversioned files and directories. I understand that protecting them from accidental deletion is often desirable, but not always. My suggestion is therefore to add a --force option to revert which does a true revert: It reverts the working copy without trying to be smart and just erases everything what's not in the repository.
>>
>> Here's my use case:
>> - I'm working on a branch.
>> - I have a path in my working copy which is modified by some automatic scripts.
>> - About once a week, I merge trunk. To do so, I need a clean working copy. To get it clean, I have to
>> - manually delete all these files (slow and error prone) or
>> - delete the path and checkout again (very slow)
>> - just revert --force it (wishful thinking).
>>
>
> 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 :)
> * 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.
> * 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. OK, you can shoot yourself in the foot with such an option, but do your users also come and complain that rm -rf / just erased all of their work? Again, I'm not arguing that it's a bug in subversion or that it should always behave that way, but rather that I and maybe some more users would appreciate this as a feature. 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.
> * Use a real operating system and not Windows. Okay, Windows is a real
> operating system, but it can be slow when copying files to and from a
> network. Much of this is due to anti-virus programs that have to check
> each and every file that gets created. Subversion makes a lot of files
> whenever you do a checkout. It creates a file to track properties, and
> files to track changes made from the base revision, so each Subversion
> working directory contains 3 times the number of files you're actually
> working on. Checkout 100 files, and Subversion creates 300 files. If
> your anti-virus system is busy checking each of those files, it will
> go through all 300 of those.
I'm not sure I understand your point here. I am using Mac OSX and we're not talking 300 files, but 60000.
Tobias
Ableton AG, Sitz Berlin, Amtsgericht Berlin-Charlottenburg, HRB 72838
Vorstand: Gerhard Behles, Jan Bohl, Bernd Roggendorf
Vorsitzender des Aufsichtsrats: Uwe Struck
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2429275
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 19:28:55 CET