Ben Collins-Sussman <sussman@collab.net> writes:
> 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?
I think it's wonderfully clear, and accurate -- go for it!
-Karl
> ----------------------
>
> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Mar 4 07:14:54 2004