The Perfarce extension allows you to pull changelists from Perforce, and to push Mercurial changesets back to it. The ForestExtension can be used to something similar to Perforces mapping of arbitrary repository files into a working directory.Ĭonversion from Perforce was added in Mercurial 1.2. The equivalent Mercurial concept is the Repository. In Perforce, a client is a collection of directories that you can check out under one name. In Mercurial, a revision of a file can have two parent revisions (see Design for how this is technically implemented), which happens if the file had to be merged as a consequence of the hg merge of two Mercurial changesets.Ī Perforce tag is a symbolic name for a subset of files at certain revisions in a depot.Ī Mercurial Tag is just a symbolic name for a changeset and thus the whole manifest. See also the ImergeExtension, which provides a file by file (an incremental) resolve process similar to the one provided by p4 resolve of Perforce. Mercurial can Merge two changesets (not files) by using the hg merge command, which does a p4 integrate and p4 resolve in one step for all files in both Manifests needing a classical file merge. Mercurial can assign a branch name to a changeset (see NamedBranches), but conceptually, branches can and do exist in a Mercurial repository even if they are not named. It doesn't even matter whether this happens in the same or in different repositories. In Mercurial, a changeset can have two parents (in contrast, Perforce doesn't record this information, as all merge and branch operations are file based). Branches don't have to be anticipated in advance as in Perforce, they just happen naturally if two changesets are based on the same parent changeset (see also Heads). In Mercurial, each WorkingDirectory is a potential "branch". Client specs are used to decide which part of the depot to put in the working directory. Any file can be branched anywhere in the depot, even though branch specs often are used to specify branching paths. Perforce basically knows nothing about branches - but does it quite well anyway. To uniquely identify ChangeSets Mercurial uses ChangeSetIDs instead of RevisionNumbers changeset IDs are hashes of the content and are thus considered unique.
Mercurial RevisionNumbers describe the history of a local repository and will thus be different even in repositories which share a part or even all of their change history. A single Perforce server can be used to manage multiple "depots", and in this case changelist numbers are unique across all the depots managed by the same Perforce server! Perforce repositories are central and common for all users, and the changelist numbers are thus globally unique and used as such.
Perforce changelist numbers are similar to Mercurial revision numbers. This one writer / multiple readers design allows files to be edited without coordination with server, and changes to any version can be submitted. It is a basic assumption that users (or uses) have their own repository and pulls other changes to it. You can even share your changes with others without being directly connected - file transfer or email can be used. You do not need to be connected to any server in order to perform any operation. The command hg is used for working with files/repositories. Each working directory is self-contained and contains the files being worked on as well as a complete Repository. 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.īy contrast, Mercurial is a DistributedSCM.
#CHANGE PERFORCE DOWNLOAD DIRECTORY CODE#
It is very fundamental that multiple users can work on the same code at the same time. Perforce requires network access to the central repository (the "depot") in order to perform any operation. Perforce users create a "client" and check files out from the repository to a working directory in their local file system. The command-line utility p4 or a graphical client called p4v is used for communicating with the server and working with local/repository files.
In Perforce the repository for all users and branches lives on a central server. Perforce is a quite good commercial CentralisedSCM. Please refer to CvsConcepts for more details. Some parts of the general discussion about Mercurial and other centralized SCM systems apply here too. This document focuses on the similarities and differences of Mercurial with Perforce, a popular commercial CentralisedSCM. (Might also be usable as "Perforce for Mercurial users")
0 kommentar(er)
