Assumptions:
- Pushed/fetched changes stay in order but only within a set
There may be other changes inserted between changes
- Ability to push the same set of content to multiple servers and/or locations
- Configurable for enable/disable rewrite history
All of this should be feature flag enable/disable
- One perforce binary for all of this
Possible optimizations:
- Mark fetched revs that have been resolved to indicate indelibility
and warn if the user tries to rewrite pulled history
Potential confusions:
- Complete changes or just the file history of the specified files
- Change numbers being different between instances
If a site wants distinct change numbers, then they could turn-on/configure
some central change number system (dynamic or static ranges). If they don’t
then they don’t. In either case, the code to push/fetch would be almost the
same with only a change number translation bit added. So I don’t think we
require a definite answer on this before we start.
- Attributes, Filetypes, charset
- triggers
- user mappings / licensing
- client associated with changes
- broker / proxy / replica / edge
- case sensitivity/unicode-ness of the two servers
Future nice things:
- diff2 of remote vs local
- make text files ctext by default instead of rcs (configurable?)
- mergefrom branch to simplify process
- checkpoint current work to simplify process
- launch network server to share work (aka accept fetch requests)
init: Create a local Perforce installation typically for individual use
configured for immediate use, client, client root, etc.
p4 init <target dir>
- uses rsh
- fixes typemap to remove rcs files
- creates initial branch, sets up client
- defines p4config values to make it all work
Prevent rcs files for optimization of push/fetch?
Possible simplifying assumptions
- User is super, all others get read access
- Single-user repository
- Single-user, unlimited clients when in single-user configuration
- Do allow definiting additional users/passwords for controlling
fetch requests
branch: Create a new branch of the currently viewed branch
switching to the new branch and updating working directory
resolves pending work in some mapper
p4 branch <newBranchName> OR p4 switch -b <newBranchName>
- populates the new branch
- updates client, syncs
Branch from arbitrary points in history
Possible simplifying assumptions:
- //branches/<branch>/... is how branches are stored locally
- branch-name clients define each branch
- only supported in single-user repositories
switch: Switch to a branch, resolving pending work in some manner
update working directory
p4 switch <existingBranchName>
- checks for unresolved work and offers options
- updates client, syncs
- adds in previous unresolved work
Possible simplifying assumptions:
- Only supported in single-user repositories
push: Copy content from this Perforce installation into some other installation
Content can be relocated in the other installation
Requires the content to fit into the target installation
otherwise fetch/resolve needs to be done before pushing
all content needs to add to the target system, no rewriting of existing
content
p4 push <targetInstall> <contentDefinition> <relocationDetails>
- determine changes and hence files to push
- extract filelog for each file send to server
- server validates that for every file, only new revisions are being added
- server requests archive and change list bundle
Auto failover into fetch/resolve on failure
Possible simplifying assumptions:
- Only supported to multi-user repositories
fetch: Copy content from some other Perforce installation into this one
Content can be relocated as part of this transfer
Resolve all incoming content automatically
Trigger resolve for all conflicts
p4 fetch <targetInstall> <contentDefinition> <relocationDetails>
- determine changes and hence files to fetch
- extract filelog for each file to be retrieved
- determine new archive data and retrieve it
- update all change/revs that just add to the history, updating archive
Limited history pulled on fetch
Possible simplifying assumptions:
- Initial version only works for non-conflict cases
- Multi-user repositories require non-conflict cases
- Single-user repositories could support conflict resolution
resolve: Unwind local history such that fetched content can be installed
Restore unwound history on top of the fetched content
p4 integFetch
- determine which changes need to be redone, shelve/obliterate
- apply revs and update archive
- cycle through shelves
- interactive for conflicts, automatic when possible
Possible simplifying assumptions:
- Only supported in single-user repositories
rewrite: Unwind local history and rewrite it as desired
p4 rewrite
Unwind specified sections of history
Interactively restore/re-arrange the bits
Revert last change as a subset of functionality
rollback, backout, ...
Possible simplifying assumptions:
- Only supported in single-user repositories