#scalable

  • Why Perforce is more #scalable than #Git - Steve Hanov’s Programming Blog
    http://stevehanov.ca/blog/index.php?id=50

    Git can’t handle large repositories
    Okay this is subjective because it depends on your definition of large. When I say large, I mean about 6 gigs or so. Because your company’s source tree is probably that large.
    [...]
    The typical git user considers the linux kernel to be a “large project”. If you’ve looked at Linus’s git rant on Google code, take a listen to see how he sidesteps the question of scalability.

    Don’t believe me? Fine. Go ahead and wait a minute after every git command while it scans your entire repo. It’s maddening because its long enough to be annoying
    [...]
    The solution

    You know what? I don’t think many people really use distributed source control. The centralized model is here to stay. Most git users (especially those using #Github) use the centralized model anyway.

    Ask yourself this: Is it really that important to duplicate the entire history on every single PC? Do you really need to peruse changelist 1 of KDE from an airplane? In most cases, NO. What you really want is the other stuff: easy branching, clean, and stash, and the ability to transfer changes to another client. The distributed stuff isn’t really asked for, or needed. It just makes it hard to learn.

    #développement #synchronisation #scalability #décentralisation #unhosted

    • Quelqu’un ici aurait des retours sur l’utilisation de Git sur des grands répertoires ?

      Je suis en train de réfléchir à une solution pour versionner nativement un système de base de données qui serait cloné chez chacun, mais du coup, est-ce que Git peut fonctionner dans ce cas ?

      Je crois qu’il y a moyen qu’un dépôt central contienne tout l’historique, mais que chacun chez soi on peut n’avoir que les derniers trucs. Mais je ne connais pas bien Git pour le moment, donc je demande...