4 ms·

Ive been using perforce/p4 since 97. the last 8 years have been coupled with P4V and the eclipse plugins. My workflow is virtually identical to the much offered

Ive been using perforce/p4 since 97. the last 8 years have been coupled with P4V and the eclipse plugins. My workflow is virtually identical to the much offered Git branching model [0]. Turn it -90deg with time left to right. Rename "develop" to "trunk". and think of "master" as being the release labels. release and feature branches are created from the build label of the previous release needing special changes that can not just go into trunk or when we want to do a minimal patch-only release. a developer makes local copy of the portions of the trunk they want/need. the server knows who has what opened for edit/add which makes checkins fast. only the change must go in. same for regular update of my local workspace. we rarely have people editing the same exact file and if we do its a simple resolve in P4V during your commit or integrate activity. So far, there are FEW benefits i see to using, or switching to, GIT: LOCAL REPOSITORY - I have the whole repo for what i am working on so can work remote easier LOCAL VERSIONING - I can create lightweight local branches that duplicate only what is required without resync of my local repo POPULARITY - all the cook kids are using it so lots of ops utilities now are built expecting it to be there under the covers. I can live without the LOCAL benefits. I have for 8 years. I worry about the third - popularity vs. merit. Where are the concrete comparisons showing all the features and functions of these solutions side by side and how they compare for a student, startup, or enterprise? EDIT: found a newer perforce:git comparison on the perforce site[1]. The LOCAL REPO/VERSIONING is available with P4SANDBOXING. I suppose modding me down is appropriate since i picked up on the POPULARITY aspect of the discussion and don't have any Hg experience. However, it seems these discussions just keep happening and there is no one-true-solution or approach. they each have merits and faults. it will be the careful consideration of these that leads to your own solution implementation. The popularity of GIT appears to be its strongest argument. EDIT2: located a GIT-v-Perforce on SO.[2] so many of the diffs, however, have been met with sandboxing It really appears the strength is in popularity - everyone else uses GIT so you should too… [0]: http://nvie.com/posts/a-successful-git-branching-model/ http://nvie.com/posts/a-successful-git-branching-model/ [1]: http://www.perforce.com/sites/default/files/pdf/perforce-git-comparison.pdf http://www.perforce.com/sites/default/files/pdf/perforce-git... [2]: http://stackoverflow.com/questions/222782/git-vs-perforce-two-vcs-will-enter-one-will-leave http://stackoverflow.com/questions/222782/git-vs-perforce-tw...

rallison 13y ago
I'll mention that a number of the answers covered in this StackOverflow post [1] (note, that post is old, so it is entirely possible that perforce has improved since then) cover a number of the reasons I prefer git over perforce, but, for me, cheap branching and speed (due to everything being local) are probably the two biggest. Cheap branching, especially, completely changed my workflow. When a branch is effectively free, and switching between branches is quick, a lot of doors are opened. And I say this as someone who really liked perforce previously. I just think git is more capable, albeit with a higher learning curve. [1] http://stackoverflow.com/questions/222782/git-vs-perforce-two-vcs-will-enter-one-will-leave http://stackoverflow.com/questions/222782/git-vs-perforce-tw...
- MikeTLive 13y ago
  you found the same one that i did while editing. if git is great, is it worth changing an enterprise to use it? when the auditors come, I need to list the changes on a server. when its an app, the changes to that app. who, what, when, where, why - reviewer, requestor, approver, author, deployer, etc.etc.etc. how granular and how far back can i get this with GIT? how solid is the nonrepudiation factor with GIT? for commits - can i see who else might be looking at code? for security - can i protect others from getting the code?
  - eru 13y ago
    Does perforce provide cryptographic checksums? If not, git is actually a win as far as the auditors are concerned. git does not allow any changes to history. You can make new history and garbage-collect the old history. But for a fixed commit hash, all history and all contents are fixed forever. For extra security, you can sign the commits (ie their hashes) with your PGP key. > how solid is the nonrepudiation factor with GIT? Rock solid: as far as I can tell (from https://en.wikipedia.org/wiki/Perforce https://en.wikipedia.org/wiki/Perforce) in Perforce you have to trust your admin not to go behind your back and change history. In git you have cryptographic hashes to protect your history and content. > for security - can i protect others from getting the code? git leaves the protection to the file system permissions. git doesn't track who requested a change nor why. People usually do this via conventions in their commit messages. You can write plug-ins to enforce these conventions.

rallison 13y ago

I'll mention that a number of the answers covered in this StackOverflow post [1] (note, that post is old, so it is entirely possible that perforce has improved since then) cover a number of the reasons I prefer git over perforce, but, for me, cheap branching and speed (due to everything being local) are probably the two biggest. Cheap branching, especially, completely changed my workflow. When a branch is effectively free, and switching between branches is quick, a lot of doors are opened. And I say this as someone who really liked perforce previously. I just think git is more capable, albeit with a higher learning curve. [1] http://stackoverflow.com/questions/222782/git-vs-perforce-two-vcs-will-enter-one-will-leave http://stackoverflow.com/questions/222782/git-vs-perforce-tw...

MikeTLive 13y ago
you found the same one that i did while editing. if git is great, is it worth changing an enterprise to use it? when the auditors come, I need to list the changes on a server. when its an app, the changes to that app. who, what, when, where, why - reviewer, requestor, approver, author, deployer, etc.etc.etc. how granular and how far back can i get this with GIT? how solid is the nonrepudiation factor with GIT? for commits - can i see who else might be looking at code? for security - can i protect others from getting the code?
- eru 13y ago
  Does perforce provide cryptographic checksums? If not, git is actually a win as far as the auditors are concerned. git does not allow any changes to history. You can make new history and garbage-collect the old history. But for a fixed commit hash, all history and all contents are fixed forever. For extra security, you can sign the commits (ie their hashes) with your PGP key. > how solid is the nonrepudiation factor with GIT? Rock solid: as far as I can tell (from https://en.wikipedia.org/wiki/Perforce https://en.wikipedia.org/wiki/Perforce) in Perforce you have to trust your admin not to go behind your back and change history. In git you have cryptographic hashes to protect your history and content. > for security - can i protect others from getting the code? git leaves the protection to the file system permissions. git doesn't track who requested a change nor why. People usually do this via conventions in their commit messages. You can write plug-ins to enforce these conventions.