You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Nick Vaughan <n....@codestuff.net> on 2007/02/15 12:22:12 UTC

Readonly externals

I was wondering whether it would be possible to provide an option to the
svn:externals property to make svn client mark the local files as
readonly when updating/checking out from the tree pointed to by the
externals.

I am willing to help contribute if this feature would be deemed useful
to other people.

Cheers,

Nick.

PS. I'm not on the dev list so please CC me!

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org


RE: Readonly externals

Posted by Nick Vaughan <n....@codestuff.net>.
> 
> > What I'd like to do is to ensure that SharedLib, when its 
> > checkedout/updated through the svn:externals is marked as readonly. 
> > This serves as a reminder to me if I go to edit the project in my 
> > TheProduct solution that it should really be modified in the Common 
> > solution where I will ensure that it is fully tested, 
> documented, etc, etc.
> 
> Couldn't this be solved with fine-grained authorization?  In 
> other words, checkout TheProduct as a particular user, but 
> then make sure that same user has no write permission to the 
> sharedlibs location?
> 

That is one way of doing it, however that same user might be working on
the shared lib but not through an externals link. 

I'm not trying to limit peoples access to particular projects, but
rather I'd like to make sure that development is done in the correct
place and not through an svn:external link.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org


RE: Readonly externals

Posted by Nick Vaughan <n....@codestuff.net>.
> > 
> > Couldn't this be solved with fine-grained authorization?  In other 
> > words, checkout TheProduct as a particular user, but then make sure 
> > that same user has no write permission to the sharedlibs location?
> 
> The question is not on the server but on the local machine - 
> that is, having the local files being read-only because it is 
> from a read-only external.
> 
> Thus, this is a client-only type of feature.
> 

Exactly, much like the svn:external propery is client-side feature
anyway. It would just be a case of being able to have the svn client
mark the "checked out"/updated files as readonly if the svn:external had
a specific flag attached (not -r as that's already used!).

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org


Re: Readonly externals

Posted by Michael Sinz <Mi...@sinz.org>.
Ben Collins-Sussman wrote:
> On 2/19/07, Nick Vaughan <n....@codestuff.net> wrote:
> 
>> What I'd like to do is to ensure that SharedLib, when its
>> checkedout/updated through the svn:externals is marked as readonly. This
>> serves as a reminder to me if I go to edit the project in my TheProduct
>> solution that it should really be modified in the Common solution where
>> I will ensure that it is fully tested, documented, etc, etc.
> 
> Couldn't this be solved with fine-grained authorization?  In other
> words, checkout TheProduct as a particular user, but then make sure
> that same user has no write permission to the sharedlibs location?

The question is not on the server but on the local machine - that is, having
the local files being read-only because it is from a read-only external.

Thus, this is a client-only type of feature.

-- 
Michael Sinz                     Technology and Engineering Director/Consultant
"Starting Startups"                                mailto:michael.sinz@sinz.org
My place on the web                            http://www.sinz.org/Michael.Sinz

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Readonly externals

Posted by Ben Collins-Sussman <su...@red-bean.com>.
On 2/19/07, Nick Vaughan <n....@codestuff.net> wrote:

> What I'd like to do is to ensure that SharedLib, when its
> checkedout/updated through the svn:externals is marked as readonly. This
> serves as a reminder to me if I go to edit the project in my TheProduct
> solution that it should really be modified in the Common solution where
> I will ensure that it is fully tested, documented, etc, etc.

Couldn't this be solved with fine-grained authorization?  In other
words, checkout TheProduct as a particular user, but then make sure
that same user has no write permission to the sharedlibs location?

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

RE: Readonly externals

Posted by Nick Vaughan <n....@codestuff.net>.
> 
> Can you give some sort of use-case or rationale for this 
> idea?  What's the real problem being solved?
> 

OK, here's an example:

I have a solution called Common which I use to develop, test and debug a
set of common libraries, for example SharedLib.

I have another solution which I use to develop my product which makes
use of SharedLib. I therefore use svn:externals to add SharedLib to the
source tree and I add SharedLib as a project reference to my solution.

What I'd like to do is to ensure that SharedLib, when its
checkedout/updated through the svn:externals is marked as readonly. This
serves as a reminder to me if I go to edit the project in my TheProduct
solution that it should really be modified in the Common solution where
I will ensure that it is fully tested, documented, etc, etc.

This would also be very useful where the external is pinned to a
specific revision where making modifications makes no real sense.

So, for example, the svn:externals could be:

SharedLib -r 205 -readonly
https://svn.sharedlibs.com/repos/sharedlib/trunk

Or something similar.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org


Re: Readonly externals

Posted by Ben Collins-Sussman <su...@red-bean.com>.
On 2/15/07, Nick Vaughan <n....@codestuff.net> wrote:
> I was wondering whether it would be possible to provide an option to the
> svn:externals property to make svn client mark the local files as
> readonly when updating/checking out from the tree pointed to by the
> externals.
>

Can you give some sort of use-case or rationale for this idea?  What's
the real problem being solved?

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Readonly externals

Posted by Peter McNab <mc...@optushome.com.au>.
Nick Vaughan wrote:
> I was wondering whether it would be possible to provide an option to the
> svn:externals property to make svn client mark the local files as
> readonly when updating/checking out from the tree pointed to by the
> externals.
>
>
>   
Hi nick.

I'm not a developer but do stay current with TSVN nightlys.
This is possibly more a client side issue because it's conceivable some 
users within a group will need commit access to svn:externals.
Have you looked at using TSVN hooks?

Another brute force method might be to simply make the externals folder 
readonly to the logged in user but not to the administrator. Very crude 
of course but if its only one or two troublesome users then it might 
suffice.

Peter

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org