You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Brendan van Drempt <Br...@scholastic.com.au> on 2004/05/27 00:27:19 UTC
Subversion and Project Environments (Dev / Test / Prod)
I am in the processing of setting up Subversion to manage the development of
a website.
Setup:
Subversion Repository on Windows Server machine running SVNserve. Windows
development machines running TortoiseSVN client. (soon to add mac
development machines, when we decide on a suitable mac subversion client)
* What is the best way to implement Subversion across my Dev / Test /
Production sites?
* Should each environment be a 'working copy' of the repository, and then
use a client tool to update to particular revisions? (in addition to the
working copies of the developers)
* Should I be using 'tags' to set releases?
Need a bit of clarity here.
Thanks!
Regards,
Brendan van Drempt
Analyst / Programmer
Email: brendan_vandrempt@scholastic.com.au
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Are MIME/Types worth the config? (was: Subversion and Project
Environments)
Posted by Gary Affonso <gl...@greywether.com>.
On 5/27/04 9:07 AM, "C. Michael Pilato" <cm...@collab.net> wrote:
> Ben Collins-Sussman <su...@collab.net> writes:
>
>> On Thu, 2004-05-27 at 01:15, Gary Affonso wrote:
>>> Which leads me to ask...
>>>
>>> Is there any good reason to go to the work of defining auto-properties to
>>> ensure that things like .jar, .jpg, .gif, etc. are all tagged with the
>>> appropriate mime/type?
> In other words, if your website is only served up via a Subversion
> working copy, then, no, there's no reason to bother with the precise
> mime-type settings. But if you ever want to refer directly to
> Subversion repository URLs, browser presentation will be greatly
> improved for those things.
Ahhhh <nods head> that answers my question. We aren't providing
browser-based access to the repository so this feature didn't make a lot of
sense to me. I get it now. Thanks!
- Gary
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Are MIME/Types worth the config? (was: Subversion and Project Environments)
Posted by "C. Michael Pilato" <cm...@collab.net>.
Ben Collins-Sussman <su...@collab.net> writes:
> On Thu, 2004-05-27 at 01:15, Gary Affonso wrote:
> > Which leads me to ask...
> >
> > Is there any good reason to go to the work of defining auto-properties to
> > ensure that things like .jar, .jpg, .gif, etc. are all tagged with the
> > appropriate mime/type?
> >
> > I can't see any benefit to it for web-sites. As long as the repository is
> > properly seeing them as binary, I'm happy. But maybe I'm missing some
> > benefit.
>
> >From chapter 7:
>
> "Also, if the svn:mime-type property is set, then the Subversion Apache
> module will use its value to populate the Content-type: HTTP header when
> responding to GET requests. This gives a crucial clue about how to
> display a file when perusing your repository with a web browser."
In other words, if your website is only served up via a Subversion
working copy, then, no, there's no reason to bother with the precise
mime-type settings. But if you ever want to refer directly to
Subversion repository URLs, browser presentation will be greatly
improved for those things.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Are MIME/Types worth the config? (was: Subversion and Project
Environments)
Posted by Ben Collins-Sussman <su...@collab.net>.
On Thu, 2004-05-27 at 01:15, Gary Affonso wrote:
> Which leads me to ask...
>
> Is there any good reason to go to the work of defining auto-properties to
> ensure that things like .jar, .jpg, .gif, etc. are all tagged with the
> appropriate mime/type?
>
> I can't see any benefit to it for web-sites. As long as the repository is
> properly seeing them as binary, I'm happy. But maybe I'm missing some
> benefit.
From chapter 7:
"Also, if the svn:mime-type property is set, then the Subversion Apache
module will use its value to populate the Content-type: HTTP header when
responding to GET requests. This gives a crucial clue about how to
display a file when perusing your repository with a web browser."
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Are MIME/Types worth the config? (was: Subversion and Project
Environments)
Posted by Gary Affonso <gl...@greywether.com>.
Which leads me to ask...
Is there any good reason to go to the work of defining auto-properties to
ensure that things like .jar, .jpg, .gif, etc. are all tagged with the
appropriate mime/type?
I can't see any benefit to it for web-sites. As long as the repository is
properly seeing them as binary, I'm happy. But maybe I'm missing some
benefit.
- Gary
On 5/26/04 11:03 PM, "glists" <gl...@greywether.com> wrote:
> I'm in the middle of getting Subversion setup for managing several large
> java-based web site. Here's how I'm tackling it:
>
> The repository is organized as such:
>
> Trunk
> dev
> lib
> src
> build.xml
> front-end
> home.jsp
> img
> etc.
> Branches
> beta
> production
> Tags
> <versions tags go here>
>
> ----
>
> The dev folder is used by the java programmers for the the back-end java
> stuff that needs compiling. The Ant build.xml file handles compiling and
> jar'ing.
>
> The front-end folder is for the html/graphics/jsp. This is generally
> checked out by a different set of folks who are using Dreamweaver on their
> local copies and doing commits when those local changes have been made.
>
> For a branching strategy we're using the "basically unstable" philosophy
> described in the Essential CVS book from O'Reilly. In this strategy the
> main "trunk" contains the latest (and possibly brittle) updates. You use
> things like branching and tagging to take snapshots (or evolve custom lines
> of development) from the repository for the beta and production releases.
>
> In some cases a simple "tag" of a particular trunk revision gets us a
> snapshot of the beta or prod release.
>
> In other cases there are things we don't want on the main trunk right away
> so we commit to the beta branch for those changes and then merge them back
> onto the trunk when the time comes.
>
> As noted in the manual, there's no inherent difference between a branch and
> a tag in Subversion, it's all just a linked-copy. The difference is in how
> you use the linked-copies (and, I supppose, your definitions of what
> constitutes a "branch" and/or a "tag").
>
> My understanding of the common-usage of the terms is that a "tag" is a
> snapshot of a particular revision on the trunk or one of the branches. A
> "branch" is a snapshot of a particular revision *plus* commits to only that
> specific branch (and not to the trunk).
>
> Anyway...
>
> For rollout (of either dev, beta or prod) we'll just grab the front-end
> folder and the .jar created from the Ant build in "dev" and move them onto
> the Tomcat server by hand, placing the jar (and the other java libs) inside
> the front-end/WEB-INF/lib folder.
>
> When I say "grab" I've been imagining I'd just check them out but as the
> previous poster pointed out, that gets you a bunch of .svn folders you may
> not want. But I believe there's a command (or a checkout option) that gets
> you the folders/files you want without the hidden Subversion directories.
> I'd guess we'll be using that.
>
> I have plans to automate all this (the checkout/merge/FTP to server) by
> further extending our Ant build script, perhaps building a WAR file or
> possibly just automating the FTP copy/merge.
>
> I'm still a little new to all this and am making some mistakes as I go so
> don't take the above as gospel. But it's where I'm at right now. Hope it
> helps.
>
> I'd love feedback if the above plan seems wrong-headed to anybody.
>
> - Gary
>
> On 5/26/04 5:27 PM, "Brendan van Drempt"
> <Br...@scholastic.com.au> wrote:
>
>> I am in the processing of setting up Subversion to manage the development of
>> a website.
>>
>> Setup:
>> Subversion Repository on Windows Server machine running SVNserve. Windows
>> development machines running TortoiseSVN client. (soon to add mac
>> development machines, when we decide on a suitable mac subversion client)
>>
>> * What is the best way to implement Subversion across my Dev / Test /
>> Production sites?
>>
>> * Should each environment be a 'working copy' of the repository, and then
>> use a client tool to update to particular revisions? (in addition to the
>> working copies of the developers)
>>
>> * Should I be using 'tags' to set releases?
>>
>> Need a bit of clarity here.
>>
>> Thanks!
>>
>> Regards,
>>
>> Brendan van Drempt
>> Analyst / Programmer
>> Email: brendan_vandrempt@scholastic.com.au
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
>> For additional commands, e-mail: users-help@subversion.tigris.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Subversion and Project Environments (Dev / Test / Prod)
Posted by glists <gl...@greywether.com>.
I'm in the middle of getting Subversion setup for managing several large
java-based web site. Here's how I'm tackling it:
The repository is organized as such:
Trunk
dev
lib
src
build.xml
front-end
home.jsp
img
etc.
Branches
beta
production
Tags
<versions tags go here>
----
The dev folder is used by the java programmers for the the back-end java
stuff that needs compiling. The Ant build.xml file handles compiling and
jar'ing.
The front-end folder is for the html/graphics/jsp. This is generally
checked out by a different set of folks who are using Dreamweaver on their
local copies and doing commits when those local changes have been made.
For a branching strategy we're using the "basically unstable" philosophy
described in the Essential CVS book from O'Reilly. In this strategy the
main "trunk" contains the latest (and possibly brittle) updates. You use
things like branching and tagging to take snapshots (or evolve custom lines
of development) from the repository for the beta and production releases.
In some cases a simple "tag" of a particular trunk revision gets us a
snapshot of the beta or prod release.
In other cases there are things we don't want on the main trunk right away
so we commit to the beta branch for those changes and then merge them back
onto the trunk when the time comes.
As noted in the manual, there's no inherent difference between a branch and
a tag in Subversion, it's all just a linked-copy. The difference is in how
you use the linked-copies (and, I supppose, your definitions of what
constitutes a "branch" and/or a "tag").
My understanding of the common-usage of the terms is that a "tag" is a
snapshot of a particular revision on the trunk or one of the branches. A
"branch" is a snapshot of a particular revision *plus* commits to only that
specific branch (and not to the trunk).
Anyway...
For rollout (of either dev, beta or prod) we'll just grab the front-end
folder and the .jar created from the Ant build in "dev" and move them onto
the Tomcat server by hand, placing the jar (and the other java libs) inside
the front-end/WEB-INF/lib folder.
When I say "grab" I've been imagining I'd just check them out but as the
previous poster pointed out, that gets you a bunch of .svn folders you may
not want. But I believe there's a command (or a checkout option) that gets
you the folders/files you want without the hidden Subversion directories.
I'd guess we'll be using that.
I have plans to automate all this (the checkout/merge/FTP to server) by
further extending our Ant build script, perhaps building a WAR file or
possibly just automating the FTP copy/merge.
I'm still a little new to all this and am making some mistakes as I go so
don't take the above as gospel. But it's where I'm at right now. Hope it
helps.
I'd love feedback if the above plan seems wrong-headed to anybody.
- Gary
On 5/26/04 5:27 PM, "Brendan van Drempt"
<Br...@scholastic.com.au> wrote:
> I am in the processing of setting up Subversion to manage the development of
> a website.
>
> Setup:
> Subversion Repository on Windows Server machine running SVNserve. Windows
> development machines running TortoiseSVN client. (soon to add mac
> development machines, when we decide on a suitable mac subversion client)
>
> * What is the best way to implement Subversion across my Dev / Test /
> Production sites?
>
> * Should each environment be a 'working copy' of the repository, and then
> use a client tool to update to particular revisions? (in addition to the
> working copies of the developers)
>
> * Should I be using 'tags' to set releases?
>
> Need a bit of clarity here.
>
> Thanks!
>
> Regards,
>
> Brendan van Drempt
> Analyst / Programmer
> Email: brendan_vandrempt@scholastic.com.au
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org