[UPHPU] Source Control Questions

[John Anderson]

You can use authz to limit access to certain modules via authz.  Here is an
example of setting up groups and managing a module

[groups]
admins = sontek
mycars = oglzogl, sontek

[/]
@admins = rw
* =

[MyCars:/]
@mycars = rw
@admins = rw
* =



On 12/27/06, Alvaro Carrasco <alvaro at epliant.com> wrote:
>
> Hi,
> I have setup all of these things using subversion.
> >
> > * Each developer should have their own development environment that's
> > independent of everything else.
> Every developer would checkout a copy of the code that they can edit and
> run (and trash) on their own machine
> >
> > * The development environment should play nice with using
> > $_SERVER['DOCUMENT_ROOT'] to include files.  I'm thinking of giving
> > each dev their own vhost for this.
> good idea...
> >
> > * I'd like the ability to review code before it gets committed, to
> > prevent obvious stupidities from getting into production code
> You would have a development branch (trunk) and a release branch
> (branches/stable?), so developers would commit to the trunk and after
> you have reviewed the changes, you can merge them to the stable branch.
> The production code would just be a checkout of the stable branch.
> >
> > * I don't want to look at diffs when reviewing code - I'd like to see
> > the old file and the new file side by side with differences
> > highlighted.
> >
> If you use windows, TortoiseSVN will give you side by side comparisons.
> Eclipse's Team Syncronization perspective will do the same. And i'm sure
> there are other tools you can use.
> > * Production code should be separate from our code repository - I
> > should check out the code into our production server the same way
> > people check out code to work on it locally.
> Again, trunk and stable branches.
> >
> > * I want to be able to keep some files "hidden" from some developers -
> > specifically the files that contain our DB password info, credit card
> > gateway info, etc.  They would need to stay in the live code and/or
> > the repository, but not get checked out along with everything else
> > when someone grabs the code.
> You can use the svn:ignore property to ignore files. This setting is
> stored on the repository, so you only need to set it once.
> >
> > * Expanding upon that, it'd be nice if I could just give someone
> > access to certain parts of the code and not others.
> >
> A little more difficult, but you can do it using hooks. I've set this up
> before and once you learn how to use the hooks, you can do all kinds of
> cool things, like automatically running unit tests after each commit,
> sending email notifications after every commit, checking user
> permissions before each commit, etc.
>
> Good luck,
> Alvaro
>
>
>
>
>
> _______________________________________________
>
> UPHPU mailing list
> UPHPU at uphpu.org
> http://uphpu.org/mailman/listinfo/uphpu
> IRC: #uphpu on irc.freenode.net
>