thoughts about a checkout --force option?

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

thoughts about a checkout --force option?

Gary Wilson Jr.-2
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

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: thoughts about a checkout --force option?

Gary Wilson Jr.-2
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: thoughts about a checkout --force option?

Brian W. Fitzpatrick

On May 24, 2005, at 10:19 AM, Gary Wilson Jr wrote:

> 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?

1. If you use --force in your root directory, what if you just blow  
away huge swaths of /etc?

2. There's a pretty easy workaround for putting / into svn:

$ svnadmin create /svn/rootrepos

$ svn co file:///svn/rootrepos /tmp/foo

$ mv /tmp/foo/.svn /

$ cd /

$ svn st

... etc.

-Fitz

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: thoughts about a checkout --force option?

Julian Foad
In reply to this post by Gary Wilson Jr.-2
Gary Wilson Jr wrote:
> 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.

"checkout" is not as simple as "export" because the directories it creates are
Subversion working copies, not just plain directories.  Therefore "Don't
complain about existing directories" is not enough of a specification.  What
should it do with an existing plain directory and its contents when checking
out a WC directory at the same path?  Turn it into a WC, presumably.  What
should it do with an existing WC directory for the same repository and path?
What should it do with an existing directory for a different path or a
different repository?

Let's say that each checked out directory will cause any existing plain
directory of the same name to be converted into a WC, with all its existing
contents kept as unversioned items.  And, if a checked out directory has the
same name as an existing WC directory, that is an error and the command aborts
without altering the existing WC directory in any way.

And, to be clear, each file that is checked out should replace any existing
file of the same name (regardless whether the file's content is the same), and
any other files that already exist on disk should just stay there as
unversioned items.

>>
>>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".

So in this scenario, only plain directories (no Working Copies) exist that
might clash with checked out directories.

>>
>>Several other commands make use of a --force flag, and I believe checkout
>>should be included.

In that sentence you seem to be implying that checkout should have a --force
flag _because_ other commands have it.  That's not a valid argument, because
different commands use it for different purposes.

>>
>>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.

Oh, OK, so you have thought of this, but your use case doesn't have existing
WCs so you don't mind what it does.  I wouldn't make "--force" overwrite
existing WCs unless and until someone demonstrated a good use case for doing so.

I think I would be happy to see the version I sketched above (the two
paragraphs from "Let's say") implemented.  I can help by reviewing the patch if
someone writes one.

- Julian



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: thoughts about a checkout --force option?

Gary Wilson Jr.-2
Julian Foad wrote:

> Gary Wilson Jr wrote:
>
>> 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.
>
>
> "checkout" is not as simple as "export" because the directories it
> creates are Subversion working copies, not just plain directories.
> Therefore "Don't complain about existing directories" is not enough of a
> specification.  What should it do with an existing plain directory and
> its contents when checking out a WC directory at the same path?  Turn it
> into a WC, presumably.  What should it do with an existing WC directory
> for the same repository and path? What should it do with an existing
> directory for a different path or a different repository?
>
> Let's say that each checked out directory will cause any existing plain
> directory of the same name to be converted into a WC, with all its
> existing contents kept as unversioned items.  And, if a checked out
> directory has the same name as an existing WC directory, that is an
> error and the command aborts without altering the existing WC directory
> in any way.
>
> And, to be clear, each file that is checked out should replace any
> existing file of the same name (regardless whether the file's content is
> the same), and any other files that already exist on disk should just
> stay there as unversioned items.

Yes, I agree that is how it should work.

>>>
>>> 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.
>
>
> Oh, OK, so you have thought of this, but your use case doesn't have
> existing WCs so you don't mind what it does.  I wouldn't make "--force"
> overwrite existing WCs unless and until someone demonstrated a good use
> case for doing so.

Yes, I think the main issues here are what the --force flag should force OR
should more than one flag be introduced.

Here are some options:

1) --force
    new files and directories are written and become part of working copy
    overwrite existing files, which become part of working copy
    other already-existing files stay unversioned
    existing directories become become part of working copy
        other already-existing subdirectories and files stay unversioned
        error if directory is already a working copy

Notes: inconsistent with export's --force flag which will overwrite files and
use existing directories (working copy or not).


2) --force
    same as 1) but no error if directory is already a working copy

Notes: consistent with export's --force.  Granted, with export it would be
harder to ruin a working copy, but it would be possible (overwriting local
modifications or metadata for example).  On the other hand, a checkout
implemented this way would necessarily destroy any existing working copy,
turning it into a working copy of the new checkout.


3) --force does 1)
   --force-all does 2)

Notes: introduces two flags instead of one.  Should export's flags change also
for consistency (so that export --force does not export to directories that
are working copies, but a --force-all would)?

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: thoughts about a checkout --force option?

Julian Foad
Gary Wilson Jr wrote:
> Julian Foad wrote:
>>  I wouldn't make "--force"
>>overwrite existing WCs unless and until someone demonstrated a good use
>>case for doing so.
>
> Yes, I think the main issues here are what the --force flag should force OR
> should more than one flag be introduced.
>
> Here are some options:

There's no point in suggesting user interfaces for forcibly overwriting WCs
unless and until we want that behaviour.  Design the functionality of a feature
first, and the user interface afterwards.

Anyway, the "--force" option name is a vague catch-all.  If more that one
option is to be used to control what behaviours are being forced, then the
options should be named according to what they do (e.g.
--overwrite-existing-working-copies), not given more vague names like
"--force-all", "--force-lots", "--force-some", etc.

- Julian

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]