On Wed, Oct 12, 2016 at 04:49:55PM +0200, Bert Huijben wrote:
> > -----Original Message-----
> > From: Stefan Sperling [mailto:s...@elego.de]
> > Sent: woensdag 12 oktober 2016 16:37
> > To: Patrick Steinhardt <patrick.steinha...@elegosoft.com>
> > Cc: Subversion <firstname.lastname@example.org>
> > Subject: Re: [PATCH] Reject checkouts to existing directory
> > On Wed, Oct 12, 2016 at 04:28:05PM +0200, Patrick Steinhardt wrote:
> > > Hi,
> > >
> > > attached is a patch to reject checkouts to already existing
> > > directories when `--force` is not given. This is according to
> > > `svn co --help`.
> > >
> > > [[
> > > Reject checkout to existing paths without force
> > >
> > > * subversion/svn/checkout-cmd.c:
> > > - (svn_cl__checkout): Reject checkout to existing directory
> > > without --force
> > > ]]
> > Nice catch.
> > It's odd that the actual behaviour and help string don't line up.
> I'm not sure if the behavior you see is actually a bug. The --force flag is
> already used for processing in the update editor and there are cases where I
> would like to turn an existing directory in a checkout, while not invoking
> that behavior. (I prefer conflicts, over just assuming that every file is
> just a modified version of the files already in the directory; the current
> behavior triggered by --force)
> I can see that you might want to have a warning when there is already a
> directory, but I don't think it is the right way to use the --force option
> for this.
> And then there is the feature that svn checkout is restartable when it fails
> after some part of the checkout (just like update)... with this patch
> applied that would also stop being supported.
Prior to version 1.7, Subversion would complain by default if you try to
check out a directory atop an existing directory which contains files or
subdirectories that the checkout itself would have created.
Subversion 1.7 handles this situation differently, allowing the checkout
to proceed but marking any obstructing objects as tree conflicts.
Use the --force option to override this safeguard.
I'm actually surprised that we made this change in 1.7.
If 'svn checkout' sees an existing directory the most likely situation is
that the user has made a mistake. Leaving behind a working copy full of
tree conflicts is hardly useful in this situation. I would expect this to
happen only with a flag such as --force but the default behaviour being
not touch an existing directory.
To allow for the case where 'svn checkout' is restarted we could check if
the existing .svn directory contains a database that matches the repository
location the checkout is reading from. And only then proceed with the update,
but otherwise behave as above.