Re: Just to show some appreciation for SVN
> 1) Monotonically increasing revision numbers
instead of constant handle that remains unchanged no matter which branches it is merged into? I'll take the latter. (Like one customer never wanted one feature, but one feature only that the other customer got, or one fix in this old release, and one fix only...)
and while I do appreciate the usefulness of revision-for-version-number, revision-as-quick-and-easy-identifier doesn't work too well for 4 or 5 digit revision count...
> 2) I don't have to check out EVERYTHING that ever was, just the current state (this saves time, I've seen some big repos and small files can add up!)
git clone --depth 1
> 3) Nothing is special, trunk/tags/branches are just directories like any other <---x2
no branch is special in git either, "master" is just a convention, "HEAD" is an implementation detail
> 4) svn:merge-info makes sense, merging follows like a simple "calculus of diffs"
funny you said that, because when I had to use svn, I usually used git to merge branches, unlike with svn, it was automatic in majority of cases...
not to mention working with patchsets, something basically impossible using svn only...
> 5) properties in general (like svn:ignore) but I imagine git has these (but I have seen a lot of .gitignore and stuff)
.gitignore and svn:ignore has exactly the same usage, I don't know what you mean as it not being there....
> 6) svn praise/blame (and some third one) - this is git bisect?
git blame does exactly the same thing svn blame does, svn-bisect is an external script...
> 7) svn:externals
> 8) svn revert
git reset --hard
> 2) There's an annoying merge-trunk-into-branch-after-reintegrating-that-branch-into-trunk (that is "record only" step to stop conflicts in the future when you try to merge the trunk in later
while in the git world, you can merge multiple branches that touch the same files at the same time so that you don't have merge conflicts caused by previous merge (git merge-octopus)