4 ms·

Being able to disappear/discard history has significant downsides, too. Regardless, you can rollback changes in subversion without bungling future merges.

• dexen 16y ago
  > Being able to disappear/discard history has significant downsides, too. Yes and no. You can remove something from history if all holders of the copies agree with that. You can't forcefully remove anything from anybody's history if they don't actively cooperate. So no malicious data loss possible, but an agreed-upon cleanup is. Nb., in SVN only a central repo holds the full history. Should the admin remove some changeset, there's no way to check, or prove, that it ever was there. That is a (formal, legal etc) problem in certain situations. With Git, once you've fetched a changeset, it's there, all yours (till you explicitly remove it). In SVN, should a malicious blackhat break in and add backdoor to code in a central repo, noone will notice. In Git, correctness and consistency is ensured courtesy of SHA1. In Git and in SVN you can alter history. In Git, it's either `everybody agrees' or `somebody notices something went haywire because changeset chain doesn't match'. In SVN, it's `I trust the central repo with everything, fingers crossed'.
  • nupark 16y ago
    > Yes and no. You can remove something from history if all holders of the copies agree with that. You can't forcefully remove anything from anybody's history if they don't actively cooperate. These features also make it very easy to make mistakes with your own local repository, and propagate those mistakes upstream (even if they can then be detected and resolved), which was the original poster's point, as I recall. > In SVN, it's `I trust the central repo with everything, fingers crossed'. In reality, this isn't an issue for organizations, and decentralization introduces a considerable amount of complexity that confuses most users. Businesses already rely on the correctness of centralized resources and have straight-forward processes to monitor and maintain them -- be it accounting data, a centralized CA, their corporate directory and payroll system, or SCM. Ignoring the fact that this level of validation largely unnecessary -- if I were going to modify subversion to institute better validation of data, I would implement PKI signing of commits, not decentralization of the repository. Git has some support for this, but honestly this is not very high on the list of most organization's priorities, and largely only matters more for open source projects, if at all.