I can work on this tomorrow. All of the items are in place it's just a matter of gathering the following information from each of the people:

        svn user id
        ssh public key

Once I have that information I can create user id's and make the appropriate entries to the access config files.


On May 31, 2006, at 3:59 PM, Philippe Bossut wrote:

Hi,

Just happened that we discussed this at the first Office Hour with Xun this morning. We're also having a bunch of interns coming in in the next few weeks. So, don't want to sound pushy but, how far are we from this to be done?

Let us know if you need some help.

Cheers,
- Philippe

Mike Taylor wrote:
I was already planning on setting up commit access restrictions for the other repositories - just didn't have any external drivers for a deadline.

sounds like I now do :)

Adding the same commit hooks to the other sandboxes will take a day to implement and test.


On May 25, 2006, at 2:25 PM, Ted Leung wrote:

So the question has arisen as to the mechanics of having interns and Summer of Code students work on the various code bases, and we wanted to bring the discussion onto the lists

The issue is that we want the student's work to be available in a public place (that is version control) without granting unearned commit privileges. There are several options for trying to make this happen, none of them ideal (at least in my opinion).

The possible options are:

1. Give each person a private branch in the repository sections for each product

The problem with private branches is that we also grant commit privileges to all of our repositories. Also, it establishes the precedent of giving non-committer private branches and keeping the history of those branches in the version control repository.

2. Give each person a sandbox in <http://svn.osafoundation.org/sandbox/>

The sandboxes have limited access control, which is implemented via a pre-commit hook. Unfortunately, granting commit access to a sandbox also grant commit access to all the other projects, because the main project repositories do not have a pre-commit hook.

3. Have new folks use svk <svk.elixus.org/>, which provides a distributed version control system on top of subversion

The problem with using svk is the need to learn a new toolset and way of working.


My personal opinion is that implementing access control on the repositories via pre-commit hooks is something that we should do anyway and that would solve the problem in the short term.

Ted



_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Open Source Applications Foundation "General" mailing list
http://lists.osafoundation.org/mailman/listinfo/general


---
Bear

Build and Release Engineer
Open Source Applications Foundation (OSAF)
[EMAIL PROTECTED]
http://www.osafoundation.org

[EMAIL PROTECTED]
http://code-bear.com

PGP Fingerprint = 9996 719F 973D B11B E111  D770 9331 E822 40B3 CD29


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

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Open Source Applications Foundation "General" mailing list
http://lists.osafoundation.org/mailman/listinfo/general

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Open Source Applications Foundation "General" mailing list
http://lists.osafoundation.org/mailman/listinfo/general

---
Bear

Build and Release Engineer
Open Source Applications Foundation (OSAF)
[EMAIL PROTECTED]
http://www.osafoundation.org

[EMAIL PROTECTED]
http://code-bear.com

PGP Fingerprint = 9996 719F 973D B11B E111  D770 9331 E822 40B3 CD29


Attachment: PGP.sig
Description: This is a digitally signed message part

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Open Source Applications Foundation "General" mailing list
http://lists.osafoundation.org/mailman/listinfo/general

Reply via email to