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

Re: Default folder names compulsory?

From: Ryan Schmidt <subversion-2007b_at_ryandesign.com>
Date: Fri, 11 Jan 2008 00:51:45 -0600

On Jan 11, 2008, at 00:05, pd wrote:

> At 03:22 PM 11/01/2008, Ryan Schmidt wrote:
>> On Jan 10, 2008, at 22:11, pd wrote:
>>> I'm new to version control in general, let along any one 'flavour'
>>> like SVN, so please be gentle :)
>>> I work on websites on Ubuntu servers running Apache. Standard
>>> accounts are used for example:
>>> /home/username/
>>> Virtual web sites are then 'mapped' in Apache to:
>>> /home/username/public_html/
>>> Overall I think this is a relatively normal set up.
>>> To integrate SVN, is it possible to make the
>>> /home/username/
>>> folder the 'trunk' folder?
>>> Branches and tags can go anywhere on the dev server because they
>>> will be copied to separate staging and production servers and
>>> therefore don't need to be usable on the dev server, from a web
>>> browser for example. Hence I was hoping to have these folders at
>>> this level:
>>> /home/username/branches/
>>> /home/username/tags/
>>> So in summary, is it possible to have this:
>>> /home/[usernameAsTrunkName]/
>>> /home/[usernameAsTrunkName]/branches/
>>> /home/[usernameAsTrunkName]/tags/
>>> I can see this might present a problem with the branches and tags
>>> folders 'under' the trunk folder unless they are excluded from the
>>> files versioned as trunk code.
>> There seems to be a few basic misunderstandings...
>> First, the trunk, branches and tags are in the repository database,
>> not folders on your hard disk.
> 'in the repository database' meaning they are flags on revision
> records?
>> You can check things out from the
>> repository into working copies, which then are on your hard disk, but
>> you wouldn't check out the root of the repository, including the
>> trunk, all branches and all tags.
> Yeah i don't think I was suggesting this.
> Presently we tend to connect to the server via FTP, download a
> file, work on it, and save it via FTP back to the server. This is
> probably very different to 'normal' desktop software development
> however it's quite effective in the tiny team we have. We'd just
> like to add revision control for backup more than anything, and
> version management.
>> Rather, you would usually check out
>> the trunk and work on it. If you want to work on a branch instead,
>> you can switch your trunk working copy to that branch, work, then
>> switch back to the trunk. Or you can check out a second working copy
>> for your branch work, then delete the working copy.
> Cool, sounds fine, so despite the common online code 'browsers'
> I've seen, such as trac, which are designed to look like
> filesystems, /trunk/, /branches/, /tags/ don't ever actually exist
> as folder on the server, correct?
>> Second, trunk, branches and tags need to be at the same level.
>> branches and tags cannot be under the trunk. This is not due to any
>> built-in Subversion restriction, but simple logic of directory
>> operations.
> But you said trunk, branch, tags are not folder/directories? Are
> you saying that SVN recursively scans any files in a given folder
> and versions everything? Hence if a branch or tag set of files
> exist within/underneath the trunk folder, they will be included in
> addition to the trunk files, meaning they are duplicates and
> confusion would reign?
> I think I suggested that might be a flaw in my suggestion.
>> A branch or tag is created by copying the trunk. And I
>> think most file systems (Subversion repositories included) don't let
>> you copy directories into themselves.
> Cool.
>> trunk, branches and tags directories don't need to be called that.
> Why are you referring to these words as 'directories' (aka folders)
> when initially you stated
> "trunk, branches and tags are in the repository database, not folders"
>> They can have any name you want. Or you can omit them entirely. After
>> all, a Subversion repository is just a versioned file system. You can
>> version any files and directories you want. That said, you probably
>> do want the functionality this setup gives you, and it's useful to
>> use the names that everyone else does for these concepts.
> So trunk, branches, tags are not directies/folders but they kinda
> are ... I can name them whatever I like but I kinda shouldn't?
> I'm still confused though I appreciate your effort to respond Ryan.
>> Have you read the free online book? It should explain everything you
>> need to know.
>> http://svnbook.red-bean.com/en/1.4/
> I've read bits and pieces. I'd really like a printout, does anyone
> know if an easier-to-print version exists, for example a pdf?

I recommend you read it from start to finish. And before trying a
repository layout of your own devising, be sure you understand the
structure proposed in the book and why the book proposes it. It will
also be easier if you just try Subversion out and see how it works.
Follow along with the examples in the book perhaps. Once you have
done all this, you'll have a much better understanding of how
Subversion work and how it can be used.

I'll briefly say that a Subversion repository is like a filesystem
that is accessed through a Subversion client. So, when you create a

        svnadmin create myrepo

you can look into the directory "myrepo" on your server's hard disk
and you'll see various internal directories that Subversion uses to
store the repository filesystem. You will not, however, see the files
and directories contained in that filesystem. To do that, you need to
use a Subversion client.

When you check out a working copy from your repository:

        svn checkout url://to/myrepo mywc

and put some items in it:

        cd mywc
        svn mkdir trunk
        svn mkdir branches
        svn mkdir tags
        svn ci -m "creating empty trunk / branches / tags directories"

you can now go back to the server and look in the myrepo directory on
your server's hard disk, and you will not find any directories called
"trunk", "branches" or "tags" in it. Rather, (if this is an FSFS
repository, which it will be by default if you used Subversion 1.2.0
or later to create it) you will see a new file in the directory db/
revs and another new file in db/revprops. Each revision that you
commit to the repository causes one new file to be created in each of
these two directories, with an incrementing number equal to the
committed revision number, regardless of how many files or
directories of the repository's filesystem the commit affected. These
two files contain all the changes that were just committed in the new
revision. More information is available about how the repository
stores your data, but you don't really need to know it. Just know
that the repository is a filesystem that you access via a Subversion

To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-01-11 07:52:46 CET

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.