I wrote this FAQ late last night, and was thinking of committing it to
our website FAQ. But then I thought, "hm, maybe this should go in the
book instead?" Maybe in one of the grey sidebars in the chapter on
merging? What do people think?
----------------------
Does Subversion have changesets?
That's a loaded question, because everyone seems to have a slightly
different definition of "changeset", or a least a slightly different
expectation of what it means for a version control system to have
"changeset features".
For the purposes of this discussion, here's a simple definition of
changeset: it's a collection of changes with a unique name. The
changes might include textual edits to file contents, modifications to
tree structure, or tweaks to metadata. In more common speak, a
changeset is just a "patch" with a name you can refer to.
Subversion mananges versioned trees as first order objects (the
repository is an array of trees), and the changesets are things that
are derived (by comparing adjacent trees.) Systems like Arch or
Bitkeeper are built the other way around: they're designed to manage
changesets as first order objects (the repository is a bag of
patches), and trees are derived by composing sets of patches together.
Neither philosophy is better in absolute terms: the debate goes back
at least 30 years. The two designs are better or worse for different
types of software development. We're not going to discuss that here.
Instead, here's an explanation of what you can do with Subversion.
In Subversion, a global revision number 'N' names a tree in the
repository: it's the way the repository looked after the Nth commit.
It's also the implicit name of a changeset: if you compare tree N
with tree N-1, you can derive the exact patch that was committed.
For this reason, it's easy to think of "revision N" as not just a
tree, but a changeset as well. If you use an issue tracker to manage
bugs, you can use the revision numbers to refer to particular patches
that fix bugs -- for example, "this issue was fixed by revision 9238."
Somebody can then run 'svn log -r9238' to read about the exact
changeset which fixed the bug. And svn's merge command also uses
revision numbers. You can merge specific changesets from one branch
to another by simply naming them: 'svn merge -r9237:9238 branchURL'
would merge changeset #9238 into your working copy.
This is nowhere near as complicated as a system built around
changesets as primary objects, but it's still a vast convenience over
CVS.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Mar 4 01:09:48 2004