9884
Comment:
|
9909
|
Deletions are marked like this. | Additions are marked like this. |
Line 6: | Line 6: |
Perforce is a good commercial ["SCM"] - see http://www.perforce.com/ |
|
Line 20: | Line 18: |
Perforce is a ["CentralisedSCM"]. The repository for all users and | [http://www.perforce.com/ Perforce] is a (in manys opinion) quite good commercial ["CentralisedSCM"]. In Perforce the repository for all users and |
Line 30: | Line 29: |
By contrast, ["Mercurial"] is a ["DistributedSCM"]. Each working directory | By contrast, Mercurial is a ["DistributedSCM"]. Each working directory |
Line 32: | Line 31: |
copy of the ["Repository"]. The command {{{hg}}} is used for working with | complete ["Repository"]. The command {{{hg}}} is used for working with |
Line 42: | Line 41: |
Perforce changelist numbers are similar to ["Mercurial"] revision | Perforce changelist numbers are similar to Mercurial revision |
Line 45: | Line 44: |
["Mercurial"] ["RevisionNumber"]s describe the history of a local |
Mercurial ["RevisionNumber"]s describe the history of a local |
Line 49: | Line 47: |
used instead; they are hashes of the content and are thus probably unique. | used instead; they are hashes of the content and are thus considered unique. |
Line 63: | Line 61: |
In ["Mercurial"], a branch is a repository. Nothing more or less. A repository is a branch. Repeat the soothing mantra. |
In Mercurial, a repository is a branch. Instead of creating a branch you create a repository. |
Line 69: | Line 65: |
If every repository is a branch, how do you keep track of which one is which? That's simply a matter of convention. ["Mercurial"] has no idea which ["Repository"] is "main", or which is a "branch"; it's all a matter of how you use the repositories. See WorkingPractices and CvsLikePractice for some suggestions. |
As in Perforce it is a matter of convention which branches main-line, development/project and release branches. There is no (need for) branchspecs to specify the flow of changes. A repo can have references default push/pull repos. See WorkingPractices and CvsLikePractice for some suggestions to how a Mercurial workflow can look like. |
Line 80: | Line 74: |
A Mercurial ["Tag"] is just a symbolic name for a ChangeSet. See | A Mercurial ["Tag"] is just a symbolic name for a ChangeSet and thus the whole ["Manifest"]. See |
Line 88: | Line 82: |
The equivalent Mercurial concept is the ["Repository"]. The Mercurial Forest extension can be used to something similar to Perforces mapping of arbitrary repository files into a working directory. | The equivalent Mercurial concept is the ["Repository"]. The Mercurial Forest extension can be used to something similar to Perforces mapping of arbitrary repository files into a working directory. |
Line 94: | Line 89: |
For a way to convert a Perforce repository to a ["Mercurial"] ["Repository"], see ConvertingRepositories. |
See ConvertingRepositories. |
Line 102: | Line 96: |
simply to check them in. Some projects have a convention of posting UnifiedDiff patches to a mailing list ''before'' making a check-in. |
that all contributors are licensed users on the same server and simply check them in. |
Line 105: | Line 99: |
In ["Mercurial"], collaboration is much more flexible. You can share | In Mercurial, collaboration is much more flexible. You can share |
Line 124: | Line 118: |
|| '''Concepts''' || || client/workspace || read-only files, all meta info is in server depot || WorkingDirectory (WD)|| plain files and .hg store || || depot || central repository || .hg store || whole repository in each WD || || changelist || changes to a set of files, depot-global || changeset || changes to a set of files, local to .hg store || || base version || the version a file is based on || parent version || the changeset a WD is based on || || head || the latest change in a branch, new changes must be based on this || tip || the changeset that happens to have appeared last in .hg store || || branch || location in depot dedicated to one project || WD || usually related WDs are used instead of branches || || '''Working on files''' || changes are pending in WD until commit || || changes are pending in WD until commit || |
|| '''Concepts''' || || || || || client/workspace || read-only files, all meta info is in server depot || WorkingDirectory (WD)|| plain files and .hg store with dirstate and history || || depot || central repository || .hg store || the whole ["Repository"] is in each WD || || changelist || changes to a set of files, depot-global || ChangeSet || changes to a set of files, local to .hg store || || base version || the version a file is based on || ["Parent"] version || the changeset a WD is based on || || head || the latest change in a branch, new changes must be based on this || ["Tip"] || the changeset that happens to have appeared last in .hg store || || branch || location in depot dedicated to one project || WD or ["Head"] || usually a branch is a WD, but a repo can also contain branches || || '''Working on files''' || changes are pending in WD until commit || || changes are pending in WD until ["commit"] || |
Line 137: | Line 131: |
|| - || || hg status || list unknown files - they should be added or listed in .hgignore || || [http://www.perforce.com/perforce/technotes/note012.html ???] || schedule add added and remove removed files || hg addremove || automatic add+remove || |
|| - || || hg status || list unknown files - they should be added or listed in [".hgignore"] || || [http://www.perforce.com/perforce/technotes/note012.html ???] || schedule add added and remove removed files || hg addremove || automatic add+remove if not [".hgignore"]d || |
Line 141: | Line 135: |
|| p4 revert || drop all changes, revert to base version || hg revert || drop all WD changes, revert to parent version || || p4 revert || drop all changes, revert to base version || hg update -C || drop all meta changes, revert to known state || |
|| p4 revert || drop all changes, revert to base version || hg revert || restore files content to any version from repo, no meta data changed || || p4 revert || drop all changes, revert to base version || hg update -C || drop all meta changes, revert WD to known state || |
Line 144: | Line 138: |
|| '''Looking in repository''' || changes nothing || || changes nothing || | || '''Looking in repository''' || changes nothing || || changes nothing || |
Line 158: | Line 152: |
|| p4 client; p4 integ || create a new branch+client based on other || hg clone || create new hg WD based on other || | || p4 client; p4 integ || create a new branch+client based on other || hg clone || create new hg WD/branch based on other || |
Line 160: | Line 154: |
|| p4 submit || add pending changes to the chain of changesets in branch || hg commit || save changes in own repo, possibly creating new head/"branch" || | |
Line 165: | Line 158: |
|| p4 submit || add pending changes to the chain of changesets in branch || hg commit || save changes in own repo, possibly creating new head/"branch" || |
Mercurial for Perforce users
(Might also be usable as "Perforce for Mercurial users")
Focus is on Mercurial versus Perforce. Some parts of the general description of Mercurial versus other SCM in CvsConcepts applies here too.
- [#architecture Architecture]
- [#rev Revisions]
- [#tag Modules, branching and tagging]
- [#convert Converting a Perforce repository]
- [#collab Collaborating with other people]
- [#keyword Keywords expansion]
Architecture
[http://www.perforce.com/ Perforce] is a (in manys opinion) quite good commercial ["CentralisedSCM"]. In Perforce the repository for all users and branches lives on a central server. The command p4 is used for communicating with the server and working with local/repository files. Users create a "client" and checks files out from the repository to a working directory in their local file system. Perforce requires that you have network access to the central repository (the depot) in order to perform any operation. It is very fundamental that multiple uses can work on the same code at the same time. As a consequence of this files are write protected until they are opened for edit (and thus given an advisory lock), and only changes to the newest version can be submitted to the repository.
By contrast, Mercurial is a ["DistributedSCM"]. Each working directory is self-contained and contains the files being worked on as well as a complete ["Repository"]. The command hg is used for working with files/repositories. You do not need to be connected to any server in order to perform any operation. You can even share your changes with others without being directly connected - file transfer or email can be used. It is a basic assumption that users (or uses) have their own repository and pulls other changes to it. This one writer / multiple readers design allows files to be edited without coordination with server, and changes to any version can be submitted.
Revisions
Perforce changelist numbers are similar to Mercurial revision numbers. Perforce repositories are central and common for all users, and the changelist numbers are thus globally unique and used as such. Mercurial ["RevisionNumber"]s describe the history of a local ["Repository"] and will thus be different even in similar repositories. To identify ["ChangeSet"]s ["ChangeSetID"]s are used instead; they are hashes of the content and are thus considered unique.
Modules, branching and tagging
Perforce basically knows nothing about branches - but does it quite well anyway. Any file can be branched anywhere in the depot, even though branch specs often are used to specify branching paths. Client specs are used to decide which part of the depot to put in the working directory.
Branches
In Mercurial, a repository is a branch. Instead of creating a branch you create a repository. The verb "to branch" simply means "to make a clone of a repository at a particular revision".
As in Perforce it is a matter of convention which branches main-line, development/project and release branches. There is no (need for) branchspecs to specify the flow of changes. A repo can have references default push/pull repos. See WorkingPractices and CvsLikePractice for some suggestions to how a Mercurial workflow can look like.
Tags
A Perforce tag is a symbolic name for a subset of files at certain revisions in a depot.
A Mercurial ["Tag"] is just a symbolic name for a ChangeSet and thus the whole ["Manifest"]. See ["Tag"] for a little more discussion.
Clients
In Perforce, a client is a collection of directories that you can check out under one name.
The equivalent Mercurial concept is the ["Repository"]. The Mercurial Forest extension can be used to something similar to Perforces mapping of arbitrary repository files into a working directory.
Converting a Perforce repository
Collaborating with other people
With Perforce, the standard way to share changes with other people is that all contributors are licensed users on the same server and simply check them in.
In Mercurial, collaboration is much more flexible. You can share changes in any number of ways, including (but not limited to) the following:
["Export"] one or more ["ChangeSet"]s and
["Push"] (or rsync) the ["ChangeSet"]s into a ["Repository"] from which other people can ["Pull"] them
- ["Clone"] a copy of the ["Repository"] onto a CD-ROM and hand it to someone else
Perforce-to-Mercurial Cheat sheet
This table gives hints to some related Perforce and Mercurial commands or concepts. Some commands are the same. Some commands just use different words or syntax. Some commands have no direct counterpart, so there the relation is kind of "instead you could use this command which does something else".
Perforce |
Description |
Mercurial |
Description |
Concepts |
|
|
|
client/workspace |
read-only files, all meta info is in server depot |
WorkingDirectory (WD) |
plain files and .hg store with dirstate and history |
depot |
central repository |
.hg store |
the whole ["Repository"] is in each WD |
changelist |
changes to a set of files, depot-global |
changes to a set of files, local to .hg store |
|
base version |
the version a file is based on |
["Parent"] version |
the changeset a WD is based on |
head |
the latest change in a branch, new changes must be based on this |
["Tip"] |
the changeset that happens to have appeared last in .hg store |
branch |
location in depot dedicated to one project |
WD or ["Head"] |
usually a branch is a WD, but a repo can also contain branches |
Working on files |
changes are pending in WD until commit |
|
changes are pending in WD until ["commit"] |
p4 edit |
open a file for edit |
- |
hg detects automatically |
p4 add |
add files |
hg add |
add files |
p4 delete |
remove files |
hg remove |
remove files |
p4 diff |
show diff for files opened for edit |
hg diff |
show diff for all changed files |
p4 opened |
show scheduled changes |
hg status |
show scheduled changes |
- |
|
hg status |
list unknown files - they should be added or listed in [".hgignore"] |
[http://www.perforce.com/perforce/technotes/note012.html ???] |
schedule add added and remove removed files |
hg addremove |
automatic add+remove if not [".hgignore"]d |
p4 integ; p4 delete |
move file keeping history |
hg rename |
move file keeping history |
p4 integ |
copy file keeping history |
hg copy |
copy file keeping history |
p4 revert |
drop all changes, revert to base version |
hg revert |
restore files content to any version from repo, no meta data changed |
p4 revert |
drop all changes, revert to base version |
hg update -C |
drop all meta changes, revert WD to known state |
p4 sync |
update p4 client to other repo version |
hg update |
update hg WD to other repo version |
Looking in repository |
changes nothing |
|
changes nothing |
p4 print |
show repository file |
hg cat |
show repository file |
p4 annotate |
show modification info for each line in a file |
hg annotate |
show modification info for each line in a file |
p4 changes |
show history of (branch of) repo |
hg log |
show history of repo |
p4 filelog |
show history of file |
hg log |
show history of file |
p4 tag |
add a tag for a ChangeSet |
hg tag |
add a ["Tag"] for a ChangeSet |
p4 have |
show info for client files |
hg parent |
show parent of WorkingDirectory |
p4 have |
show info for client files |
hg identify |
show info for WorkingDirectory |
p4 have |
show info for client files |
hg manifest |
list files in repo version |
p4 files |
show info for repo files |
hg manifest |
list files in repo version |
p4 branches |
list branch specifications - that is officielly related branches |
hg heads |
show heads, that is changes not merged |
p4 describe |
show changelist with its changes |
hg log -p |
show patch-like changelist |
Working with repository |
all changes are pending until submit |
|
changes local repo immediately - and perhaps WD |
p4 client |
create a new branch+client from scratch |
hg init |
create hg WD from scratch |
p4 client; p4 integ |
create a new branch+client based on other |
hg clone |
create new hg WD/branch based on other |
p4 integ; p4 resolve |
get changes from other p4 branch |
hg pull; hg merge |
get changes from other repo |
p4 integ |
integrate changes from other branch |
hg pull; hg merge |
get other version from a hg repo and merge with own repo |
p4 integ |
integrate changes to other branch |
hg push |
push own repo to other repo - but it is recommended to pull instead |
(diff; merge) |
can't move changes to other repos - must be done manually |
hg bundle |
create distributable file with all repo info |
p4 sync; p4 resolve |
rebase scheduled changes to other repo version |
- |
don't mess with uncommitted changes - commit and merge instead |
p4 submit |
add pending changes to the chain of changesets in branch |
hg commit |
save changes in own repo, possibly creating new head/"branch" |