On Fri, Sep 30, 2011 at 8:16 PM, Grant <emailgrant_at_gmail.com> wrote:
>
> Right now I'm trying to decide whether or not I should use subversion.
> Hopefully there is a less time-consuming method for making that
> determination.
>
> My goals are to implement a good development framework and to define a
> (changing) list of files which are the only files a developer is
> allowed to either read or write. If I can do that with subversion and
> path-based authorization, I'd like to get an idea of the workflow
> involved. Here is a modified version of my proposed workflow.
> Hopefully it is more intelligent than my last attempt:
>
> 1. I install a subversion server on my dev machine.
> 2. I decide which file or files I want my dev to work on and give him
> read/write access to only those files (and neither read nor write
> access to any other files) via path-based authorization on the
> subversion server.
> 3. The dev uses a subversion client over an encrypted connection to
> edit the permissible files. He can test his changes via http on the
> dev machine.
> 4. Once he is done, I test his changes via http on the dev machine and
> use svn log to look at the specific changes he made.
> 5. I use rsync to copy the changes made to the dev machine's files to
> the production machine.
> 6. Steps 2-5 are repeated.
>
> Is this any better?
No, forget the part about copying/duplicating the subversion
respository. If you are going to use subversion at all, you should
have one authoritative copy of the repository/server. You can make
the developer work on a branch within the repository and you can
either switch the server to a checked out copy of the branch or you
can merge the approved changes back to the trunk. But any way you
approach it, if you don't want a single repository holding all work,
you probably don't want to use subversion.
--
Les Mikesell
lesmikesell_at_gmail.com
Received on 2011-10-01 09:08:17 CEST