It is commonplace for a developer to find himself working at any given time on multiple different, distinct changes to a particular bit of source code. This isn't necessarily due to poor planning or some form of digital masochism. A software engineer often spots bugs in his peripheral vision while working on some nearby chunk of source code. Or perhaps he's halfway through some large change when he realizes the solution he's working on is best committed as several smaller logical units. Often, these logical units aren't nicely contained in some module, safely separated from other changes. The units might overlap, modifying different files in the same module, or even modifying different lines in the same file.
Developers can employ various work methodologies to keep these logical changes organized. Some use separate working copies of the same repository to hold each individual change in progress. Others might choose to create short-lived feature branches in the repository and use a single working copy that is constantly switched to point to one such branch or another. Still others use diff and patch tools to back up and restore uncommitted changes to and from patch files associated with each change. Each of these methods has its pros and cons, and to a large degree, the details of the changes being made heavily influence the methodology used to distinguish them.
Subversion provides a changelists feature that adds yet another method to the mix. Changelists are basically arbitrary labels (currently at most one per file) applied to working copy files for the express purpose of associating multiple files together. Users of many of Google's software offerings are familiar with this concept already. For example, Gmail doesn't provide the traditional folders-based email organization mechanism. In Gmail, you apply arbitrary labels to emails, and multiple emails can be said to be part of the same group if they happen to share a particular label. Viewing only a group of similarly labeled emails then becomes a simple user interface trick. Many other Web 2.0 sites have similar mechanisms—consider the “tags” used by sites such as YouTube and Flickr, “categories” applied to blog posts, and so on. Folks understand today that organization of data is critical, but that how that data is organized needs to be a flexible concept. The old files-and-folders paradigm is too rigid for some applications.
Subversion's changelist support allows you to create changelists by applying labels to files you want to be associated with that changelist, remove those labels, and limit the scope of the files on which its subcommands operate to only those bearing a particular label. In this section, we'll look in detail at how to do these things.
You can create, modify, and delete changelists using the svn changelist command. More accurately, you use this command to set or unset the changelist association of a particular working copy file. A changelist is effectively created the first time you label a file with that changelist; it is deleted when you remove that label from the last file that had it. Let's examine a usage scenario that demonstrates these concepts.
Harry is fixing some bugs in the calculator application's mathematics logic. His work leads him to change a couple of files:
$ svn status M integer.c M mathops.c $
While testing his bug fix, Harry notices that his changes bring to light a
tangentially related bug in the user interface logic found in
button.c. Harry decides that he'll go ahead and fix
that bug, too, as a separate commit from his math fixes. Now, in a small
working copy with only a handful of files and few logical changes, Harry can
probably keep his two logical change groupings mentally organized without
any problem. But today he's going to use Subversion's changelists feature
as a special favor to the authors of this book.
Harry first creates a changelist and associates with it the two files he's already changed. He does this by using the svn changelist command to assign the same arbitrary changelist name to those files:
$ svn changelist math-fixes integer.c mathops.c Path 'integer.c' is now a member of changelist 'math-fixes'. Path 'mathops.c' is now a member of changelist 'math-fixes'. $ svn status --- Changelist 'math-fixes': M integer.c M mathops.c $
就像你看到的，你的svn status反映了新的分组。
Harry now sets off to fix the secondary UI problem. Since he knows which file he'll be changing, he assigns that path to a changelist, too. Unfortunately, Harry carelessly assigns this third file to the same changelist as the previous two files:
$ svn changelist math-fixes button.c
Path 'button.c' is now a member of changelist 'math-fixes'.
$ svn status
--- Changelist 'math-fixes':
button.c
M integer.c
M mathops.c
$
Fortunately, Harry catches his mistake. At this point, he has two options.
He can remove the changelist association from button.c,
and then assign a different changelist name:
$ svn changelist --remove button.c Path 'button.c' is no longer a member of a changelist. $ svn changelist ui-fix button.c Path 'button.c' is now a member of changelist 'ui-fix'. $
Or, he can skip the removal and just assign a new changelist name. In this
case, Subversion will first warn Harry that button.c is
being removed from the first changelist:
$ svn changelist ui-fix button.c
svn: warning: Removing 'button.c' from changelist 'math-fixes'.
Path 'button.c' is now a member of changelist 'ui-fix'.
$ svn status
--- Changelist 'ui-fix':
button.c
--- Changelist 'math-fixes':
M integer.c
M mathops.c
$
Harry now has two distinct changelists present in his working copy, and
svn status will group its output according to these
changelist determinations. Notice that even though Harry hasn't yet
modified button.c, it still shows up in the output of
svn status as interesting because it has a changelist
assignment. Changelists can be added to and removed from files at any time,
regardless of whether they contain local modifications.
现在 Harry 开始修正 button.c 中的用户界面问题。
$ svn status --- Changelist 'ui-fix': M button.c --- Changelist 'math-fixes': M integer.c M mathops.c $
The visual grouping that Harry sees in the output of svn
status as shown in our previous section is nice, but not entirely
useful. The status command is but one of many operations
that he might wish to perform on his working copy. Fortunately, many of
Subversion's other operations understand how to operate on changelists via
the use of the --changelist option.
When provided with a --changelist option, Subversion
commands will limit the scope of their operation to only those files to
which a particular changelist name is assigned. If Harry now wants to see
the actual changes he's made to the files in his
math-fixes changelist, he could
explicitly list only the files that make up that changelist on the
svn diff command line.
$ svn diff integer.c mathops.c Index: integer.c =================================================================== --- integer.c (revision 1157) +++ integer.c (working copy) … Index: mathops.c =================================================================== --- mathops.c (revision 1157) +++ mathops.c (working copy) … $
That works okay for a few files, but what if Harry's change touched 20 or 30 files? That would be an annoyingly long list of explicitly named files. Now that he's using changelists, though, Harry can avoid explicitly listing the set of files in his changelist from now on, and instead provide just the changelist name:
$ svn diff --changelist math-fixes Index: integer.c =================================================================== --- integer.c (revision 1157) +++ integer.c (working copy) … Index: mathops.c =================================================================== --- mathops.c (revision 1157) +++ mathops.c (working copy) … $
And when it's time to commit, Harry can again use the
--changelist option to limit the scope of the commit to
files in a certain changelist. He might commit his user interface fix by
doing the following:
$ svn commit -m "Fix a UI bug found while working on math logic." \
--changelist ui-fix
Sending button.c
Transmitting file data .
Committed revision 1158.
$
In fact, the svn commit command provides a second
changelists-related option: --keep-changelists. Normally,
changelist assignments are removed from files after they are committed. But
if --keep-changelists is provided, Subversion will leave
the changelist assignment on the committed (and now unmodified) files. In
any case, committing files assigned to one changelist leaves other
changelists undisturbed.
$ svn status --- Changelist 'math-fixes': M integer.c M mathops.c $
![[注意]](images/note.png)
|
注意 |
|---|---|
|
The |
Even the svn changelist command accepts the
--changelist option. This allows you to quickly and easily
rename or remove a changelist:
$ svn changelist math-bugs --changelist math-fixes --depth infinity . svn: warning: Removing 'integer.c' from changelist 'math-fixes'. Path 'integer.c' is now a member of changelist 'math-bugs'. svn: warning: Removing 'mathops.c' from changelist 'math-fixes'. Path 'mathops.c' is now a member of changelist 'math-bugs'. $ svn changelist --remove --changelist math-bugs --depth infinity . Path 'integer.c' is no longer a member of a changelist. Path 'mathops.c' is no longer a member of a changelist. $
Finally, you can specify multiple instances of the
--changelist option on a single command line. Doing so
limits the operation you are performing to files found in any of the
specified changesets.
Subversion's changelist feature is a handy tool for grouping working copy files, but it does have a few limitations. Changelists are artifacts of a particular working copy, which means that changelist assignments cannot be propagated to the repository or otherwise shared with other users. Changelists can be assigned only to files—Subversion doesn't currently support the use of changelists with directories. Finally, you can have at most one changelist assignment on a given working copy file. Here is where the blog post category and photo service tag analogies break down—if you find yourself needing to assign a file to multiple changelists, you're out of luck.