On May 12, 9:09 am, "Jennifer A. Drummond" <[EMAIL PROTECTED]> 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 > > 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. > > > That's as far as I'm willing to talk about this in a public mailing > > list. :-) > > > Ross > > -- > > Ross Reedstrom, Ph.D. [EMAIL PROTECTED] > > 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 > > I'll make another note, just for the record, that we have a split > between utility scripts and our actual codebase. Even if you have good > SVN discipline for your *code*, developers might feel entitled to be > shyer about their personal bash scripts and sql snippets. Even external > collaborators wouldn't get much, if any, use out of that kind of thing. > It's good to have it in SVN for personal history tracking and/or > eventual promotion, but we don't necessarily want to present it to the > world (or even to each other) as finished "code".
So, you can do what the OP requested by setting up private branches for each user and putting a rule in the authz script that limits access to that branch to that user. This may be ok if there are a few users, but can be a pain if you have a lot of people. An easier option would be for users to keep those types of files in a local repository using Git, Darcs, or some other distributed version control system. These tools are great for versioning files in a local directory which you don't feel like pushing back to a central repository. -- Matt --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Trac Users" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~----------~----~----~----~------~----~------~--~---
