[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn disk usage

From: John Peacock <john.peacock_at_havurah-software.org>
Date: Sat, 14 Jun 2008 19:45:57 -0400

Enrico Weigelt wrote:
> * Ryan Schmidt <subversion-2008b_at_ryandesign.com> wrote:
>> You almost certainly should check out only the trunk, not the entire
>> project structure. When you want to look at a tag, "svn switch" your
>> trunk working copy to the tag, then when you're done switch it back.
>
> hmm, looks a bit unconvenient to me, especially when tagging.
> (for now I just svn copy locally, do some things and commit -
> with your approach I'll have to type in the whole repo urls :()

The convention that most people adhere to is that a tag is an exact
point-in-time copy of the repo at one revision, i.e. no changes to the tag that
weren't made to the mainline code. Besides, even Windows has environment
variables that make long URL's manageable.

However, if your normal operation is to make some changes to a tag before
committing (like updating a version string or something), you should be aware
that you can create a tag directly from your working copy if you want. Just
check out trunk (if that is what you are tagging from), make whatever changes
you would normally make for the tag and then *copy* from your working copy to
the tag url:

        svn cp . http://server/some/long/path/tags/RELEASE-0001

The tag created would be exactly like a local copy plus update, but without the
overhead of having everything checked out. See 'svn help cp' for details on WC
to URL copies.

There really is no need to have the entire repo checked out for the vast
majority of purposes...

HTH

John

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-06-15 01:44:44 CEST

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.