Hi Ryan
Thanks for this, it's very helpful. I've printed the first two chapters of the book and am RTFMing :) The initial quality of the manual is quite impressive!
One statement I can make that might clear up some confusion is that I don't care if the names "trunk", "branches" and "tags" are used in the repository's internals and theory. I was just hoping to ensure the trunk always related to code in the /home/username/ folder.
However, if my thinking is now correct, code doesn't 'live' in a normal file system folder *until* a version is extracted from the SVN internals to a folder. Is that correct? If this is the case, my scenario would need a situation where any code checked in to the trunk would automatically be outputted to a real folder. If I was to draw up a basic work flow diagram of what I am trying to achieve, would you be able to take a look?
pd
At 05:51 PM 11/01/2008, you wrote:
>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
>repository:
>
> 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
>client.
---------------------------------------------------------------------
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 12:58:40 CET