Git | Perforce Command Line | P4V | Notes |
---|---|---|---|
git pull | p4 sync | get latest revision | |
n/a | p4 update | ? | Get latest revision without overwriting files that have been changed. |
git checkout | p4 edit | checkout | You plan to change a file from the version control system |
git commit | p4 submit | submit | |
git push | n/a | n/a | No perforce equivalent. There is no concept of a pure local submit in Perforce. |
git status | p4 status | ? | |
git stash | p4 shelve | ||
git blame | p4 annotate |
Git | Perforce |
---|---|
Git | Perforce |
Repository | Depot |
Local Repository | Workspace |
1 - Get the files from the server
cd /Users/turtle/work
p4 sync
2 - Checkout the file you want to work on and modify it
p4 edit main/foo;
echo cake >> main/foo
3 - Submit it to the server
p4 submit -d "A trivial edit"
- Revert all changes
p4 revert //...
- Restore workspace files to match the state of corresponding depot files.
p4 clean
Resources:
'p4 edit' is definitely an 'n/a', and it's linked to one of the massively distinguishing features of perforce.
Perforce has a concept of a global lock, which it turns out is critical for things like binary assets. If two artists are working on the same texture, how do you merge that? And since perforce lets everyone see the depot differently, it's quite common for people to not realize they're treading on someone else's work thru other means.
So p4 defaults to marking all files read-only so that you cant easily change something you didn't intend to (a common thing with art tools which will randomly rewrite config files or re-generate some source item).
With svn/git you run status and it goes off and checks files for changes.
With p4, you tell perforce first with p4 edit. In exchange, it unlocks the file(s) for you and associates them with your current/default changelist.
So, it's closer to "git stage", but then it's also not that, because it has nothing to do with changes already made...
But last and MOST importantly:
"p4 edit" interacts with files that are marked as requiring global locks, so that only one person can manipulate that file across a stream.