Migrating away from CVS? was: [temporal snapshot of cvs source is prepared]

[Tait <gnu...@t4...>]

> Mercurial is pretty nice...  Mercurial was a little more straightforward
> than git; not so bulky, easy to start doing basic things.  Mercurial has
> a way of creating a local html server if one wants to view the change
> history.

Mercurial is nice, and I've used it, too. The learning curve of Mercurial
is lower, and it certainly appeals to those who don't like/use the
index. I find the index to be an invaluable tool. For those wanting
to mostly pretend it doesn't exist, git has options like git commit -a
(which can be aliased using your shell, or git itself).

If you want a zero-configuration web server, there's git instaweb.
  http://www.kernel.org/pub/software/scm/git/docs/git-instaweb.html

Or as was mentioned by someone else, gitk or git log --graph (along
with options like --oneline to format as one wishes) can offer a visual
representation of history.

> Git is good at branching and such. But I don't think gnuplot development
> has the need for much branching.

I used to think nobody needs a mobile phone, but today I would be
hard-pressed to live without it. Having a good tool means previously
unimagined uses for it will begin to appear, once it's available and
understood. Git and Mercurial both do well here. I don't think branching,
per se, is what's magical. What git and projects built on top of git,
like quilt, stgit, and so on, do well, is allow moving and merging of
code with minimal effort. Here, CVS falls flat.

Where git does shine a little brighter than Mercurial is in the maintainer
role. Whoever is accepting patches (from SourceForge, mailing list, ...)
and committing them will have an easier time in that role with git.

>From my perhaps biased view, git seems to have more momentum in the
open-source community than Mercurial. There are more developers working on
git and more projects using git, which means it's easier to find support,
less likelihood of bugs or missing features, and a faster response when
there are (bugs or missing features). The mailing list is high-traffic,
but between that and the IRC channel (#git on freenode), you can get any
question answered, perhaps several times over.

> When people submit patches to sourceforge...

If we used git, I would look to the git project itself as a model of how
to accept and manage user contributions. Patches are created based on
master (the main branch, or trunk as it would be known in CVS/SVN), then
submitted  -- mostly via the mailing list -- and applied straight from the
email to the maintainer's repository (the "git am" command does this),
in a topic-specific branch. If it looks interesting, it may be merged
into a branch called "pu", which is basically a collection area for rough
ideas being developed. After suggestions, cleanup, and modifications, the
topic-specific branch or pu gets merged into a branch called "next". Next
is a long-lived branch that represents things expected to appear in the
next release. If everything goes well for this change on next, then it
will be merged into master when creating the next release.

There is another branch, "maint", used for regressions and bug
fixes. Before a new release is made, master is merged back to maint.

This may sound complicated, but there are probably only three branches
for a project gnuplot's size: next, master, and maint. Changes are made
to next and graduated to master. Fixes are ported forward to master and
next from maint. (Or whatever names you want to give each branch.)

Like Mojca, I'm just a gnuplot user. If I could find more time, I might
contribute to development. I hope some of the information I've offered
can be helpful to the developers. The SourceForge blog said, "We are
also considering the end-of-life of the CVS service and hope to have user
support in migrating CVS users..." Importing history from CVS to either
git or Mercurial is relatively pain-free.