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 init: Create a local Perforce installation typically for individual use configured for immediate use, client, client root, etc. p4 init - 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 - 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 - populates the new branch - updates client, syncs Branch from arbitrary points in history Possible simplifying assumptions: - //branches//... is how branches are stored locally - branch-name clients define each branch switch: Switch to a branch, resolving pending work in some manner update working directory p4 switch - checks for unresolved work and offers options - updates client, syncs - adds in previous unresolved work 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 - 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 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 - 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 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 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, ...