While I hate to contradict a recommendation to read my book (thanks,
Ben!), I think the section on branches is probably CVS-specific enough
to be confusing when applied to Subversion's "cheap copy" model.
But here is a quick attempt to answer Alexis Huxley's question:
The immediate purpose of a revision control system is to be a time
machine. It's what allows you to go back in time and examine your
project "as it was on date X". Sometimes you want to do more than
that -- you might want to not only examine a past snapshot, but make a
change to that snapshot. For example, you discover a bug in an old
and otherwise stable release, and want to make a new bugfix release
containing just the fix for that bug, but *not* containing all of the
(potentially destabilizing) development work you've done since that
release.
Of course, the bugfix change shouldn't affect all the revisions
committed since then. The fix is only tested against the old stable
snapshot; maybe the bug doesn't exist in the latest development
sources, or maybe the same fix doesn't apply. And in any case, the
change history since the stable release is already committed. It's
irrevocable -- one can't just change the course of history. That
would be a loss of information.
So just as in many science fiction stories involving time machines, if
you go back into the past and change history, you get an alternate,
parallel universe -- a branch :-).
Subversion implements branches as copies. If you need to make changes
against foo without affecting "descendent" revisions of foo, you make
your changes to a copy of foo, so the original remains untouched. (Of
course, under the hood Subversion implements copies efficiently -- it
doesn't duplicate all the storage of the original, it just stores new
pointers to the same data, then allocates new storage only as the copy
receives changes.)
You can make a copy of anything you have a historical handle on, at
any time; that is, you can make a copy of yesterday's snapshot today,
or tomorrow, and the copy still starts out with the content of
yesterday. Here's a simple diagram in which a copy is made of the
sources as of date X. Time moves to the right:
.--------------------------[copy based =========================>
/ on date X] (copy's line of devel)
/
/
====X===================================Y=========>
(main line of development,
also called "trunk" )
The copy was _made_ at time Y, but it is a copy of the main line of
development as it was at time X.
I'm sure you can see many applications for this concept, no need to go
into all of them here.
So given the above, two more definitions:
"tag" -- A pristine snapshot of prior revision(s), to which no
changes have been made. That is, a copy, where
nothing new has been committed to the copy's line of
development.
"merge" -- To port changes from one line of development over to
another. For example, if you took the bugfix patch
applied to the stable release branch, and applied that
patch to the main development line, that would be a
merge.
Hope this helps,
-Karl
Ben Collins-Sussman <sussman@collab.net> writes:
> > Can anybody offer any pointers to good generic/philosophic [web]
> > documents regarding such things? Thanks!
>
> If you want to understand 'branches' and 'tags' as general version
> control concepts, take a look at a nice part of kfogel's CVS book:
>
> http://cvsbook.red-bean.com/cvsbook.html#Branches
>
> If you then want to understand how they work in Subversion via our
> 'cheap copy' technique, read our programmer's 'design' document. It
> has some diagrams and examples of how copies and shared storage works:
>
> http://subversion.tigris.org/files/documents/15/17/svn-design.html
>
> You'll need to grep down to the section called "Repository Structure"
> and start reading there.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jun 19 17:03:25 2002