Feature request: inhibit checkout of tags/branches

[Paul Coulson <pa...@coulsonweb.co.uk>]

I have a legacy repo structure that has many projects with their own tags
and branches folders.

Users check out the whole structure as there are common lib references etc,
but they don't need to see the full contents
of tags or branches folders, which can be massive.

I would like a property svn:inhibit (similar to svn:ignore) set on the root
folder
that limits the checkout depth for a folder anywhere in the tree that
matches the inhibit list.

By setting as a property, a new checkout will inherit this property and
limit the checkout depth for the named folders as required.

Users can then checkout particular tag versions as normal if they require
past versions, but an update at the root will not checkout tags or branches
by default.

IMHO this will make the behavior of a tag more like what the SVN manual
says is just a "user friendly name for a revision".
You wouldn't want to check out all revisions on the trunk, so why check out
all revisions for tags by default?

This would be a really cool improvement, as I see the problem has been
mentioned many times on SVN groups.

Re: Feature request: inhibit checkout of tags/branches

[Les Mikesell <le...@gmail.com>]

On Thu, Mar 29, 2012 at 6:19 AM, Paul Coulson <pa...@coulsonweb.co.uk> wrote:
> I have a legacy repo structure that has many projects with their own tags
> and branches folders.
>
> Users check out the whole structure as there are common lib references etc,
> but they don't need to see the full contents
> of tags or branches folders, which can be massive.
>
> I would like a property svn:inhibit (similar to svn:ignore) set on the root
> folder
> that limits the checkout depth for a folder anywhere in the tree that
> matches the inhibit list.
>
> By setting as a property, a new checkout will inherit this property and
> limit the checkout depth for the named folders as required.
>
> Users can then checkout particular tag versions as normal if they require
> past versions, but an update at the root will not checkout tags or branches
> by default.
>
> IMHO this will make the behavior of a tag more like what the SVN manual says
> is just a "user friendly name for a revision".
> You wouldn't want to check out all revisions on the trunk, so why check out
> all revisions for tags by default?
>
> This would be a really cool improvement, as I see the problem has been
> mentioned many times on SVN groups.

Your real issue is that you aren't using externals to pull in the
component references.  Do that and you only need to check out specific
project trunk or branch/tag revision you want at the top level and
your self-inflicted problem goes away.

-- 
   Les Mikesell
     lesmikesell@gmail.com

Re: Feature request: inhibit checkout of tags/branches

[Doug Hunley <do...@gmail.com>]

On Thu, Mar 29, 2012 at 07:49, Nico Kadel-Garcia <nk...@gmail.com> wrote:
> On Thu, Mar 29, 2012 at 7:19 AM, Paul Coulson <pa...@coulsonweb.co.uk> wrote:
>>
>> I have a legacy repo structure that has many projects with their own tags
>> and branches folders.
>>
>> Users check out the whole structure as there are common lib references
>> etc, but they don't need to see the full contents
>> of tags or branches folders, which can be massive.
>>
>> I would like a property svn:inhibit (similar to svn:ignore) set on the
>> root folder
>> that limits the checkout depth for a folder anywhere in the tree that
>> matches the inhibit list.
>
>
> Woof. From the view of a sophisticated user, I don't think it's
> feasible. Access control is built into daemons, mod_dav_svn, svnserver, and
> file:/// access from the subversion client. Weaving in the ability to parse
> the repository characteristics and restrict access on that basis is asking
> for a signigifcant rewrite of the system, and sounds like a really, really,
> destabilizing idea. It certainly wouldn't backport to older Subversion
> server software.
>
> You can do some access control with Apache configurations or access.conf,
> but neither of those will restrict file:/// access. I suggest you pick an
> access method to allow, block all others, and rely on the existing
> structures to do that kind of control on the server  side.

To add to this, once you've removed file:// and everyone is using
http(s) you should look into mod_dontdothat as it was pretty much
built to handle this kind of thing

-- 
Douglas J Hunley (doug.hunley@gmail.com)
Twitter: @hunleyd                                               Web:
douglasjhunley.com
G+: http://goo.gl/sajR3

Re: Feature request: inhibit checkout of tags/branches

[Les Mikesell <le...@gmail.com>]

On Thu, Mar 29, 2012 at 11:50 AM, coolie <pc...@senscient.com> wrote:
> May have given the wrong impression here - its not access control but just
> limiting the depth of checkout to folders matching the list.

Keep in mind that the branches/tags layout in subversion is just a
convention - to subversion itself, they are just more subdirectories
and if you check out the root above multiple projects they are the
same depth as the trunk of the component you might have wanted (aside
from the fact that you probably really do want a tagged version of
that component...).

-- 
  Les Mikesell
    lesmikesell@gmail.com

Re: Feature request: inhibit checkout of tags/branches

[coolie <pc...@senscient.com>]

May have given the wrong impression here - its not access control but just 
limiting the depth of checkout to folders matching the list.

On Thursday, 29 March 2012 12:49:57 UTC+1, Nico Kadel-Garcia wrote:
>
> On Thu, Mar 29, 2012 at 7:19 AM, Paul Coulson <pa...@coulsonweb.co.uk>wrote:
>
>> I have a legacy repo structure that has many projects with their own tags 
>> and branches folders.
>>
>> Users check out the whole structure as there are common lib references 
>> etc, but they don't need to see the full contents
>> of tags or branches folders, which can be massive.
>>
>> I would like a property svn:inhibit (similar to svn:ignore) set on the 
>> root folder
>> that limits the checkout depth for a folder anywhere in the tree that 
>> matches the inhibit list.
>>
>  
> Woof. From the view of a sophisticated user, I don't think it's 
> feasible. Access control is built into daemons, mod_dav_svn, svnserver, and 
> file:/// access from the subversion client. Weaving in the ability to 
> parse the repository characteristics and restrict access on that basis is 
> asking for a signigifcant rewrite of the system, and sounds like a really, 
> really, destabilizing idea. It certainly wouldn't backport to older 
> Subversion server software.
>  
> You can do some access control with Apache configurations or access.conf, 
> but neither of those will restrict file:/// access. I suggest you pick an 
> access method to allow, block all others, and rely on the existing 
> structures to do that kind of control on the server  side. 
>  

Re: Feature request: inhibit checkout of tags/branches

[Nico Kadel-Garcia <nk...@gmail.com>]

On Thu, Mar 29, 2012 at 7:19 AM, Paul Coulson <pa...@coulsonweb.co.uk> wrote:

> I have a legacy repo structure that has many projects with their own tags
> and branches folders.
>
> Users check out the whole structure as there are common lib references
> etc, but they don't need to see the full contents
> of tags or branches folders, which can be massive.
>
> I would like a property svn:inhibit (similar to svn:ignore) set on the
> root folder
> that limits the checkout depth for a folder anywhere in the tree that
> matches the inhibit list.
>

Woof. From the view of a sophisticated user, I don't think it's
feasible. Access control is built into daemons, mod_dav_svn, svnserver, and
file:/// access from the subversion client. Weaving in the ability to parse
the repository characteristics and restrict access on that basis is asking
for a signigifcant rewrite of the system, and sounds like a really, really,
destabilizing idea. It certainly wouldn't backport to older Subversion
server software.

You can do some access control with Apache configurations or access.conf,
but neither of those will restrict file:/// access. I suggest you pick an
access method to allow, block all others, and rely on the existing
structures to do that kind of control on the server  side.