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

RE: svn commit: r1501163 - in /subversion/trunk/subversion: include/private/svn_wc_private.h libsvn_client/checkout.c libsvn_wc/adm_files.c

From: Bert Huijben <bert_at_qqmail.nl>
Date: Tue, 9 Jul 2013 12:39:30 +0200

> -----Original Message-----
> From: Bert Huijben [mailto:bert_at_qqmail.nl]
> Sent: dinsdag 9 juli 2013 12:26
> To: dev_at_subversion.apache.org; stsp_at_apache.org
> Subject: RE: svn commit: r1501163 - in /subversion/trunk/subversion:
> include/private/svn_wc_private.h libsvn_client/checkout.c
> libsvn_wc/adm_files.c
>
>
>
> > -----Original Message-----
> > From: stsp_at_apache.org [mailto:stsp_at_apache.org]
> > Sent: dinsdag 9 juli 2013 11:35
> > To: commits_at_subversion.apache.org
> > Subject: svn commit: r1501163 - in /subversion/trunk/subversion:
> > include/private/svn_wc_private.h libsvn_client/checkout.c
> > libsvn_wc/adm_files.c
> >
> > Author: stsp
> > Date: Tue Jul 9 09:35:12 2013
> > New Revision: 1501163
> >
> > URL: http://svn.apache.org/r1501163
> > Log:
> > Allow 'svn checkout' to work within a working copy that is locked.
> > Fixes a regression from 1.7.
> >
> > Reported by: Frank Loeffler <knarf_at_cct lsu edu>
> > See http://svn.haxx.se/users/archive-2013-07/0066.shtml
> >
> > * subversion/include/private/svn_wc_private.h
> > (svn_wc__init_adm): Declare.
> >
> > * subversion/libsvn_client/checkout.c
> > (initialize_area): Use svn_wc__init_adm() instead of
> > svn_wc_ensure_adm4().
> > The latter scans upwards for an existing admin area to check for existing
> > working copies, which we don't need to do when creating a new WC.
> >
> > * subversion/libsvn_wc/adm_files.c
> > (svn_wc__init_adm): New function, a thin wrapper around init_adm().
> > This creates a new admin area at a specified local abspath, without
> > first scanning upwards for an existing admin area. We could also have
> > created svn_wc_ensure_adm5() with a new 'is_checkout' argument, but
> > we're trying to reduce the public set of libsvn_wc API functions.
>
> I haven't tested this, but this currently appears to remove the safety net
> around:
> $ rm trunk
> $ svn co URL trunk
> (which would produce an error and now two working copies)
>
> Or:
> $ svn rm trunk
> $ svn co URL trunk
> (which will now produce two working copies, with the first partially
> obstructed)
>
> Or even:
> $ svn up --set-depth excluded trunk
> $ svn co URL trunk
>
> In all these cases 1.6 would have behaved one way, and with single-db we
> behave in a different way as we don't just attach subdirectories in the parent
> wc.db.
>
> This patch might fix a few use cases, but I don't think it solves a real
> problem... And it might create a whole heap of new proplems

And detecting any of these in a user friendly way would require reading the parent working copy...

... but the only reason you added this patch (as far as I can tell) was because reading the parent working copy wasn't possible?

I think the recommended approach is making sure the parent working copy is readable, instead of trying to do things 100% without the parent working copy.

Doing things without the parent working copy just gives you all kinds of obstruction scenarios where a simple local_abspath doesn't work as that will just describe a path that is now part of two working copies.

I don't think want to go back to the access batons/wc.db per directory where we could describe these paths that are part of two working copy scenarios.

        Bert
Received on 2013-07-09 12:40:33 CEST

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