> -----Original Message-----
> From: Subversion Newbie [mailto:subversionnewbie@yahoo.com]
> Sent: Tuesday, December 14, 2004 3:35 PM
> To: users@subversion.tigris.org
> Subject: suggestions for Best Practices for SVN with
> staging->development website environment?
>
> I'm trying to "get religion" about the best practices for
> managing a large (i.e., many thousands of files) website with
> SVN in a staging->production environment, and would like to
> get feedback from you fine folks on this list.
>
> The idea is to have the entire contents of the website in a
> repository, and have a script periodically run "svn update"
> under the DocumentRoot of the website to incorporate the
> latest changes into what Apache serves. About twenty people
> will be using Windows and Tortoise/SVN to check out files
> from the repository, edit them on their PCs, and commit them
> back to the repository. A few seconds later they'll view
> their updated
> file(s) on the web (where Apache has found the recently
> update'd files thanks to the "svn update"). So far so good.
>
> The thing is, we want to have a "staging" (or "development")
> website and a "production" website. Ideally, after they're
> satisfied with the way their changes look in the "staging"
> website, users would somehow indicate that those files should
> be propagated to the "production" website. (There would be a
> similar script doing "svn update" under the "production"
> website's DocumentRoot.) I know that this is how one does
> things in a traditional software development environment with
> longer development cycles, but in this case different people
> will be making changes to files all the time, and have to
> incorporate them into the "production" website. We don't
> want users logging in to the server, or set up individual
> "development" environments for each one, or anything like
> that; we want them to check out to their PC (via
> Tortoise/SVN) and edit locally, then commit back.
>
> Branching doesn't make sense because many files are being
> edited all the time by different people; Tags don't seem to
> make sense to me because I can't figure out how to "svn
> update" based on a tag value (and tags don't have a sense of
> history so how would one deal with continually toggling a
> "production" tag value?).
>
> I'm fairly sure many of you out there are running
> environments similar to the one I'm describing, and I'd like
> to know what's the best way to go. Thanks very much in advance.
>
>
>
> __________________________________
> Do you Yahoo!?
> Dress up your holiday email, Hollywood style. Learn more.
> http://celebrity.mail.yahoo.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
>
This will greatly depend on your environment. There are a lot of ways of
doing this. I'm in a Windows server/client environment so my answer
reflects that fact. I couldn't find a pre-made native windows way of
doing this and I wasn't allowed to install PHP or Python for the
pre-made solutions I found, I ended up writing a "control panel" in
ASP.NET that allows the developer to update the staging or live servers
via a web page.
It has a text box for the revision to update and a button to do it. It
also shows the logs for the last 5 commits to the repository. Since it's
ASP.NET and I couldn't find any .NET bindings for subversion (that I
could figure out how to use) it invokes the subversion command-line
client to do the updates and shows the result on the web page. Not ideal
and a little slow but it works fine.
<caveat>
In our environment, the developers test locally, commit supposed working
code (mostly html) and test finally on the "staging" server. That means
that updates to the staging server don't happen often.
</caveat>
This has worked great for me. It allows the developers to roll back
changes to both the staging and live servers without help from me and
has gotten them out of my hair for when they blindly update their live
site with code that doesn't work. Hooray for version control!! All hail
Subversion!!
<reference to different topic>
This is a situation where a working copy without the base copies would
be great for me. Since the developers have no access to these working
copies except through the control panel which only allows "update to
revision", there is no reason to waste all the space for the base
copies. That said, you will have to drag me kicking a screaming back to
working without subversion on websites.
</reference to different topic>
Rick
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Dec 14 22:23:47 2004