5 ms·

It's funny how they did not use Perforce which works really well for large repositories.

• 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 ago
    Git 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 ago
    On 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 ago
    I 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 ago
    For 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 ago
    You can just edit "..." over the sub-directories you are working with. It tends to solve the problem.
• lazzlazzlazz 10y ago
  Having used Perforce for nearly five years, I can say it's an absolute nightmare for many reasons.
  • gaius 10y ago
    Having also used Perforce for many years, I can say it is quite literally the best thing ever.
    • turaw 10y ago
      Augh, I've been trying to like Perforce for a year and have hated it at every turn. I invariably wind up having ~3 workspaces open so as to map to different parts (or different views of the same) of the depot, constantly swapping back and forth between them whenever there's a problem that requires attention on some stream or another. Code reviews are awful; I need to balance tonnes of CLs (and their shelves) so as to save _my_ current work, grab the reviewed code, reset everything etc (or I could just make a new workspace for each review! hahahah). There's also this ever-present feeling of dread whenever I invoke any p4 command -- if I absentmindedly submit something with unshelving the change that I had shelved after making a previous change but reverted when trying out a new change, I can wipe my old data and lose work. Or some issue comes up in a deployed environment, so I have to grab a new workspace (or dance through shelving/unshelving all my open CLs), have a 10 minute coffee break while it syncs, sync up to the release line and work on that one. Also my IDE doesn't like being switched rapidly between repositories all the time. Also it's difficult to just _commit_ some code after making a change and wanting to save progress. Every operation is just so stress inducing; how do you handle it :/
• dmoy 10y ago
  Perforce also runs into problems for sufficiently large repos, so it would have been a very temporary solution at best.