Decide on naming of include folder

[donovanhide]

If this project is to become supported by package installation tools such as brew and apt in the future, the include path will conflict with that of the legacy project. What is a suitable alternative name?

[PhilipDeegan]

sparsehash11 ?

Keeping "sparsehash" could cause conflicts as you say, but changing it will force people to create sym links/modify include paths.

Bit of a toss up either way.

[david-grs]

It might be off topic, but why should this library be a fork? why not merge the changes to the main sparsehash? If everything is backward compatible - and that will be the case - I don't really see a reason to have 2 similar libraries.

On top of that, C++11 is old now, 14 is out and 17 will be here very soon. Naming it sparsehash11 sounds odd to me as it is already outdated before it's out :)

[donovanhide]

@david-grs sorry for the late reply...

I'd love to merge this code back into the other repo, but I live in fear of breaking anything that depends on apt/brew/yum packages derived from that repo. Maybe I'm being paranoid...

[PhilipDeegan]

@david-grs I think you're right, at least by now if someone's not using a C++11 compiler that's their own problem