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

[Daniel J S. <dan...@ie...>]

On 02/14/2011 12:05 AM, Tait wrote:
>
>> 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.

Please explain index tool.  I can't recall what that is.


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

Thereby avoiding the "add to platform" step, correct me if I'm wrong.


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

Mobile phone free, and still going.  I always wonder if the mobile phone 
has made companies more efficient...oh wait, there's my phone, sorry, 
got to leave the meeting and take this in the hallway because it's way 
more important than you guys, I'm back, what were we talking about? oh 
yeah...or less efficient.


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

How or why?


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

I recall Mercurial being very solid, bug wise.  The same is probably 
true of git.  Source control programs seem to me to be a case where bugs 
have a lower tolerance level than bigger applications.  Admittedly, 
Mercurial isn't fast evolving, feature wise.


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

Your point about a project gnuplot's size is what my point was about 
branching.  Given the activity level of gnuplot, I don't see branching 
as being anything but more work.  However, the way you are describing 
things, it appears the philosophy of code development is to use some 
branch techniques even for linear development.


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

That's good, because we don't want to lose the history.  (In fact, 
someone should archive the revision history somewhere from time to time.)

Dan