|
Size: 2303
Comment: Expanding
|
Size: 2303
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 15: | Line 15: |
| The working directory can be ["Update"]d to any commited changeset of the repository, which then becomes the parent of the working directory. | The working directory can be ["Update"]d to any commited changeset of the repository, which then becomes the parent of the ["WorkingDirectory"]. |
| Line 17: | Line 17: |
| Committing changes in the ["WorkingDirectory"] creates a new version of the manifest and a new changeset in the repository. The parent(s) of the working directory become the parents of the changeset. | Committing changes in the working directory creates a new version of the manifest and a new changeset in the repository. The parent(s) of the working directory become the parents of the changeset. |
Changeset
A changeset (sometimes abbreviated "cset") is an atomic collection of changes to files in a ["Repository"]. The act of creating a changeset is usually called a ["Commit"] or Checkin. The information in a changeset includes
- changes to the contents of the files
- changes to file names or other external attributes (such as execute permissions)
- information about who made the change (the "committer"), why ("comments") and when (date/time, timezone)
Conceptually, each changeset has zero, one or two ["Parent"] changesets. It has two parent changesets, if the commit was a ["Merge"]. It has no parent, if the change is a root in the repository. There may be multiple roots in a repository (normally, there is only one), each representing the start of branch.
If a changeset is not the ["Head"] of branch, it has one or more child changesets (it is then the parent of its child changesets).
Technically, the parent changesets of a changeset are retrieved from the revision history of the ["Manifest"]. Each changeset references a revision of the Manifest (see ["Design"] for the technical details).
The working directory can be ["Update"]d to any commited changeset of the repository, which then becomes the parent of the ["WorkingDirectory"].
Committing changes in the working directory creates a new version of the manifest and a new changeset in the repository. The parent(s) of the working directory become the parents of the changeset.
"Updating" back to changeset which already has a child, changeing files and then commiting creates a new child, thus starting a new branch. Branches can be named (see ["NamedBranches"]).
A changeset is identified uniquely by a ["ChangeSetID"]. In a single repository, you can identify it using a RevisionNumber.
- Question: Is a changeset a particular state of the project (like a Subversion revision number), or is it a set of changes to files (like a Darcs patch)?
The way the changeset hash is calculated says that a changeset is a particular state of the project plus all of its ancestor states (i.e. all the changeset it took to get there). In Darcs that's a [http://www.darcs.net/manual/node7.html#SECTION00781000000000000000 tag].
See also: ["ChangeSetComments"]