RE: Checkouts - I think I've been doing it wrong for 3 years!

Now that is a post that deserves to be added to the subversion docs J

PS. The thing about sparse checkouts: those of us with multi-gigabyte
repositories use that feature quite a lot.

PPS. The thing about not needing tags if you can remember the revision
number is much underrated.

From: David Weintraub [mailto:qazwart_at_gmail.com]
Sent: Friday, August 14, 2009 4:36 PM
To: Steve Klett
Cc: users_at_subversion.tigris.org
Subject: Re: Checkouts - I think I've been doing it wrong for 3 years!

First of all, you don't need branches and tags if you never have to use
them. For example, if you are using Subversion to version a single
website, you might not need branches or tags.

Branches are used to allow for parallel development. That's all. If you
don't do parallel development, you don't need branches.

I worked at one company that simply released a single product, and
updated all their users to that revision. No users had a different
revision. If there was a bug, it would be fixed in the next revision
(which came out quite regularly). When we were doing a release, we had a
code freezes, but because we had a small shop, everyone simply worked on
bug fixes, so we still kept everyone busy, so we still didn't need a
branch. Branches add complexity to revision control, so if you can get
away without using them, you're fine.

You don't need tags either -- especially with Subversion. Tags are
simply a way of taking a snapshot of your current development. Since
Subversion versions the entire repository and not individual files, it
pretty much takes a snapshot of your development every checkin. If you
don't mind referring to your revisions by the Subversion repository
revision number, you don't need tags. There are quite a few shops that
don't use tags. And there are even more shops that simply only have tags
on customer releases.

Nor, is there any problem of checking everything out if your projects
are small and you don't have a lot in the way of branches or tags which
sounds like the setup you have.

So, take a deep breath. You're not doing anything "wrong". It might not
be the way many people use Subversion, but I can assure you that many
places get by fine without branches or tags.

I have rarely used the "switch" command. I've got 120 Gigabytes on my
computer and have plenty of room, so I simply do multiple checkouts of
the various projects I'm working on. When I do a checkout, I simply name
the directory with the name of the project and the branch ID. For
example, I have a repository that looks like this:

projects
    foo
       tags
          1.0
          1.0.1
          1.1
          1.1.1
          1.1.2
       branches
          1.0
          1.2
          1.3
       trunk
    bar
        tags
          1.0
          1.1

                                  branches
                                        1.0
                                        2.0
                                  trunk

Let's say I am doing work on foo's trunk, foo's 1.2 branch, and bar's
trunk. I create three workareas:

$ svn co svn://localhost/projects/foo/trunk foo-trunk
$ svn co svn://localhost/projects/foo/branches/1.2 foo-1.2
$ svn co svn://localhost/projects/bar/trunk bar-trunk

Now, it's easy for me to see that the directory foo-trunk contains the
trunk of foo while foo-1.2 contains foo's 1.2 branch development

If I do use "svn switch", I'll rename the base directory after the
switched to branch or trunk. If I checkout a tag, and the tag and branch
names have the same structure, I'll append the name of the checked out
directory with a "T": That will let me know it's for tag 1.1.1 and not
branch 1.1.1

$ svn co svn://localhost/projects/foo/tags/1.1.1 foo-1.1.1-T

So, I personally use directory names as a way to tell me what project
I've got checked out and what tag or branch is checked out.

Some developers like to use the "switch" command, so they simply need to
remember what branch or trunk is in what directory when they switch from
one revision to another. They can also use "svn info" which will give
them this information.

The big problem you're going to have is understanding that once you
start using branches and tags, a master checkout will quickly fill up an
entire disk. Let's say you do this:

$ svn co svn://localhost/projects/foo

You're going to get a directory foo that contains a complete checkout of
the trunk, of the three branches, and of all five tags of foo. That's
almost ten times the room that checking out a single branch, tag, or
trunk will give you. Many developers who had never used Subversion do
this.

As for your repository structure, you can do it almost anyway you want.
the two standards are:

     trunk/project
     tags/project
     branches/project

and

    project/trunk
    project/tags
    project/branches

The first way is nice because a checkout of trunk/project is just trunk
project, and it's simple to map trunk/project/build.xml with
branches/1.2/project/build.xml. Mapping project/trunk/build.xml vs.
project/branches/1.2/build.xml is just a bit harder to contemplate
because the trunk and branch names are between the project and the name
of the file. Especially since there are two directory levels in
branches, but only a single directory level for trunk.

Also, when you do a checkout of trunk/project, you're only getting the
project and your directory is automatically named "project".

The problem is that tags and branches are now shared between all
projects. Normally, I simply use plain revision numbers (1.1, 1.2) for
branch and tag names, but if you use the first method, you'll need a way
to distinguish between branch 1.1 for project "foo" vs. branch 1.1 for
project "bar".

Nor, is there anything that says you must do branching and tagging like
that. For example, one shop I worked at had
"project/branches/main" vs. "project/trunk" simply because they prefer
to think of the trunk as a branch, and they thought it was easier to
think of a file's URL when both the trunk and branches shared the same
number of directories:

project/branches/main/build.xml
project/branches/1.1/build.xml

So, instead of restructuring your entire repository, you may simply want
to just add a branches and tags directory to your current structure:

C:\PMD Repository
    \tags
    \branches
    \Tools
        \ProjectA
        \ProjectB
        \ProjectC
    \Forms
        \Stuff
        \More Stuff

Note, that there's no "trunk" directory. This would allow you to keep
your current structure, but still allow you to create branches and tags.

So, to answer your question: How do you know which branch or trunk
you're working on, we simply put that as part of our directory name. You
can also use the "svn info" command which will give you that
information. Remember: There is nothing telling you that you are only
allowed a single checkout of a particular project. If you are working on
both a trunk, and a branch, check them both out.

BTW, I've seen people take advantage of the "sparse checkout" abilities:
They now do this:

$ svn co --depth=immediates svn://localhost/foo

Which gives them a working directory that contains the empty directories
"trunk", "branches", and "tags". When they want to checkout a particular
branch or tag, they do this:

$ cd trunk
$ svn update --depth=infinity

This way, they simply checkout the branches, tags, and trunks they want,
but still use the directory repository structure and a single working
copy. You usually see people who've used Perforce do this.

On Thu, Aug 13, 2009 at 10:34 PM, Steve Klett <sklett_at_pmddirect.com>
wrote:

Hi, first post.

I am the only developer in my small company and have been using (hosted)
subversion for 3+ years. When I first started using it I was coming from
an old job where we used sourcesafe (v6!) so there was no concept of
branches, tags, etc. While learning subversion (I read the red book and
also purchased Pragmatic Version Control with Subversion) I remember
reading about tags, branches and trunks and thinking it was interesting
but never ended up using them. Until now. Well at least I want to.

Here's how I've been working, I created my local copy of my projects
years ago and then added and committed that to the repository. Over the
years I have just added more and more projects. I now have something
like this on my local copy (same as working copy?)

Code:
C:\PMD Repository
    \Tools
        \ProjectA
        \ProjectB
        \ProjectC
    \Forms
        \Stuff
        \More Stuff

as you can see there are no trunks or branches. That is easy enough to
fix I think by adding the folders and then svn-moving my projects into
the trunk.

What I'm REALLY confused about is the concept of a working copy and the
way I've been creating a complete copy of my whole repository on my
local machine. It's very "SourceSafe" of me to just do a giant update of
everything I need so that's how I've always thought about it.

After reading about branching and the switch command I suspect I've been
doing this all wrong. That I should actually be performing a checkout of
the specific trunk or branch that I want to work on. So rather that
checkout "PMD Repository" and get EVERYTHING I should create a basic
directory and checkout only the trunk or branch that I want to work on.
For example, if I wanted to create and work on a new branch of ProjectA
I would checkout "PMD Repository\Tools\ProjectA\branches\somebranch" to
my local folder "C:\PMD Repository\Tools\ProjectA"

In other words, I don't create the tree/branch/tag structure on my local
machine.

Is this correct? What's made me question all this is the concept of
"switching" which as I understand it sets your working copy (what
exactly does that mean?) to the trunk/branch/tag that you choose. It
lets users work on files without being concerned if they are on the
trunk or branch.

To me this seems very confusing and dangerous - how do you KNOW what
tag/branch/trunk you are working on?

What if I want to keep a working copy of trunk and a working copy a
branch at the same time? As I'm sure you can tell I'm missing something.
I've re-read the topics in the red book and read through my pragmatic
book again and I'm still confused.

Any help GREATLY appreciated. At this point I'd even pay someone for
some professional guidance on this - I really don't want to screw it up
and lose anything and I want to understand how to use subversion
correctly.

Thanks for reading!

-Steve

-- 
David Weintraub
qazwart_at_gmail.com
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2383669
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].