On 03/25/2011 06:45 AM, Niels Möller wrote:
- I'm familiar with mercurial, but I hear that git is a better choice these days, so maybe I should go with git instead. And then I have some new stuff to learn.
i find myself more effective with git than with mercurial, but i acknowledge that i have spent more time thinking about git (and many more other projects i collaborate on use git as well, so not spending time with it isn't much of an option for me).
- Currently, several more-or-less independent projects are in the lsh cvs tree. Besides nettle, there's libspki, argp, sftp. So how should this be split up? As far as I understand, neither hg nor git have any well-working analogue to cvs modules, which would otherwise have been a natural choice.
git does have submodule support -- so you can have one repository reference another at a given commit. I don't use it often, but i can help you sort it out if you like. "git help submodule" for some starter documentation/reference.
OTOH, if these separate pieces are actually different libraries, i'm not sure that using submodules really makes a lot of sense. I think you just want one git repository per project. Is there a reason that lsh would need to be tightly-coupled with any of these libraries instead of using their exported API?
One git repo per project is a pretty reasonable approach. And it's not hard to serve several git repos from a single server. If you want help setting that up, i'd be happy to help out.
- Then there's the shared files which are symlinked by the top-level lsh/.bootstrap script. I guess with a split it will be unavoidable to have multiple separately version controlled copies of those files.
i think you might be right here. For my git development, i took static copies of those files and placed them directly in my git repo (the commit log comment starts with "transfer files from lsh".
How often do these files actually change? Is it critical that they be kept in sync?
I guess it's possible to start with migrating nettle from cvs, and leave the rest of the tree for later. But I'm not sure that's a good way to do it.
I actually don't think that's an unreasonable approach. If we just migrate one component (nettle), we can make sure the migrated setup is OK and that your workflow feels sensible before going through the work of the other subprojects. We can apply any new knowledge learned from the nettle transition to the migration of the other subprojects.
Regards,
--dkg