--- Jeff Stuart <furball@weboverdrive.com> wrote:
> As far as I know, with IN SVN, NO. However, my PERSONAL assumption is
> that a tag is ALWAYS read only. :) IE we here all KNOW, when someone
> creates a tag, do not EVER EVER copy anything else into the tag. (IE I
> JUST created a new tag called release for a release of a piece of
> software. For all eternity, you will always be able to refer to it as
> /Tag/release and get the code that we sent out the door at Version 1.0.
> :))
>
> A feature that I want to add on top of SVN at SOME point is some kind of
> automated content management/delivery system. haven't thought it all
> out yet but something like this:
>
> We all are working on a web site. I commit a change to a PHP script.
> It then at a specific time (or when I TELL it to) goes and updates our
> staging server code. Everyone then goes and tests it and says "Yes it
> is GOOD.". I then run ANOTHER command that goes and either Exports or
> just does a copy or something (IE this part I've not REALLY figured out
> at all. LOL) over to the live server.
I see we are thinking along the same lines :-)
My thought is to have information on which files should be accessible in
an XML file "files.xml" (under SVN of course):
<?xml version="1.0"?>
<files xmlns="http://twops.dk/files/1.0">
<dir name="/">
<file name="slam.html">
<active from="20020801T0000" to="20020831" tag="/version/23" />
<active from="20020901T0000" to="infinity" tag="/version/25" />
</file>
<dir name="images">
<file name="bam.gif">
<active from="20020801T0000" to="20020831" tag="/version/23" />
<active from="20020901T0000" to="infinity" tag="/version/25" />
</file>
</dir>
</dir>
</files>
When a change is commited to this file it is immediately svn-updated on
any servers that need it (or it could be accessed through HTTP).
I would probably have a branch for test and production:
[Repository]/releases/trunk/files.xml
[Repository]/releases/test/files.xml
[Repository]/releases/prod/files.xml
One would only edit files.xml in the trunk, and copy it to test or prod when needed.
So the production site would use files.xml from [Repository]/files/prod/files.xml.
The version numbers in files.xml are not revision numbers (i know that now :-).
So when the server needs slam.html the tag is looked up in files.xml. If it
already has that version of slam.html in cache it can use that, knowing that
it has not changed. This is especially important if further processing is needed
(ex. an XSLT transformation) before it is served to the user.
Any thoughts?
> There could also be a web page for non programmers to upload changed/new
> files into the staging server and then let em check it in.
>
> And since I can ALWAYS access the repository via http... :) it works
> well for us since we're all remote users.
>
> And ya know.. I JUST had a thought!!!
>
> YOU MIGHT be able to make a portion of the repository read only via
> APACHE!!!
>
> IE something like this:
>
> <Location /Tags/release>
> <LimitExcept GET PROPFIND OPTIONS REPORT>
> deny from all
> </LimitExcept>
> </Location>
>
> This would make it read only for EVERYONE. OR!!!!
>
> <Location /Tags>
> <LimitExcept GET PROPFIND OPTIONS REPORT>
> require user tag-manager
> </LimitExcept>
> </Location>
I'll try that.
> This would make the repository read only to everyone but the tag-manager
> user. Control who has that password and you're in business.
>
> Note: this will NOT work for accessing the repository via the local file
> system.
Of course :-)
> The more I play with SVN, the more AMAZED I am at it's potential!
> Whoever decided to use WebDAV and Apache is a GENIUS! :)
I agree - also SVN is portable, handles binary files (ever tried that with CVS?) and is free :-)
Regards,
Morten Ludvigsen
2-People Software
Denmark
__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Oct 10 10:57:09 2002