On Jun 29, 2006, at 18:54, Les Mikesell wrote:
> On Thu, 2006-06-29 at 11:53 -0400, jason wrote:
>> You've asked the question and gotten several responses saying that
>> you
>> either can't do what you want, or that what you want to do can be
>> done much
>> easier by simply using post-commit hooks to update a working copy
>> that can
>> be served by Apache. Yet you keep arguing.
>>
>> If you think all of those responses are wrong, wouldn't it be
>> easier to go
>> and try it out and if those responses were proved incorrect
>> (unlikely) to
>> provide this new-found knowledge back to the mailing list?
>
> Slight variation on the question: how would you make the site stay
> at a tagged version so untested changes could be committed, then
> tested and tagged when verified? I used to do this with CVS by
> rtagging the tested copy to float a known tag to that version,
> followed
> by an update to the working version, always using the same tag. That
> way it didn't matter if additional untested changes had been
> committed.
> The script also floated a couple of previous-release tags backwards
> so you could always back out to earlier versions without having to
> track any release numbers or tags.
I don't know CVS, but two solutions spring to mind:
1. Have a trunk and a branch. The web site points to a working copy
of the branch. Do active development on trunk. Merge those changes
that are tested and should appear on the site into the branch. In the
post-commit hook, update the working copy of the branch when a commit
happens on the branch.
2. If you want a more hands-on approach, you could make a tag of the
trunk or a branch or whatever version you want to release, and then
"svn switch" the working copy to that tag. We manage our sites this
way. We have a nice script which does the switching for us when we
tell it to. (We don't want our production sites updating themselves
any old time; we want to be there and push the button explicitly.)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Jun 29 19:34:16 2006