何謂SVN的'changesets"

摘錄於Version Control with Subversion (for Subversion 1.5)之電子書
針對在svn常見的名詞 "changesets", 提供了清楚的定義

Changesets
Before we proceed further, we should warn you that there's going to be a lot of discussion of “changes” in the pages ahead. A lot of people experienced with version control systems use the terms “change” and “changeset” interchangeably, and we should clarify what Subversion understands as a changeset.

Everyone seems to have a slightly different definition of changeset, or at least a different expectation of what it means for a version control system to have one. For our purposes, let's say that a changeset is just 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.

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 name of an implicit 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 r9238.” Somebody can then run svn log -r 9238 to read about the exact changeset that fixed the bug, and run svn diff -c 9238 to see the patch itself. And (as you'll see shortly) Subversion's svn merge command is able to use revision numbers. You can merge specific changesets from one branch to another by naming them in the merge arguments: passing -c 9238 to svn merge would merge changeset r9238 into your working copy.

簡要說明: "changesets"在svn中, 真正代表的意義是, 在commit時, 此時間點下, 異動到的檔案, 皆可視為"changesets", 而使用者可以藉由svn log -r9238, 或svn diff -r9238, 清楚得知該次異動到檔案

衍生說明: 同一時間點內, 儘可能增修一個bug, 一個fuction , 一個procedure, 隨即進行一次commit, 極力不建議增修多個bug, 多個fuction, 多個procedure, 才進行一次的commit

舉例說明: user A增加一個fuction CallPhone(), 也修改一個function SetRing(), 實際上2個function是不相干的, CallPhone()是新增需求, SetRing()是修改流程, 卻同時進行commit, 當日後user B發現CallPhone()有問題, 卻很難將之移除, 須額外花費時間判斷哪些部份的程式碼是因應Call Phone而增修的, 造成極大的困擾及風險