On 03/25/2011 06:45 AM, Niels Möller wrote: > 1. 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).
> 2. 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.
> 3. 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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ nettle-bugs mailing list [email protected] http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
