20. Subversion Way
• Working copies
- How the working copy works
- Disposing of a Working Copy
- Administrative directory
- Mixed-revision
21. Subversion Way
• Working copies
- How the working copy works at e!
- Disposing of a Working Copy re sep ar
- Administrative directory it sa
m
c om
- Mixed-revision
te sa
nd
p da
U
24. Importing
• Working copy not required
• Files are immediately committed to the
repository
• Original local directory not converted into
a working copy
$ svn import unversioned-directory
http://svn.example.com/repos/trunk/magic
25. Create a working copy
• Create a working copy on local machine
• Every directory in a working copy contains
an .svn subdirectory
$ svn checkout http://svn.example.com/repos/trunk/magic
working-copy
26. Basic Work Cycle
• Update your working copy
• Make your changes
• Review your changes
• Fix your mistakes
• Resolve any conflicts
• Publish (commit) your changes
27. Update working copy
• Update to specified revision with -r
• Commit new changes to out-of-date files
and directories is not allowed by svn
$ cd working-copy
$ svn update
28. Make your change
• File changes
- Make changes using what ever tools
- Svn automatically detects file changes
• Tree changes
- Changes to a directory’s structure
- Use svn operations to “schedule”
37. Resolve Any Conflicts
• Resolve conflicts with svn resolve
• Removes three temporary files
• Accepts the version of the file that you
specified with the --accept option
• No longer considers the file to be in a state
of conflict
38. Commit Your Changes
• Commit changes with svn commit
• --message(-m) --file(-F)
• SVN_EDITOR
40. SVN Changing Steps
• Logs intentions in a private “to-do list”
• Performs those action to affect the desired
change, holding a lock on the relevant part
of the working copy
• Releases its lock and cleans up its private
to-do list.
41. Clean Up
• Recover from interruption with svn cleanup
• Searches working copy
• Runs any leftover to-do items
• Removing working copy locks as it
completes
42. Localization
• Notices the value of LC_MESSAGES
variable and attempts to print messages in
the specified language
• Locale is honored involves how svn
interprets your input
• The repository stores all paths, filenames,
and log messages in Unicode, encoded as
UTF-8
43. Localization
• Notices the value of LC_MESSAGES
variable and attempts to print messages in
the specified language
• Locale is honored involves how svn
interprets your input
• The repository stores all paths, filenames,
and log messages in Unicode, encoded as
UTF-8
svn: Can’t convert string from native encoding to ‘UTF-8’:
svn: Can’t convert string from ‘UTF-8’ to native encoding:
53. Peg Revisions
• A path and a peg revision can identify to a
specific line of history
• Peg revisions are specified using at syntax
• Default peg revision is HEAD
54. Operative Revisions
• Specified by --revision (-r) option
• Subversion performs the requested
operation using the operative revision
55. Properties
• Versioned metadata on versioned files and
directories
• Property names contain only ASCII
characters
• Property values can be whatever you want
• Revision Properties
57. Automatic Setting
• Subversion tries to setting some common
file properties automatically when adding
and importing files
• Subversion tries to determine the file’s
MIME type
• Provides flexible feature to create mappings
of filename patterns to properties
59. Sparse Directory
• By default, operations on directories act in
a recursive manner
• This feature allows you to easily check out
a working copy more shallowly than full
recursion
• Free to bring in previously ignored files and
subdirectories at a later time
62. Locking
• Copy-modify-merge models lives and dies
on its data merging algorithm
• Creating lock with svn lock
• Lock token and Lock owner
• svn:needs-lock as lock communication
$svn info https://url-to-target | grep Lock
64. Changelists
• Working at multiple changes
• Best to committed as several small logical
units
• Need to keep logical changes organized
65. Changelists
• Allows you to create changelists by applying
labels to files you want to be associated
with the change list
• Allow you to limit the scope of the files on
which its subcommands operate to only
those bearing a particular label
66. Changelists
• Allows you to create changelists by applying
labels to files you want to be associated
with the change list
• Allow you to limit the scope of the files on
which its subcommands operate to only
those bearing a particular label
$ svn changelist ui-fixes dream.c
$ svn commit --changelist ui-fixes
72. What’s a Branch
• A line of development that exists
independently of another line
• Shares a common history if look far enough
back in time
• Always begins life as a copy of something,
and moves on from there, generating its
own history
74. Creating a Branch
$ svn copy http://svn.example.com/repo/trunk
http://svn.example.com/repo/branches/my-branch
-m “Creating a private branch”
# Choice 1: check out new branch
$ svn checkout
http://svn.example.com/repo/branches/my-branch
my-branch
# Choice 2: switch to new branch in trunk working-copy
$ svn switch http://svn.example.com/repo/branches/my-branch
75. Creating a Branch
• Subversion has no internal concept of a
branch
• Subversion’s branches exist as normal
filesystem directories in the repository
• The only reason a copied directory is a
“branch” is because humans have decided
to treat it that way
76. Keeping Branch in Snyc
• It’s very easy to drift too far apart.
• May be near-impossible to merge back into
the trunk without a huge number of
conflicts.
• Frequently keeping your branch in sync
with the main line helps prevent “surprise”
conflicts
$ cd my-branch
$ svn merge ^/trunk/
77. Reintegrating a Branch
• Bring branch in sync with trunk first
• Make sure trunk working copy do not have
any local edits or be at mixed-revisions
• Use svn merge with --reintegrate
$ cd trunk
$ svn merge --reintegrate ^/branches/my-branch
$ svn delete ^/branches/my-branch
78. Mergeinfo and Previews
• Use svn mergeinfo to see changesets has
absorbed and eligible to receive
• Using svn merge --dry-run option to get a
more precise preview
• Cherry Peeking
79. Undoing Change
• Roll back a change that has already been
committed
• You can use svn merge to “undo” the
change in your working copy, then commit
• Specify a reverse difference
$ svn merge -c -303 ^/trunk
$ svn diff
$ svn commit -m “Undoing change committed in r303”
80. Resurrect Deleted Item
• Information is never lost in VCS
• Delete a file just means it gone from the
HEAD revision, still exists in earlier
revisions
81. Resurrect Deleted Item
• Define exactly which item you’re trying to
resurrect (By path and peg revision)
• Two choices to resurrect
- Use svn merge to apply “in reverse”
- Use svn copy command
$ svn copy ^/trunk/dream.c@303 ./dream.c
$ svn commit -m “Resurrected dream.c from r303”
82. Tags
• A “snapshot” of a project in time
• Nobody commits to it
• svn copy comes to the rescue
$ svn copy http://svn.example.com/repos/trunk
http://svn.example.com/repos/tags/release-1.0
$ svn copy working-copy
http://svn.example.com/repos/tags/release-1.0
Unlike most version control systems, Subversion's revision numbers apply to entire trees, not individual files. Each revision number selects an entire tree, a particular state of the repository after some committed change. Another way to think about it is that revision N represents the state of the repository filesystem after the Nth commit.\n\n
Unlike most version control systems, Subversion's revision numbers apply to entire trees, not individual files. Each revision number selects an entire tree, a particular state of the repository after some committed change. Another way to think about it is that revision N represents the state of the repository filesystem after the Nth commit.\n\n
Unlike most version control systems, Subversion's revision numbers apply to entire trees, not individual files. Each revision number selects an entire tree, a particular state of the repository after some committed change. Another way to think about it is that revision N represents the state of the repository filesystem after the Nth commit.\n\n
Unlike most version control systems, Subversion's revision numbers apply to entire trees, not individual files. Each revision number selects an entire tree, a particular state of the repository after some committed change. Another way to think about it is that revision N represents the state of the repository filesystem after the Nth commit.\n\n
Unlike most version control systems, Subversion's revision numbers apply to entire trees, not individual files. Each revision number selects an entire tree, a particular state of the repository after some committed change. Another way to think about it is that revision N represents the state of the repository filesystem after the Nth commit.\n\n
Unlike most version control systems, Subversion's revision numbers apply to entire trees, not individual files. Each revision number selects an entire tree, a particular state of the repository after some committed change. Another way to think about it is that revision N represents the state of the repository filesystem after the Nth commit.\n\n
Unlike most version control systems, Subversion's revision numbers apply to entire trees, not individual files. Each revision number selects an entire tree, a particular state of the repository after some committed change. Another way to think about it is that revision N represents the state of the repository filesystem after the Nth commit.\n\n
Unlike most version control systems, Subversion's revision numbers apply to entire trees, not individual files. Each revision number selects an entire tree, a particular state of the repository after some committed change. Another way to think about it is that revision N represents the state of the repository filesystem after the Nth commit.\n\n
Unlike most version control systems, Subversion's revision numbers apply to entire trees, not individual files. Each revision number selects an entire tree, a particular state of the repository after some committed change. Another way to think about it is that revision N represents the state of the repository filesystem after the Nth commit.\n\n
\nFor each file in a working directory, Subversion records (among other things) two essential pieces of information:\nWhat revision your working file is based on (this is called the file's working revision) \nA timestamp recording when the local copy was last updated by the repositor \nGiven this information, by talking to the repository, Subversion can tell which of the following four states a working file is in: Unchanged, and currentThe file is unchanged in the working directory, and no changes to that file have been committed to the repository since its working revision. An svn commit of the file will do nothing, and an svn update of the file will do nothing. Locally changed, and currentThe file has been changed in the working directory, and no changes to that file have been committed to the repository since you last updated. There are local changes that have not been committed to the repository; thus an svn commit of the file will succeed in publishing your changes, and an svn update of the file will do nothing. Unchanged, and out of dateThe file has not been changed in the working directory, but it has been changed in the repository. The file should eventually be updated in order to make it current with the latest public revision. An svn commit of the file will do nothing, and an svn up- date of the file will fold the latest changes into your working copy. Locally changed, and out of dateThe file has been changed both in the working directory and in the repository. An svn commit of the file will fail with an “out-of-date” error. The file should be updated first; an svn update command will attempt to merge the public changes with the local changes. If Subversion can't complete the merge in a plausible way automatically, it leaves it to the user to resolve the conflict. \n\nupdates and commits are separate\nMixed revisions are normal\n
\n
\n
\n
\n
\n
\n
Tree changes are different, and involve changes to a directory's structure. Such changes include adding and removing files, renam- ing files or directories, and copying files or directories to new locations.\nFor tree changes, you use Subversion operations to “schedule” files and directories for removal, addition, copying, or moving. These changes may take place immediately in your working copy, but no additions or removals will happen in the repository until you commit them.\n\n
Subversion does this by keeping private caches of pristine, unmodified versions of each versioned file inside its working copy administrative areas. This allows Subversion to report—and revert—local modifications to those files without network access. \nThis cache (called the text-base) also allows Subversion to send the user's local modifications during a commit to the server as a compressed delta (or “difference”) against the pristine version. \nHaving this cache is a tremendous benefit—even if you have a fast Internet connection, it's generally much faster to send only a file's changes rather than the whole file to the server.\n\n
Subversion does this by keeping private caches of pristine, unmodified versions of each versioned file inside its working copy administrative areas. This allows Subversion to report—and revert—local modifications to those files without network access. \nThis cache (called the text-base) also allows Subversion to send the user's local modifications during a commit to the server as a compressed delta (or “difference”) against the pristine version. \nHaving this cache is a tremendous benefit—even if you have a fast Internet connection, it's generally much faster to send only a file's changes rather than the whole file to the server.\n\n
Subversion does this by keeping private caches of pristine, unmodified versions of each versioned file inside its working copy administrative areas. This allows Subversion to report—and revert—local modifications to those files without network access. \nThis cache (called the text-base) also allows Subversion to send the user's local modifications during a commit to the server as a compressed delta (or “difference”) against the pristine version. \nHaving this cache is a tremendous benefit—even if you have a fast Internet connection, it's generally much faster to send only a file's changes rather than the whole file to the server.\n\n
\n
\n
\n
\n
\n
\n
\n
\n
svn log -v\nsvn log -q\nsvn log -r 1:10\n
\n
\n
\n
\n
\n
svn提供了足够的灵活性，能够非常方便随意的管理文件目录\n\nSubversion's file management support is quite liberating, affording almost as much flexibility for versioned files as you'd expect when manipulating your unversioned ones. But that flexibility means that across the lifetime of your repository, a given versioned object might have many paths, and a given path might represent several entirely different versioned objects. This introduces a certain level of com- plexity to your interactions with those paths and objects.\n\n
Subversion's file management support is quite liberating, affording almost as much flexibility for versioned files as you'd expect when manipulating your unversioned ones. But that flexibility means that across the lifetime of your repository, a given versioned object might have many paths, and a given path might represent several entirely different versioned objects. This introduces a certain level of com- plexity to your interactions with those paths and objects.\n\n
Subversion's file management support is quite liberating, affording almost as much flexibility for versioned files as you'd expect when manipulating your unversioned ones. But that flexibility means that across the lifetime of your repository, a given versioned object might have many paths, and a given path might represent several entirely different versioned objects. This introduces a certain level of com- plexity to your interactions with those paths and objects.\n\n
Subversion's file management support is quite liberating, affording almost as much flexibility for versioned files as you'd expect when manipulating your unversioned ones. But that flexibility means that across the lifetime of your repository, a given versioned object might have many paths, and a given path might represent several entirely different versioned objects. This introduces a certain level of com- plexity to your interactions with those paths and objects.\n\n
Subversion's file management support is quite liberating, affording almost as much flexibility for versioned files as you'd expect when manipulating your unversioned ones. But that flexibility means that across the lifetime of your repository, a given versioned object might have many paths, and a given path might represent several entirely different versioned objects. This introduces a certain level of com- plexity to your interactions with those paths and objects.\n\n
Subversion's file management support is quite liberating, affording almost as much flexibility for versioned files as you'd expect when manipulating your unversioned ones. But that flexibility means that across the lifetime of your repository, a given versioned object might have many paths, and a given path might represent several entirely different versioned objects. This introduces a certain level of com- plexity to your interactions with those paths and objects.\n\n
Subversion's file management support is quite liberating, affording almost as much flexibility for versioned files as you'd expect when manipulating your unversioned ones. But that flexibility means that across the lifetime of your repository, a given versioned object might have many paths, and a given path might represent several entirely different versioned objects. This introduces a certain level of com- plexity to your interactions with those paths and objects.\n\n
Subversion's file management support is quite liberating, affording almost as much flexibility for versioned files as you'd expect when manipulating your unversioned ones. But that flexibility means that across the lifetime of your repository, a given versioned object might have many paths, and a given path might represent several entirely different versioned objects. This introduces a certain level of com- plexity to your interactions with those paths and objects.\n\n
Subversion's file management support is quite liberating, affording almost as much flexibility for versioned files as you'd expect when manipulating your unversioned ones. But that flexibility means that across the lifetime of your repository, a given versioned object might have many paths, and a given path might represent several entirely different versioned objects. This introduces a certain level of com- plexity to your interactions with those paths and objects.\n\n
Subversion's file management support is quite liberating, affording almost as much flexibility for versioned files as you'd expect when manipulating your unversioned ones. But that flexibility means that across the lifetime of your repository, a given versioned object might have many paths, and a given path might represent several entirely different versioned objects. This introduces a certain level of com- plexity to your interactions with those paths and objects.\n\n
Subversion's file management support is quite liberating, affording almost as much flexibility for versioned files as you'd expect when manipulating your unversioned ones. But that flexibility means that across the lifetime of your repository, a given versioned object might have many paths, and a given path might represent several entirely different versioned objects. This introduces a certain level of com- plexity to your interactions with those paths and objects.\n\n
\n
\n
\n
\n
\n
\n
native\nThis causes the file to contain the EOL markers that are native to the operating system on which Subversion was run. In other words, if a user on a Windows machine checks out a working copy that contains a file with an svn:eol-style property set to native, that file will contain CRLF EOL markers. A Unix user checking out a working copy that contains the same file will see LF EOL markers in his copy of the file.\nNote that Subversion will actually store the file in the repository using normalized LF EOL markers regardless of the operating system. This is basically transparent to the user, though.\nCRLFThis causes the file to contain CRLF sequences for EOL markers, regardless of the operating system in use.\nLFThis causes the file to contain LF characters for EOL markers, regardless of the operating system in use.\nCRThis causes the file to contain CR characters for EOL markers, regardless of the operating system in use. This line-ending style is not very common.\nAnd it's worth noting again that, unlike the global-ignores option, the patterns found in the svn:ignore property apply only to the directory on which that property is set, and not to any of its subdirectories.\n\n
For example, svn checkout creates a working copy with every file and directory in the specified area of the repository, descending recursively through the repository tree until the entire structure is copied to your local disk.\nIntroduced in subversion 1.5\n
For example, svn checkout creates a working copy with every file and directory in the specified area of the repository, descending recursively through the repository tree until the entire structure is copied to your local disk.\nIntroduced in subversion 1.5\n如果只是一个参数就不值得拿出来说，特殊的地方在于，这个depth的值是会保存在working-copy中的\n1. 只checkout关心的部分\n2. subversion会记住这个depth值，后续只需直接update\n
For example, suppose Harry locks an image file and then begins editing it. Meanwhile, miles away, Sally wants to do the same thing. She doesn't think to run svn status -u, so she has no idea that Harry has already locked the file. She spends hours edit- ing the file, and when she tries to commit her change, she discovers that either the file is locked or that she's out of date. Regard- less, her changes aren't mergeable with Harry's. One of these two people has to throw away his or her work, and a lot of time has been wasted.\n\n
svn status -u\nB -- Broken\nT -- sTolen\n
\n
The --changelist option acts only as a filter for Subversion command targets, and will not add targets to an operation.\n
\n
\n
\n
This is the basic concept of a branch—namely, a line of development that exists independently of another line, yet still shares a common history if you look far enough back in time. A branch always begins life as a copy of something, and moves on from there, generating its own history\n\n
the only reason a copied directory is a “branch” is because humans have decided to treat it that way\n
\n
Why not diff? or manual \n
Notice our use of the - -reintegrate option this time around. The option is critical for reintegrating changes from a branch back into its original line of development—don't forget it! It's needed because this sort of “merge back” is a different sort of work than what you've been do- ing up until now. Previously, we had been asking svn merge to grab the “next set” of changes from one line of development (the trunk) and duplicate them to another (your branch). This is fairly straightforward, and each time Subversion knows how to pick up where it left off. \nWhen merging your branch back to the trunk, however, the underlying mathematics is quite different. Your feature branch is now a mishmash of both duplicated trunk changes and private branch changes, so there's no simple contiguous range of revisions to copy over. By specifying the --reintegrate option, you're asking Subversion to carefully replicate only those changes unique to your branch. (And in fact, it does this by comparing the latest trunk tree with the latest branch tree: the resulting difference is ex- actly your branch changes!)\n\n
\n
\n
\n
\n
Just as with branches, the only reason a copied directory is a “tag” is because humans have decided to treat it that way\n
Release Branches\nMost software has a typical life cycle: code, test, release, repeat. There are two problems with this process. First, developers need to keep writing new features while quality assurance teams take time to test supposedly stable versions of the software. New work cannot halt while the software is tested. Second, the team almost always needs to support older, released versions of software; if a bug is discovered in the latest code, it most likely exists in released versions as well, and customers will want to get that bug fix without having to wait for a major new release.\n\nFeature Branches\nIt's a temporary branch created to work on a complex change without interfering with the stability of /trunk. Unlike release branches (which may need to be supported forever), feature branches are born, used for a while, merged back to the trunk, and then ultimately deleted. They have a finite span of usefulness.\nFinally, there's the issue of how to best keep a feature branch in “sync” with the trunk as work progresses. As we mentioned earlier, there's a great risk to working on a branch for weeks or months; trunk changes may continue to pour in, to the point where the two lines of development differ so greatly that it may become a nightmare trying to merge the branch back to the trunk.\nThis situation is best avoided by regularly merging trunk changes to the branch. Make up a policy: once a week, merge the last week's worth of trunk changes to the branch.\n
\n
\n
\n
创建了太多branch会不会对svn造成性能问题及存储空间浪费？repositroy会不会急剧增长？\n\nIt doesn't matter how large the directory is—it takes a very tiny, constant amount of time and space to make a copy of it. In fact, this feature is the basis of how commits work in Subversion: each revision is a “cheap copy” of the previous revision, with a few items lazily changed within.\nSo don't be afraid to use them when needed!\n
\n
Easy reads. If a filesystem reader wants to locate revision X of file foo.c, it need only traverse the repository's history, locate revision X's root node, then walk down the tree to foo.c.\nWriters don't interfere with readers. Writers can continue to create new nodes, bubbling their way up to the top, and concurrent readers cannot see the work in progress. The new tree only becomes visible to readers after the writer makes its final “link” to the repository's history.\nFile structure is versioned. Unlike CVS, the very structure of each tree is being saved from revision to revision. File and directory renames, additions, and deletions are part of the repository's history.\n
Easy reads. If a filesystem reader wants to locate revision X of file foo.c, it need only traverse the repository's history, locate revision X's root node, then walk down the tree to foo.c.\nWriters don't interfere with readers. Writers can continue to create new nodes, bubbling their way up to the top, and concurrent readers cannot see the work in progress. The new tree only becomes visible to readers after the writer makes its final “link” to the repository's history.\nFile structure is versioned. Unlike CVS, the very structure of each tree is being saved from revision to revision. File and directory renames, additions, and deletions are part of the repository's history.\n
Easy reads. If a filesystem reader wants to locate revision X of file foo.c, it need only traverse the repository's history, locate revision X's root node, then walk down the tree to foo.c.\nWriters don't interfere with readers. Writers can continue to create new nodes, bubbling their way up to the top, and concurrent readers cannot see the work in progress. The new tree only becomes visible to readers after the writer makes its final “link” to the repository's history.\nFile structure is versioned. Unlike CVS, the very structure of each tree is being saved from revision to revision. File and directory renames, additions, and deletions are part of the repository's history.\n
Easy reads. If a filesystem reader wants to locate revision X of file foo.c, it need only traverse the repository's history, locate revision X's root node, then walk down the tree to foo.c.\nWriters don't interfere with readers. Writers can continue to create new nodes, bubbling their way up to the top, and concurrent readers cannot see the work in progress. The new tree only becomes visible to readers after the writer makes its final “link” to the repository's history.\nFile structure is versioned. Unlike CVS, the very structure of each tree is being saved from revision to revision. File and directory renames, additions, and deletions are part of the repository's history.\n
Easy reads. If a filesystem reader wants to locate revision X of file foo.c, it need only traverse the repository's history, locate revision X's root node, then walk down the tree to foo.c.\nWriters don't interfere with readers. Writers can continue to create new nodes, bubbling their way up to the top, and concurrent readers cannot see the work in progress. The new tree only becomes visible to readers after the writer makes its final “link” to the repository's history.\nFile structure is versioned. Unlike CVS, the very structure of each tree is being saved from revision to revision. File and directory renames, additions, and deletions are part of the repository's history.\n
Easy reads. If a filesystem reader wants to locate revision X of file foo.c, it need only traverse the repository's history, locate revision X's root node, then walk down the tree to foo.c.\nWriters don't interfere with readers. Writers can continue to create new nodes, bubbling their way up to the top, and concurrent readers cannot see the work in progress. The new tree only becomes visible to readers after the writer makes its final “link” to the repository's history.\nFile structure is versioned. Unlike CVS, the very structure of each tree is being saved from revision to revision. File and directory renames, additions, and deletions are part of the repository's history.\n
Easy reads. If a filesystem reader wants to locate revision X of file foo.c, it need only traverse the repository's history, locate revision X's root node, then walk down the tree to foo.c.\nWriters don't interfere with readers. Writers can continue to create new nodes, bubbling their way up to the top, and concurrent readers cannot see the work in progress. The new tree only becomes visible to readers after the writer makes its final “link” to the repository's history.\nFile structure is versioned. Unlike CVS, the very structure of each tree is being saved from revision to revision. File and directory renames, additions, and deletions are part of the repository's history.\n
Easy reads. If a filesystem reader wants to locate revision X of file foo.c, it need only traverse the repository's history, locate revision X's root node, then walk down the tree to foo.c.\nWriters don't interfere with readers. Writers can continue to create new nodes, bubbling their way up to the top, and concurrent readers cannot see the work in progress. The new tree only becomes visible to readers after the writer makes its final “link” to the repository's history.\nFile structure is versioned. Unlike CVS, the very structure of each tree is being saved from revision to revision. File and directory renames, additions, and deletions are part of the repository's history.\n
Easy reads. If a filesystem reader wants to locate revision X of file foo.c, it need only traverse the repository's history, locate revision X's root node, then walk down the tree to foo.c.\nWriters don't interfere with readers. Writers can continue to create new nodes, bubbling their way up to the top, and concurrent readers cannot see the work in progress. The new tree only becomes visible to readers after the writer makes its final “link” to the repository's history.\nFile structure is versioned. Unlike CVS, the very structure of each tree is being saved from revision to revision. File and directory renames, additions, and deletions are part of the repository's history.\n
Easy reads. If a filesystem reader wants to locate revision X of file foo.c, it need only traverse the repository's history, locate revision X's root node, then walk down the tree to foo.c.\nWriters don't interfere with readers. Writers can continue to create new nodes, bubbling their way up to the top, and concurrent readers cannot see the work in progress. The new tree only becomes visible to readers after the writer makes its final “link” to the repository's history.\nFile structure is versioned. Unlike CVS, the very structure of each tree is being saved from revision to revision. File and directory renames, additions, and deletions are part of the repository's history.\n
Easy reads. If a filesystem reader wants to locate revision X of file foo.c, it need only traverse the repository's history, locate revision X's root node, then walk down the tree to foo.c.\nWriters don't interfere with readers. Writers can continue to create new nodes, bubbling their way up to the top, and concurrent readers cannot see the work in progress. The new tree only becomes visible to readers after the writer makes its final “link” to the repository's history.\nFile structure is versioned. Unlike CVS, the very structure of each tree is being saved from revision to revision. File and directory renames, additions, and deletions are part of the repository's history.\n
Easy reads. If a filesystem reader wants to locate revision X of file foo.c, it need only traverse the repository's history, locate revision X's root node, then walk down the tree to foo.c.\nWriters don't interfere with readers. Writers can continue to create new nodes, bubbling their way up to the top, and concurrent readers cannot see the work in progress. The new tree only becomes visible to readers after the writer makes its final “link” to the repository's history.\nFile structure is versioned. Unlike CVS, the very structure of each tree is being saved from revision to revision. File and directory renames, additions, and deletions are part of the repository's history.\n
