5 ms·
They did mention Perforce in passing: > For a repository as large as ours, a major bottleneck is simply finding out what files have changed. Git examines every
by curtis 10y ago
They did mention Perforce in passing:
> For a repository as large as ours, a major bottleneck is simply finding out what files have changed. Git examines every file and naturally becomes slower and slower as the number of files increases, while Perforce "cheats" by forcing users to tell it which files they are going to edit. The Git approach doesn't scale, and the Perforce approach isn't friendly.
I don't know if Perforce's "unfriendliness" is enough reason not to choose it nor do I know if that was the only reason they rejected it. However, speaking for myself, I vastly prefer Subversion, Git, and Mercurial over Perforce precisely because Perforce requires you to ask for permission before you can edit a file.
- loeg 10y agoGit could use inotify (Linux) or kevent (BSD) to monitor for file changes in the background. It's not a limitation of the format or workflow, just the current tools.
- vvanders 10y agoOn the flip side of editing it makes locking binary files trivial which is something Git and Mercurial fail at spectacularly(since the are intrinsically DVCS).
- cheez 10y agoI wrote a simple Emacs function to automagically call p4 edit when I began editing a Perforce managed file. It worked OK. Obviously not as convenient as straight up editing, but good enough.
- dhd415 10y agoFor any of the major IDEs with Perforce plugins, this happens automatically when you start editing a file. It's essentially a non-issue for normal use cases. Things work a little differently when you're offline, but for most people, offline work is uncommon.
- slededit 10y agoYou can just edit "..." over the sub-directories you are working with. It tends to solve the problem.