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=2383652
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-08-14 17:37:22 CEST