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

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:

1. 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).

2. cvs rm all those files from the cvs tree (as usual, we can't cvs rm the directories themselves).

3. 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

On 03/28/2011 03:17 AM, Niels Möller wrote:

Daniel Kahn Gillmor dkg@fifthhorseman.net writes:

...

hm, are you talking about making binary releases? or source releases?

I'm talking about the source releases of lsh.

I'm a software developer, a sysadmin, and a contributor to a distro (debian). No matter which of those three hats i'm wearing, i *strongly* prefer to have source releases broken out into separable components, rather than one monolithic tarball. I prefer this for system maintenance, for security, for clarity of API, and for ease of modification.

I'm not sure what the argument for monolithic source release is.

--dkg

Daniel Kahn Gillmor dkg@fifthhorseman.net writes:

To do it yourself, you want to use git cvsimport (from the git-cvs package in debian).

I think I'd prefer to do the conversion myself. I've had a first look at the man page for git-cvsimport.

I take it I first need to scan the cvs log for all comitters and write a cvs-authors file (I remember I had some trouble with character set issues for the corresponding file when doing the hg migration for gmp. Should the names here be in the $LC_CTYPE charset, or always utf8?).

Then, I'm not sure how to deal with branches, in particular, the -r and -o options. I'm not used to git, and with hg I also haven't used any "real" branches, I've just cloned the repository. I'm a bit scared by "You should never do any work of your own on the branches that are created by git cvsimport." in the man page.

I think I'd like to keep the possibility of doing cvs import more than once.

What command line did you use? What branches did you end up with?

Regards, /Niels

Daniel Kahn Gillmor dkg@fifthhorseman.net writes:

On 03/28/2011 04:15 AM, Niels Möller wrote:

...

I think I'd like to keep the possibility of doing cvs import more than once.

Meaning you want to update the cvs tree concurrently with the git repo?

Not in the longer term, but maybe during a transition period. But I guess it's not essential.

I ran something like this:

cvs -d :pserver:anonymous@cvs.lysator.liu.se:/cvsroot/lsh \ co -d nettle lsh/nettle cd nettle git cvsimport

It all ended up on the "origin" branch then? (I'm still not familiar with git conventions).

I ended up with no extra branches, though. Just a handful of tags. What sort of branches do you want to end up with?

There are a few branches, in the lsh tree I think there's lsh_1_2_BRANCH, lsh_1_4_2_BRANCH, lsh_2_0_4_BRANCH, experimental_BRANCH_20050201. I branched and tagged the complete tree at the time, but appearantly that was before the move from lsh/src/nettle to lsh/nettle, so there are no tags in the current nettle subdirectory.

Regards, /Niels

On 03/28/2011 09:07 AM, Niels Möller wrote:

Maybe it makes things simpler to stick to a single repository for everything (like the current cvs repository)? Is there any compelling reason why nettle must be a separate repository? (If I understand the docs correctly, one could split off a nettle repository later, using git-subtree split).

I'd personally like to work on nettle without dealing with the entire source of lsh and the other components.

I suspect the same might be true of people who want to hack on the other components, or on lsh itself.

If you want to encourage external participation, separate repositories make more sense to me.

How do other folks on this list feel about the tradeoffs here?

--dkg