On 03/26/2011 03:46 AM, Niels Möller wrote:
The main reason is that lsh is the main testcase. So when introducing new features one of those those libraries, I usually first hack lsh to use it, to iron out both interface and implementation bugs. Those intermediate versions may never be in the API of any released library.
git submodules (assuming that they work well) would probably be the right tool to keep these libraries in subdirectories of the lsh work tree.
Yeah, you can definitely do that with git submodules. I'd be happy to help you iron out kinks in that workflow if you like.
Ah, and then it's the release procedure. I'd still like to bundle the libraries with lsh, and having the libraries in subdirectories makes that easier. And as long as the versions bundled with nettle are configured for static linking, I see no problem of bundling lsh with unreleased versions of the libraries.
hm, are you talking about making binary releases? or source releases?
If we do that, I guess we'd need the following steps:
- migrate the nettle cvs directory to a git repository.
this is already done, if you don't mind using my git repo as the base:
git://lair.fifthhorseman.net/~dkg/nettle
You can just clone it and then publish it yourself :)
if you want to do the repository conversion yourself, i understand that too -- i'm just trying to help.
To do it yourself, you want to use git cvsimport (from the git-cvs package in debian).
cvs rm all those files from the cvs tree (as usual, we can't cvs rm the directories themselves).
At some later time, migrate the lsh cvs repository to git. Should the old nettle subdirectory be excluded somehow? Perhaps not, if I want to be able to check out old lsh versions from git.
i don't think you'll need to exclude the old nettle subdirectory from any future lsh cvs->git migration, especially if the directory has been removed from the HEAD already.
hth,
--dkg