Re: temporal snapshot of cvs source is prepared

[Mojca M. <moj...@gm...>]

On Sat, Feb 12, 2011 at 01:17, Daniel J Sebald wrote:
> On 02/11/2011 05:15 PM, Tait wrote:
>>>> If anyone wants, the downloads are also available here:
>>>>      https://github.com/gnuplot/gnuplot
>>>> (and complete history).
>>>
>>> Oh! It's nice.
>>
>> I'll second (third?) the recommendation that we switch away from CVS to
>> git. It's widely used across many open-source projects, it's resilient
>> against the kinds of outages that we're experiencing right now (each clone
>> represents the entire repository + history), and I personally prefer using
>> it. I don't think it matters much whether we move from SF to github or
>> anything else, but the time to move away from CVS is overdue.
>
> A couple years back I evaluated several source control programs.
> Mercurial is pretty nice.  Like git, it is a distributed source control
> program.  (All the changes travel with it when users upload the
> source...I'm thinking that maybe once a year it is a good idea to prune
> and archive the changes.)  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.

Git has gitk. I use GitX (http://gitx.frim.nl/, but only for mac)
which also allows interactive work with repository. But I agree, web
interfaces are suboptimal (apart from GitHub, but that one is
commercial).

> I found git to be good, but didn't like the platform concept.
> Things have to be moved into a platform and from there checked in.  It
> just seemed like extraneous keyboard typing.

How exactly do you mean that? (I'm not sure that I understood it properly.)

One thing that you need to do with GIT is:

a) git add <all the files that you want to be comitted> (you can use
"git add -A")
b) git commit
c) git push <to central repository>

In CVS/SVN that is a single command to do all the three operations at
once. The drawback of SVN is that you cannot change three files and
easily commit the changes just for one of them + just two out of three
changes done in the second file. On the other hand it is easier to
use.

(But I agree that GIT has a neverending learning curve. There are so
many useful features, but it takes ages to learn them to make your
life easier.)

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

Let me explain on a particular example.

When people submit patches to sourceforge (as .diff files):

- It means extra work when people want to try them out. They need to
check out a clean CVS tree, apply the patch (in the hope that it will
be easy to apply), recompile everything. Applying two patches at the
same time nees extra effort if both patches modify the same file (a
lot of manual work).

- It often happens that patches lie there for a long time before they
are incorporated. In the meantime a lot changes in gnuplot source, so
that it is not possible to just apply the patch any more. It needs to
be done manually after a while.

- I don't know the workflows, but from what I understood in recent
conversation, Ethan often has to prepare two patches - one for the
main branch and one for "4.4" branch (one that will remain in "trunk"
and one that will be used for the new release)

- If patches were simply separate branches, it would be easy to just
switch to a different branch & recompile gnuplot, to bring patches
up-to-date, less overhead when maintaining "master" branch and the one
approaching release + a few testing branches for new features.


But then again this needs to be the decision of those who commit to
gnuplot repository (and whose efficiency depends on those tools), not
of some random users of gnuplot (like me).

I had to set up my own (git) repository to be able to maintain my own
patches (for my own terminal) and keep gnuplot up-to-date at the same
time, with hardly any overhead. I couldn't do the same based on CVS so
easily. But that it just my personal "workflow". Developers of gnuplot
might have different experience and different needs and it is up to
them to decide what suits them best.

Mojca