Re: SourceForge reorganization may affect gnuplot development site

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

On 10/04/2012 04:35 AM, Mojca Miklavec wrote:
> On Thu, Oct 4, 2012 at 10:29 AM, Daniel J Sebald wrote:
>>
>> I'm not sure the repositories themselves are being replaced, but the
>> other items are changing (e.g., bug tracker, etc.).  However, CVS seems
>> to be downplayed a bit and only SVN, mercurial and git are listed as
>> supported.  So, if when upgrading, gnuplot is forced to choose one of
>> those three, then it is essentially the same as replacing.  Not that
>> "upgrading" from CVS is bad.  (I've used mercurial pretty much and that
>> seems nice.)
>
> Probably not at this point, but I suspect that sooner or later CVS
> will be phased out and it might happen that it won't be supported in
> future at all. They wanted to completely drop support for CVS already,
> but maybe too many projects complained, so they left it. CVS does
> forget parts of history (when folder is deleted, file
> properties/executable bits etc. are lost) and I find it very difficult
> to navigate through changes.
>
> I have found a nice workaround (which works for me) - converting CVS
> to git and then working with git. And I don't seem to be the only one
> doing that. Once I got used to cherry-picking commits (that works
> amazing) and other sugars, it is difficult to think of going back.
> That feature would be extremely useful in particular for "backporting"
> bug fixes from trunk to branch-X-Y-stable.
>
> In my opinion switching to a different version control system will be
> necessary at one point, so it might be better to do it sooner rather
> than later. (I love git, but any other version control you mention
> above is better than CVS, and the decision/transition has to be made
> by those who are contributing most. It would only make me happy as the
> user if the upstream would use a different VCS.)

I would say that either git or mercurial would be a better choice than 
SVN.  git and mercurial are both "distributed" meaning that once a 
person has a local copy of the repository, the whole commit history is 
present (at least as far back as the project developers have chosen). 
These two make working with changesets amongst programmers much more fluent.

Right now, these advantages probably wouldn't be utilized because things 
are fairly stable.  But there has been a lot of discussion in the past 
regarding bigger projects like reorganizing the core code to make 
managing multiple plots a reality, as well as a number of other things.

I haven't used git much.  It seems nice, but I felt the "dock" or 
"platform" concept was extra work.  I think there are ways to bypass 
that, but mercurial seems fairly efficient.  The things I like about 
mercurial (and git probably has this too) is a built-in diff feature. 
It is so nice to just simply type:

hg diff

anywhere within the project's directory hierarchy and get a really quick 
record of the differences between the repository and the developing code.

hg update --clean

will remove any local changes and revert to the latest tip in the 
repository.

hg commit

will commit changes into the repository.  Then

hg export tip > somefile.patch

will create a diff file that includes the commit message.  (That might 
obviate the need for a ChangeLog file.  Developers would have to come up 
with a standard for creating commit messages.)  The "tip" means just the 
latest commit, but I believe multiple commits can be included in the 
export so several commits can be sent to others.

hg rollback

Will undo the most recent commit.  Just one.  git might do things better 
in the rollback area.

If there were something that could convert the CVS record to a git or 
mercurial record, that would be great.  If the change-log can't be 
incorporated that way, maybe one of the developers could write a C 
similar program that will properly incorporate the change-log 
entries...provided the repository is in some form of ASCII.

Dan