>> 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.
My workflow above only describes a single repository on the dev machine, the production machine wouldn't have a repository. rsync would synchronize the source files, not the repository. - Grant