|
Size: 567
Comment:
|
Size: 2408
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 3: | Line 3: |
| A changeset (sometimes abbreviated "cset") is an atomic collection of changes to files in a repository. The act of creating a change set is usually called a ["Commit"]. The information in a changeset may include | 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 |
| Line 7: | Line 7: |
| * information about who made the change (the "committer") and why ("comments") | * information about who made the change (the "committer"), why ("comments") and when (date/time, timezone) |
| Line 9: | Line 9: |
| A changeset is identified uniquely by a ChangeSetID. In a single repository, you can identify it using a RevisionNumber. | 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 changeset 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 a 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 changelog file in the repository (files {{{00changelog.i}}} and {{{00changelog.d}}} in {{{.hg/store}}}). Each changeset references a revision of the ["Manifest"] (see ["Design"] for the technical details). The ["WorkingDirectory"] can be ["Update"]d to any commited changeset of the repository, which then becomes the parent of the working directory. Committing changes in the working directory creates a new revision in the manifest and a new changeset (a new revision in the changelog). The parent(s) of the working directory become the parents of the changeset. "Updating" back to a 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"] ---- CategoryGlossary |
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)
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 changeset 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 a 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 changelog file in the repository (files 00changelog.i and 00changelog.d in .hg/store). Each changeset references a revision of the ["Manifest"] (see ["Design"] for the technical details).
The ["WorkingDirectory"] can be ["Update"]d to any commited changeset of the repository, which then becomes the parent of the working directory.
Committing changes in the working directory creates a new revision in the manifest and a new changeset (a new revision in the changelog). The parent(s) of the working directory become the parents of the changeset.
"Updating" back to a 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"]