Hacker News Reader

Comment by dexen | Hacker News Reader

Merging about 240 files from big-change-branch into the main branch and also merging a small, incremental development branch into main at the same moment is a tight spot whatever version control you use.

Nothing worked anymore and the IDE managed only to spew out a dialog error saying `Nieprawid.'.

In git, cleaning the server up took just some command typing on developer machine. Could have been done from TortoiseGit, if they wanted to. The best thing is, the clean-up was `perfect' in that it left no traces of the fubar whatsoever. No faux merge left to trip up future merges by mis-placing the base version. Yay <3

View on HN

Being able to disappear/discard history has significant downsides, too.

Regardless, you can rollback changes in subversion without bungling future merges.

> 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'.

> 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.

Reply on news.ycombinator.com