cboos at neuf
May 13, 2008, 12:31 AM
Post #6 of 6
(23 views)
Permalink
|
Matt Good wrote:
> On May 12, 9:09 am, "Jennifer A. Drummond" <j...@io.com> 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. reeds...@rice.edu
>>> 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.
>
Not to mention that in the latter case, you can also setup your own
local Trac for browsing this local repository and use it for tracking
your own private TODOs and ideas ;-)
-- Christian
--~--~---------~--~----~------------~-------~--~----~
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[at]googlegroups.com
To unsubscribe from this group, send email to trac-users-unsubscribe[at]googlegroups.com
For more options, visit this group at http://groups.google.com/group/trac-users?hl=en
-~----------~----~----~----~------~----~------~--~---
|
