Re: temporal snapshot of cvs source is prepared

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

On 02/12/2011 02:40 AM, Mojca Miklavec wrote:
> On Sat, Feb 12, 2011 at 01:17, Daniel J Sebald wrote:

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

Yes.  As you point out, there is a multiple step process.  The "add" 
part is the analogy to putting things on a platform, then comes the 
commit.  Mercurial does this in one step, if I recall correctly.  (BTW, 
for those unfamiliar, the "push" is what makes the source control 
program distributed.  I.e., all the commits occur locally on one's one 
repository until one pushes the changes across the network to someone 
else's repository.  One can continue to do commits without the remote 
network having to be active.)


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

There are still diff files in distributed source control programs. 
Can't save a whole repository for each bug fix and feature in SourceForge.


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

Yes, there is an advantage over CVS.  Git and Mercurial both.  What I 
meant is comparing git against Mercurial (I could have been clearer). 
I'm recalling something about git was better at branching than Mercurial 
is, more powerful.  What it was exactly I'm not sure.  (It had something 
to do with the internal data structure, better tracking or integrating 
across branches.)  But I think for the type of branching used in 
gnuplot, Mercurial might be fine.


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

It would take a while to figure out such a transition.  E.g., how to 
convert and store changes in the patch repositories, etc.  Looking at 
other projects that have used a distributed source control program would 
be a good plan.


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

Yes, I believe there are clear advantages over CVS.

Dan