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

Re: thoughts about a checkout --force option?

From: Gary Wilson Jr <gdub_at_ece.utexas.edu>
Date: 2005-05-24 17:19:48 CEST

Gary Wilson Jr wrote:
> I would like to suggest a --force option for svn checkout. It would do the
> same as the --force flag for svn export, namely overwrite existing files and
> don't complain about existing directories.
>
> A quick search through the users list showed at least 3 instances where this
> has been mentioned before, but none I saw had any replies. See:
> http://svn.haxx.se/users/archive-2004-03/1247.shtml
> http://svn.haxx.se/users/archive-2005-04/0538.shtml
> http://svn.haxx.se/users/archive-2005-03/0848.shtml
>
> Here is my use case for suggesting this option:
> On machine A, I am keeping several directories under partial svn control, like
> '/etc' and '/usr/local', using the in-place method as described in the FAQ
> (http://subversion.tigris.org/faq.html#in-place-import). On machine B, I would
> like to checkout the files under version control to '/' so that '/' is now a
> working copy. Currently, this is not possible because the checkout terminates
> with an error like "svn: Failed to add directory 'etc': object of the same name
> already exists".
>
> Several other commands make use of a --force flag, and I believe checkout
> should be included.
>
> Possible issues:
> When trying to checkout to a directory (or subdirectory) that is already a
> working copy. It seems like this is checked on checkout already, but should a
> --force flag also force this? The svn add --force option currently overrides
> the "already a working copy" warning.
>
> Gary

Nobody has any thoughts?

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue May 24 17:24:28 2005

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

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