subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grant <>
Subject Re: File access control
Date Sun, 02 Oct 2011 01:07:29 GMT
> Again I strongly encourage you to spend time reading the book. The first several chapters
should solidify for you how people work with Subversion. There's no sense in us explaining
it all here on the list when writers have already spent years refining the words in the book.
But I'll try to summarize a few things briefly anyway:

Thank you Ryan.  Your description is very much illuminating.

> There is a repository -- a database -- that holds your code. The current version and
all past versions, including, if you like, branches. This could be on any server you like
-- the production server, the development server, a completely separate server -- doesn't
really matter. That server will run some kind of Subversion server software -- svnserve perhaps,
or Apache 2 with mod_dav_svn.
> Anyone who works on the code will check out a working copy from the repository onto their
work machine. They will modify the code, then they will test the changes on their local work
machine (which in your case means they will be running a web server and whatever else necessary
to run the web site on their work machine). Once satisfied the changes are correct, they'll
commit the changes back to the repository, with a message describing what they did.

Ouch.  If testing is done on the developer's local machine, he will
need a full working copy and it will be impossible to restrict read
access to one or a few files as I had planned to do with path-based
authz.  Instead, could I check out a working copy of the repository to
a staging machine of mine and allow the developer to check out only
one or a few files as defined via path-based authz, thereby requiring
him to commit his changes and update the staging machine's working
copy in order to test his changes and debug?  I suppose each developer
would require a separate staging machine to work this way.

I'm really getting the square peg round hole feeling.  The workflow
you describe is elegant and very enticing but it gives all of my code
away.  The prevailing attitude seems to be that developers should be
trusted, but this goes against everything I've learned about system
administration where security is taken seriously and trust doesn't cut
it.  I could go the NDA/NCC route but that seems only slightly more
secure than trust to me.

All of the big enterprise websites allow each of their developers to
check out a full working copy of the company code with only an NDA/NCC
to protect them?  It would be so easy for any of them to use, sell, or
give the code away, or even to accidentally allow an unauthorized
person access to it.

- Grant

> At any time you can choose to pull a version of the files from the repository and put
them on a staging web server for testing, or on a production web server. How you do so is
up to you. Generally you would "tag" your code before you put it anywhere, so that you give
that state of the code a meaningful name that can be referred to later as needed.
> If any of the above sounds unfamiliar then you really need to spend more time with the
> The book doesn't specifically address developing web sites with Subversion, but it's
not too difficult. If the web servers can reach the repository server, you can go to the web
server and check out or update a working copy from the repository server directly. If not,
you can use any other computer to get a working copy from the repository, and scp or ftp or
rsync that to the web server. Or you could automate deployment using tools like SVN::Notify::Mirror,
which watches your repository for the creation of tags following a certain naming convention
(that you define) and deploys those versions. (I recommend this approach.)

View raw message