new changeset FAQ?

[Ben Collins-Sussman <su...@collab.net>]

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

Re: new changeset FAQ?

["Daniel L. Rall" <dl...@collab.net>]

kfogel@collab.net wrote:
> Ben Collins-Sussman <su...@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!

Looks like you put it into the book instead.  +1 on that.  How about linking 
it from the FAQ (if you didn't already)?


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: new changeset FAQ?

[kf...@collab.net]

Ben Collins-Sussman <su...@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