[GLLUG] Once more about Subversion

[Charles Ulrich]

On Feb 5, 2008 5:27 PM,  <frank.dolinar at comcast.net> wrote:
> To all, again, thanks for the feedback.  It has helped and I've made some headway.
> That being said, I have some more questions.
>
> 1.  Given that the documentation indicates that revisions update the "revision number" for the entire trees...
> and the documentation actually says:
>
> Global Revision Numbers
> Unlike most version control systems, Subversion's revision numbers apply to entire trees,
> not individual files. Each revision number selects an entire tree, a particular state of the
> repository after some committed change. Another way to think about it is that revision N
> represents the state of the repository filesystem after the Nth commit. When Subversion
> users talk about "revision 5 of foo.c", they really mean "foo.c as it appears in revision
> 5." Notice that in general, revisions N and M of a file do not necessarily differ! Many other
> version control systems use per-file revision numbers, so this concept may seem unusual
> at first. (Former CVS users might want to see Appendix B, Subversion for CVS Users for
> more details.)
>
> Are we talking about folders with sub structure or are we talking about the entire repository.

Revision numbers work on the entire project. So if you make a change
in /trunk at revision 42, the next change somewhere in /branch will be
revision 43.

Something I meant to mention earlier is that there seem to be two
definitions of "repository" in conversations (sometimes even the
documentation) regarding subversion. Some people use it to refer to
all data stored by a particular instance of Subversion on the server
and others use it to refer to an specific project tree on a Subversion
server. So you gotta be careful. I tend to just to call the latter a
"project" since that seems more intuitive.

> 2.  I think I understand what a branch is at this point.  Under what circumstances would I want to create one?
>
> 3.  Related to question # 2, similar question about tags.

(I don't know that I fully grasp all of the concepts here since I've
never actively worked on a large development project before, but I'll
do my best to explain things as best as I've been able to figure out.)

You might want a different branches in a project where you have
simultaneous development paths. For example, there are times when the
Linux kernel source tree has a development branch and a release
branch. The development branch is used for the incorporation of new
code that is largely untested, possibly contains large amounts of
bugs, and/or might break other code within the tree. The stable branch
is code that's been tested, is largely bug-free, and is suitable for
use by the general public but that may still require bug fixes and
minor improvements.

In a smaller project following this rough idea, you'd probably put
most of your untested development code into /trunk and then use
/branch/stable for the integrating minor changes into your stable
code. You could also have a branch called /branch/experimental where
you can make large architectural changes to the code without throwing
the other developers for a loop who were already busy hacking on
/trunk. If your experimental changes end up being a good idea, you can
merge them into /trunk. As I understand it, /trunk is usually
considered the main "development" area for code, though I could be
wrong here as it seems like /trunk should rather be under /branch
instead of beside it.

A tag is simply a snapshot of your code at a particular time. You
could use revision numbers for the same purpose, but they're harder to
remember. Tagging a particular revision as 1.0-stable, for example,
lets you simply check out that revision using a command that you can
easily remember when you're sitting there on the command line ready to
get to work. You might use something like:

svn co http://svn.example.com/MyProject/branch/1.0-release

Despite everything that I've written above, Subversion is flexible
enough that you can just organize your project with whatever method
best fits your development model. The development model of the project
should dictate the structure of your project tree, not vice-versa.
There's no requirement to use branches or tags or a trunk, you can
simply do whatever feels right for your purpose. Many projects are
small enough that you can just keep everything related to the project
in one main directory and not worry about any of the branches and tags
and stuff.

> 4.  The "MyProject" folder contains a .svn folder, a trunk folder, a branches folder, and a tags folder.   I'm placing my code files in the "MyProject" folder... except when I create a branch?  How do I make sure the code for the branch gets in the right location.  And related to question # 3, when and why do I associate a tag?

I think what I've written above answers this... again, you should be
tailoring your project directory according to your needs and how you
believe the project will be developed. The only reason that the
Subversion book and others recommend using /branches, /tags, and trunk
is because that development model fits most of the medium- to
large-size development efforts out there.

Charles