Differences between revisions 2 and 3
Revision 2 as of 2005-11-04 23:13:50
Size: 5757
Comment:
Revision 3 as of 2007-06-15 08:29:15
Size: 9884
Comment:
Deletions are marked like this. Additions are marked like this.
Line 5: Line 5:
(The structure of this topic is borrowed from CvsConcepts. Thanks, guys!) Focus is on Mercurial versus Perforce. Some parts of the general description of Mercurial versus other SCM in CvsConcepts applies here too.
Line 7: Line 7:
(Perforce is a quite good commercial ["SCM"] - see http://www.perforce.com/) Perforce is a good commercial ["SCM"] - see http://www.perforce.com/
Line 25: Line 25:
Line 27: Line 26:
repository (the depot) in order to perform any operation. E.g. are
files
write protected until they are opened for edit (and thus given
an advisory lock).
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.
Line 36: Line 35:
others using USB memory sticks. E.g. can files be edited immediately;
Mercurial efficiently finds the changes.
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.
Line 89: Line 88:
The equivalent Mercurial concept is the ["Repository"], but there's no
notion in
Mercurial of "bundling" repositories together in the way
that
Perforce can map any 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 120: Line 117:
=== Running a server ===

With Perforce a daemon is running on the server, serving all clients
over the network.

=== Anonymous access ===

In ["Mercurial"], you can provide anonymous access using HTTP. You
can do this either with a CGI script (see the {{{hgweb.cgi}}} script
in the distribution) or by running a dedicated server (using the
{{{hg serve}}} command).

Mercurials HTTP server provides no access controls, so anyone who can
connect to your web server can clone any repositories you publish,
unless you take steps to secure them in some way.

=== Authenticated access ===

Mercurial allows authenticated access to repositories, by tunneling
using the {{{ssh}}} command. To perform an operation over {{{ssh}}},
compatible versions of Mercurial must be installed on both the local
and remote sides, and available through your shell's search path on
the remote side.
Line 145: Line 119:
[[Anchor(keyword)]]
== Keywords expansion ==
= Perforce-to-Mercurial Cheat sheet =
Line 148: Line 121:
Perforce can expand keywords such as $Revision: 1.12 $ by adding
information from it. This feature is not in ["Mercurial"] - see
http://www.selenic.com/pipermail/mercurial/2005-August/003887.html .
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 ||
|| 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 ||
|| 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 ||
|| 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 || 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 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 based on other ||
|| p4 integ; p4 resolve || get changes from other p4 branch || hg pull; hg merge || get changes from other repo ||
|| p4 submit || add pending changes to the chain of changesets in branch || hg commit || save changes in own repo, possibly creating new head/"branch" ||
|| 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 ||

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.

Perforce is a good commercial ["SCM"] - see http://www.perforce.com/

  • [#architecture Architecture]
  • [#rev Revisions]
  • [#tag Modules, branching and tagging]
  • [#convert Converting a Perforce repository]
  • [#collab Collaborating with other people]
  • [#keyword Keywords expansion]

Anchor(architecture)

Architecture

Perforce is a ["CentralisedSCM"]. 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 copy of the ["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.

Anchor(rev)

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 probably unique.

Anchor(tag)

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 branch is a repository. Nothing more or less. A repository is a branch. Repeat the soothing mantra.

The verb "to branch" simply means "to make a clone of a repository at a particular revision".

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.

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. 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.

Anchor(convert)

Converting a Perforce repository

For a way to convert a Perforce repository to a ["Mercurial"] ["Repository"], see ConvertingRepositories.

Anchor(collab)

Collaborating with other people

With Perforce, the standard way to share changes with other people is simply to check them in. Some projects have a convention of posting UnifiedDiff patches to a mailing list before making a check-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

    • put the exported ["PatchFile"]s on a server for someone to download

    • email the ["PatchFile"]s to a maintainer or mailing list

    • copy the ["PatchFile"]s onto a memory stick and give them to someone else

  • ["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

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

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

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

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 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 based on other

p4 integ; p4 resolve

get changes from other p4 branch

hg pull; hg merge

get changes from other repo

p4 submit

add pending changes to the chain of changesets in branch

hg commit

save changes in own repo, possibly creating new head/"branch"

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

PerforceConcepts (last edited 2013-11-17 01:37:16 by PhilipJagielski)