On Fri, Oct 28, 2016 at 10:34 AM, Patrick Steinhardt
<patrick.steinha...@elegosoft.com> wrote:
> On Fri, Oct 28, 2016 at 12:34:44AM +0200, Stefan wrote:
>> On 10/27/2016 21:45, Stefan Sperling wrote:
>> > On Tue, Oct 18, 2016 at 02:22:25PM +0200, Patrick Steinhardt wrote:
>> >> Hi,
>> >>
>> >> finally got around to update my patch regarding checkouts to
>> >> existing directories. The semantics have been changed to accept
>> >> checkouts iff
>> >>
>> >> - the target directory does not exist
>> >> - the target directory is empty
>> >> - the repository to check out is empty
>> >> - the --force flag is given
>> > I think this makes a lot of sense. I just have not yet had time to
>> > review and test your patch. I will try to do so soon.
>> >
>> > Does anyone reading this list have any concerns about this change?
>>
>> I'm +1 on the general design/behavior change. Didn't do a code/patch
>> review, though.
>>
>> On a minor side note:
>> While talking last week on IRC to Daniel, he mentioned (on a different
>> topic) that in general it might be preferable to use a separate explicit
>> command line options to control the exact behavior over one which
>> impacts several behaviors at once. Reflecting that onto this case, it
>> crossed my mind that --allow-non-empty-directory (or --allow-non-empty)
>> might be preferable over adding that behavior to the --force parameter,
>> since the --force parameter has (or in the future might have) other
>> implications in addition to allowing a co into a non-empty directory.
>>
>> Though in this case, I don't have a strong opinion to go one way or the
>> other.
>>
>> Regards,
>> Stefan
>>
>>
>
> I think I agree with introducing a new flag here. Mixing and
> extending semantics of an existing flag surely is not a nice
> route to go. I'd vote for '--allow-non-empty-target'.
I'm wondering if you also need to look at the behaviour of 'svn
update' (which also has a --force flag).
I have a valid use case for updating over an existing non-wc
directory, using 'svn update --force': converting an embedded checkout
into part of a sparse working copy (the embedded checkout was a
mistake, it should have been pulled in by 'svn update' to become part
of a parent (sparse) working copy).
For example:
trunk in repository has three subdirs: a, b, c
user has a sparse wc rooted at trunk, with 'a' as only child
user performs a checkout of 'b' into $wc/b
user does some work in $wc/b, i.e. local mods
user notices $wc/b does not get updated when he runs 'svn update
$wc' ... oops, b should have been part of the sparse parent working
copy
What I do in this case (as the local svn support guy):
- delete or rename $wc/b/.svn
- go to $wc, and run 'svn update --force b'
Result: 'E' notifications (for "exists") for all local files. Local
modifications remain present. Only moves are lost (deletes are now
"missing", and adds are now "unversioned" -- it's easy to fix those).
(btw: usually I only do this if there are no local moves that need to
be preserved)
--
Johan
