How to organize control access to source code ?

[Succelus]

Hello,
How can we organize development team with code source control policy,
that limit access to some portion of code ?

Sincerely,

Ahmed Boukhari

 

[Erik Jones]

Hello,
How can we organize development team with code source control policy,
that limit access to some portion of code ?

The specifics largely depend on the system(s) you're working with
but, basically (sic), you need to read up on filesystem level
permissions.

Erik Jones

Software Developer | Emma®
(e-mail address removed)
800.595.4401 or 615.292.5888
615.292.0777 (fax)

Emma helps organizations everywhere communicate & market in style.
Visit us online at http://www.myemma.com

 

[Succelus]

The specifics largely depend on the system(s) you're working with
but, basically (sic), you need to read up on filesystem level
permissions.

Thanks for your response,
But I want to know if there is a process or best practices, to give
not the access to all of the project. in other words, must every
developer work on the entire copy of the project locally ?

Or to work just on his module and manage a process of integration, and
if there is any Agile practices for this problem.

 

[Bruno Desthuilliers]

(e-mail address removed) a écrit :

Hello,
How can we organize development team with code source control policy,
that limit access to some portion of code ?

The question may be of interest, but I'm afraid I don't understand how
it relates to Python ???

 

[James Stroud]

Thanks for your response,
But I want to know if there is a process or best practices, to give
not the access to all of the project. in other words, must every
developer work on the entire copy of the project locally ?

Or to work just on his module and manage a process of integration, and
if there is any Agile practices for this problem.

My Understanding of Corporate Software Practices Amounts To:

Map out the whole project and divide it up, specifying the interface for
each "module"--formalized by explicit documentation. Then the individual
programmers program to the interfaces of said modules without worrying
about their implementation.

PHBs can then use threats of shooting, stabbing,
slips-of-paper-strongly-worded-with-copies-to-upper-management,
pointing-and-laughing, or sometimes even plain-ole permissions settings
to make sure no one else peeks at anyone else's code. Catbert will
mediate negotiations with the union.

James

 

[Paul Boddie]

Thanks for your response,
But I want to know if there is a process or best practices, to give
not the access to all of the project. in other words, must every
developer work on the entire copy of the project locally ?

You probably want to split the project up into several individual
projects (as perceived from a technical perspective), which can then
be protected using whichever mechanisms are available. Not only will
it be easier to introduce various access controls - for example, you
might have a bunch of different CVS modules (or similar things) which
are then easier to administer and apply access controls to - but
you'll also reduce the undesirable side-effects that come with a
monolithic project with lots of people hacking on different stuff that
inadvertently breaks other stuff.

Or to work just on his module and manage a process of integration, and
if there is any Agile practices for this problem.

I'm not sure what the overlap is between "agile development" and
restrictive access controls, but another approach might be to use a
totally distributed version control system and then manage the
restrictions when merging changes. You'd probably remain "agile"
whilst exercising the control you require.

Paul

 

[Cameron Laird]

You probably want to split the project up into several individual
projects (as perceived from a technical perspective), which can then
be protected using whichever mechanisms are available. Not only will
it be easier to introduce various access controls - for example, you
might have a bunch of different CVS modules (or similar things) which
are then easier to administer and apply access controls to - but
you'll also reduce the undesirable side-effects that come with a
monolithic project with lots of people hacking on different stuff that
inadvertently breaks other stuff.


I'm not sure what the overlap is between "agile development" and
restrictive access controls, but another approach might be to use a
totally distributed version control system and then manage the
restrictions when merging changes. You'd probably remain "agile"
whilst exercising the control you require.

Paul

I think the answers to this point are missing emphases I can't make
the time now to articulate. The prospects are actually better than
what we've been saying: individual developers *do* have access to
everything (and they like that), but the authoritative version of
the software is the one sequestered away in the version control
system, and you gain all sorts of access control and auditability
through *that* mechanism. So: I think what the original questioner
needs to do is read up on version control and configuration manage-
ment. <URL: http://www.unixreview.com/documents/s=8472/ur0308f/ >,
for example, is very light background reading that I suspect the
original questioner does not yet have.

 

[Paul Rubin]

The question may be of interest, but I'm afraid I don't understand how
it relates to Python ???

It sounds like a reasonable application of multiple Mercurial
repositories. Mercurial is a distributed source control system
written in Python. Does that count?

 

[Bruno Desthuilliers]

Paul Rubin a écrit :

It sounds like a reasonable application of multiple Mercurial
repositories. Mercurial is a distributed source control system
written in Python. Does that count?

Hmmm, let's see... The reference implementation of Python is written in
C. Should we then post Python-related questions on c.l.c ?-)