Are MIME/Types worth the config? (was: Subversion and Project Environments)

[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: Are MIME/Types worth the config? (was: Subversion and Project Environments)

[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)

["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)

[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