|
Size: 3580
Comment: cleanup after merge
|
Size: 2539
Comment: reverting to rev 43 (spam)
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| <<Include(A:delete)>> |
|
| Line 5: | Line 7: |
| A '''changeset''' (sometimes abbreviated "cset") is an atomic collection of changes to files in a [:Repository:repository]. It contains all recorded [:LocalModifications:local modfication] that lead to a new [:Revision:revision] of the repository. | A '''changeset''' (sometimes abbreviated "cset") is an atomic collection of changes to files in a [[Repository|repository]]. It contains all recorded [[LocalModifications|local modfication]] that lead to a new [[Revision|revision]] of the repository. |
| Line 7: | Line 9: |
| A changeset is identified uniquely by a [:ChangeSetID:changeset ID]. In a single repository, you can identify it using a [:RevisionNumber:revision number]. | A changeset is identified uniquely by a [[ChangeSetID|changeset ID]]. In a single repository, you can identify it using a [[RevisionNumber|revision number]]. |
| Line 9: | Line 11: |
| The act of creating a changeset is called a [:Commit:commit] or checkin. The information in a changeset includes | The act of creating a changeset is called a commit or checkin. A changeset includes the actual changes to the files and some meta information. The meta information in a changeset includes: |
| Line 11: | Line 13: |
| * changes to the contents of the files * added/removed/moved files * changes to file names or other external attributes (such as execute permissions) |
* the [[Nodeid|nodeid]] of its [[Manifest|manifest]] * the list of changed files |
| Line 15: | Line 16: |
| * the name of the branch ("default", if omitted or not set) | * the name of the [[Branch|branch]] ("default", if omitted or not set) |
| Line 17: | Line 18: |
| Each changeset has zero, one or two [:Parent:parent] changesets. It has two parent changesets, if the commit was a [:Merge: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 a branch. | Each changeset has zero, one or two parent changesets. It has two parent changesets, if the commit was a [[Merge|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 a branch. |
| Line 19: | Line 20: |
| If a changeset is not the [:Head:head] of a branch, it has one or more child changesets (it is then the parent of its child changesets). | If a changeset is not the [[Head|head]] of a branch, it has one or more child changesets (it is then the parent of its child changesets). |
| Line 21: | Line 22: |
| Technically, the parent changesets of a changeset are retrieved from the revision history of the changelog file(s) in the repository (files {{{00changelog.i}}} and {{{00changelog.d}}} in {{{.hg/store}}}). Each changeset contains the [:Nodeid:nodeid] its associated [:Manifest:manifest]. | The [[WorkingDirectory|working directory]] can be [[Update|updated]] to any commited changeset of the repository, which then becomes the parent of the working directory. |
| Line 23: | Line 24: |
| The [:WorkingDirectory:working directory] can be [:Update:updated] to any commited changeset of the repository, which then becomes the parent of the working directory. | "Updating" back to a changeset which already has a child, changing files and then committing creates a new child changeset, thus starting a new branch. Branches can be [[NamedBranches|named]]. |
| Line 25: | Line 26: |
| 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 new changeset and the new changeset becomes the new parent of the working directory. "Updating" back to a changeset which already has a child, changeing files and then committing creates a new child changeset, thus starting a new branch. Branches can be [:NamedBranches:named]. * 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]. Changesets are stored in [:Revlog:revlog] format (see the file {{{.hg/store/00changelog.d}}}) and an associated index ({{{.hg/store/00changelog.i}}}). |
All changesets of a repository are stored in the changelog. |
| Line 43: | Line 36: |
| Clean up local clone file list | Clean up local clone file list |
| Line 50: | Line 43: |
See also: ["ChangeSetComments"], ["Design"] |
See also: [[ChangeSetComments]], [[Design]] |
| Line 55: | Line 47: |
[[FrenchChangeSet|Français]] |
|
This page is proposed for deletion. See our
Changeset
(for a short intro of the basic concepts of Mercurial, see UnderstandingMercurial)
A changeset (sometimes abbreviated "cset") is an atomic collection of changes to files in a repository. It contains all recorded local modfication that lead to a new revision of the repository.
A changeset is identified uniquely by a changeset ID. In a single repository, you can identify it using a revision number.
The act of creating a changeset is called a commit or checkin. A changeset includes the actual changes to the files and some meta information. The meta information in a changeset includes:
- the list of changed files
- information about who made the change (the "committer"), why ("comments") and when (date/time, timezone)
the name of the branch ("default", if omitted or not set)
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 a 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).
The working directory can be updated to any commited changeset of the repository, which then becomes the parent of the working directory.
"Updating" back to a changeset which already has a child, changing files and then committing creates a new child changeset, thus starting a new branch. Branches can be named.
All changesets of a repository are stored in the changelog.
Here's what the internal representation of a changeset looks like:
$ hg debugdata .hg/00changelog.d 1208 1102691ceab8c8f278edecd80f2e3916090082dd <- the corresponding manifest nodeid mpm@selenic.com <- the committer 1126146623 25200 <- the date, in seconds since the epoch, and seconds offset from UTC mercurial/commands.py <- the list of changed files, followed by the commit message Clean up local clone file list We now use an explicit list of files to copy during clone so that we don't copy anything we shouldn't.
See also: ChangeSetComments, Design