headers
Ross J. Reedstrom | 9 May 22:54
Favicon
Gravatar

[Trac] Limiting trac subversion access


Hey all  - 
Is there some way to 'hide' a subtree in subversion from trac?  We'd
like to have a 'scratchpad' area for people to commit works in progress
that aren't exactly ready for general use.

Ross
--

-- 
Ross Reedstrom, Ph.D.                                 reedstrm@...
Systems Engineer & Admin, Research Scientist        phone: 713-348-6166
The Connexions Project      http://cnx.org            fax: 713-348-3665
Rice University MS-375, Houston, TX 77005
GPG Key fingerprint = F023 82C8 9B0E 2CC6 0D8E  F888 D3AE 810E 88F0 BEDE
On Fri, May 09, 2008 at 01:39:04PM -0700, Brett wrote:

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Trac Users" group.
To post to this group, send email to trac-users@...
To unsubscribe from this group, send email to trac-users-unsubscribe@...
For more options, visit this group at http://groups.google.com/group/trac-users?hl=en
-~----------~----~----~----~------~----~------~--~---
Permalink | Reply |
headers
Jason Winnebeck | 12 May 16:45
Picon
Favicon

[Trac] Re: Limiting trac subversion access


-----Original Message-----
From: Ross J. Reedstrom
Sent: Friday, May 09, 2008 4:55 PM

Hey all  - 
Is there some way to 'hide' a subtree in subversion from trac?  We'd
like to have a 'scratchpad' area for people to commit works in progress
that aren't exactly ready for general use.

Ross

--------------------------

You can use authz permissions files with Trac. They have the same format
and purpose as the authz files used by Subversion.

I am assuming that you aren't trying to say that people shouldn't have
permissions to see the scratchpad area through SVN; just that they don't
see it through Trac. Normally, you give SVN and Trac the same file to
enforce permissions, but you don't have to and in your case you don't
want to. You could create an authz file that "denied" access to
scratchpad for all users and give that to Trac, and then the existence
of that directory will disappear from the browser and timeline.

However, if this is your intention, you may want to reconsider. Trac is
a collaboration tool between developers. Maybe they want to watch the
timeline to see what other people are working on so that they can
contribute. Maybe the want to browse the scratchpad through a web
interface instead of checking out the whole folder. If you're saying
(Continue reading)

Permalink | Reply |
headers
Ross J. Reedstrom | 12 May 17:27
Favicon
Gravatar

[Trac] Re: Limiting trac subversion access


On Mon, May 12, 2008 at 10:45:13AM -0400, Jason Winnebeck wrote:
<snip helpful advice on how to split the authz>

> However, if this is your intention, you may want to reconsider. Trac is
> a collaboration tool between developers. Maybe they want to watch the
> timeline to see what other people are working on so that they can
> contribute. Maybe the want to browse the scratchpad through a web
> interface instead of checking out the whole folder. If you're saying
> that it should be blocked so that no one can collaborate on that folder,
> no one wants to see the folder, and it contains code that's not ready,
> then what is the purpose of having it in version control?

Not everyone is comfortable working in the 'fishbowl', as it where.
There are also those who never want to 'release' anything that's not
perfectly polished, or those who think everything is a 'one-off' that no
one will ever need again. Differing opinions as to what's 'reasonable'
or 'worthy' to checkin. I've already disabled commit-emails for this
tree. This removes another potential objection to checking
works-in-progress into svn, where we get lots of benefits other than
just collaborative access.  If VCS was only about collaboration, there'd
be no reason for the individual developer to use one. Clearly, that's
not the case. History tracking, developer-hit-by-a-bus replacement,
oops, I sure hope the backups are good ... 

If someone finds they want to refer to 'scratchpad' code, that's a good
argument to 'promote' it into the regular tree. We're not talking
branch, here, just very rough notes, etc. Yes, this could become a
barrier to external collaboration. But less so than files in a folder in
a homedir.  That's a management/policy issue, not a technical one.
(Continue reading)

Permalink | Reply |
headers
Jennifer A. Drummond | 12 May 18:09
Picon
Favicon

[Trac] Re: Limiting trac subversion access


On Mon, May 12, 2008 at 10:27:11AM -0500, Ross J. Reedstrom wrote:
> 
> On Mon, May 12, 2008 at 10:45:13AM -0400, Jason Winnebeck wrote:
> <snip helpful advice on how to split the authz>
>  
> > However, if this is your intention, you may want to reconsider. Trac is
> > a collaboration tool between developers. Maybe they want to watch the
> > timeline to see what other people are working on so that they can
> > contribute. Maybe the want to browse the scratchpad through a web
> > interface instead of checking out the whole folder. If you're saying
> > that it should be blocked so that no one can collaborate on that folder,
> > no one wants to see the folder, and it contains code that's not ready,
> > then what is the purpose of having it in version control?
> 
> Not everyone is comfortable working in the 'fishbowl', as it where.
> There are also those who never want to 'release' anything that's not
> perfectly polished, or those who think everything is a 'one-off' that no
> one will ever need again. Differing opinions as to what's 'reasonable'
> or 'worthy' to checkin. I've already disabled commit-emails for this
> tree. This removes another potential objection to checking
> works-in-progress into svn, where we get lots of benefits other than
> just collaborative access.  If VCS was only about collaboration, there'd
> be no reason for the individual developer to use one. Clearly, that's
> not the case. History tracking, developer-hit-by-a-bus replacement,
> oops, I sure hope the backups are good ... 
> 
> If someone finds they want to refer to 'scratchpad' code, that's a good
> argument to 'promote' it into the regular tree. We're not talking
> branch, here, just very rough notes, etc. Yes, this could become a
(Continue reading)

Permalink | Reply |
headers
Matt Good | 13 May 09:21

[Trac] Re: Limiting trac subversion access


On May 12, 9:09 am, "Jennifer A. Drummond" <j...@...> wrote:
> On Mon, May 12, 2008 at 10:27:11AM -0500, Ross J. Reedstrom wrote:
>
> > On Mon, May 12, 2008 at 10:45:13AM -0400, Jason Winnebeck wrote:
> > <snip helpful advice on how to split the authz>
>
> > > However, if this is your intention, you may want to reconsider. Trac is
> > > a collaboration tool between developers. Maybe they want to watch the
> > > timeline to see what other people are working on so that they can
> > > contribute. Maybe the want to browse the scratchpad through a web
> > > interface instead of checking out the whole folder. If you're saying
> > > that it should be blocked so that no one can collaborate on that folder,
> > > no one wants to see the folder, and it contains code that's not ready,
> > > then what is the purpose of having it in version control?
>
> > Not everyone is comfortable working in the 'fishbowl', as it where.
> > There are also those who never want to 'release' anything that's not
> > perfectly polished, or those who think everything is a 'one-off' that no
> > one will ever need again. Differing opinions as to what's 'reasonable'
> > or 'worthy' to checkin. I've already disabled commit-emails for this
> > tree. This removes another potential objection to checking
> > works-in-progress into svn, where we get lots of benefits other than
> > just collaborative access.  If VCS was only about collaboration, there'd
> > be no reason for the individual developer to use one. Clearly, that's
> > not the case. History tracking, developer-hit-by-a-bus replacement,
> > oops, I sure hope the backups are good ...
>
> > If someone finds they want to refer to 'scratchpad' code, that's a good
> > argument to 'promote' it into the regular tree. We're not talking
(Continue reading)

Permalink | Reply |
headers
Christian Boos | 13 May 09:31
Picon
Favicon

[Trac] Re: Limiting trac subversion access


Matt Good wrote:
> On May 12, 9:09 am, "Jennifer A. Drummond" <j...@...> wrote:
>   
>> On Mon, May 12, 2008 at 10:27:11AM -0500, Ross J. Reedstrom wrote:
>>
>>     
>>> On Mon, May 12, 2008 at 10:45:13AM -0400, Jason Winnebeck wrote:
>>> <snip helpful advice on how to split the authz>
>>>       
>>>> However, if this is your intention, you may want to reconsider. Trac is
>>>> a collaboration tool between developers. Maybe they want to watch the
>>>> timeline to see what other people are working on so that they can
>>>> contribute. Maybe the want to browse the scratchpad through a web
>>>> interface instead of checking out the whole folder. If you're saying
>>>> that it should be blocked so that no one can collaborate on that folder,
>>>> no one wants to see the folder, and it contains code that's not ready,
>>>> then what is the purpose of having it in version control?
>>>>         
>>> Not everyone is comfortable working in the 'fishbowl', as it where.
>>> There are also those who never want to 'release' anything that's not
>>> perfectly polished, or those who think everything is a 'one-off' that no
>>> one will ever need again. Differing opinions as to what's 'reasonable'
>>> or 'worthy' to checkin. I've already disabled commit-emails for this
>>> tree. This removes another potential objection to checking
>>> works-in-progress into svn, where we get lots of benefits other than
>>> just collaborative access.  If VCS was only about collaboration, there'd
>>> be no reason for the individual developer to use one. Clearly, that's
>>> not the case. History tracking, developer-hit-by-a-bus replacement,
>>> oops, I sure hope the backups are good ...
(Continue reading)

Permalink | Reply |

Gmane