Menu
▾
▴
gnuplot-beta
|
From: Ethan A M. <sf...@us...> - 2012-10-03 22:03:31
|
SourceForge is "upgrading" (in other words replacing) its current project
source code repositories, mailing lists, bug trackers, etc.
It is utterly unclear to me how much this will affect maintenance
or use of the gnuplot project pages, but I guess we will find out.
More information:
https://sourceforge.net/p/upgrade/
If nothing else, apparently the URL to access the project pages
will change.
Ethan
|
|
From: Allin C. <cot...@wf...> - 2012-10-03 23:08:20
|
On Wed, 3 Oct 2012, Ethan A Merritt wrote: > SourceForge is "upgrading" (in other words replacing) its current project > source code repositories, mailing lists, bug trackers, etc. > > It is utterly unclear to me how much this will affect maintenance > or use of the gnuplot project pages, but I guess we will find out. > > More information: > https://sourceforge.net/p/upgrade/ > > If nothing else, apparently the URL to access the project pages > will change. Hmm, if I go to that "upgrade" page I see text that appears to make the upgrade optional, per project. Is that misleading? Are we really bound to upgrade regardless? Allin Cottrell |
|
From: Ethan A M. <sf...@us...> - 2012-10-03 23:38:00
|
On Wednesday, October 03, 2012 03:45:15 pm Allin Cottrell wrote: > On Wed, 3 Oct 2012, Ethan A Merritt wrote: > > > SourceForge is "upgrading" (in other words replacing) its current project > > source code repositories, mailing lists, bug trackers, etc. > > > > It is utterly unclear to me how much this will affect maintenance > > or use of the gnuplot project pages, but I guess we will find out. > > Hmm, if I go to that "upgrade" page I see text that appears to make > the upgrade optional, per project. Is that misleading? Are we really > bound to upgrade regardless? From their Email to me: Early next year, we hope to be 100% migrated off of the classic platform. [...] We'd like for you to have the opportunity to upgrade on your own schedule, rather than ours. You can read about the upgrade process at https://sourceforge.net/p/upgrade/ and then press the 'Upgrade' button next to your project name. To me that sounds like 'any time you like so long as it is in the next 3 months'. Ethan |
|
From: Daniel J S. <dan...@ie...> - 2012-10-04 08:30:08
|
On 10/03/2012 05:03 PM, Ethan A Merritt wrote: > SourceForge is "upgrading" (in other words replacing) its current project > source code repositories, mailing lists, bug trackers, etc. > > It is utterly unclear to me how much this will affect maintenance > or use of the gnuplot project pages, but I guess we will find out. > > More information: > https://sourceforge.net/p/upgrade/ > > If nothing else, apparently the URL to access the project pages > will change. 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.) The example project (Allura itself) doesn't seem too much different from the existing SourceForge, if perhaps less feature rich. The color coded diffs viewing isn't much to speak of. One has to use the horizontal slide bar quite a bit and then the colored line backgrounds only extend as far as the original window, so that isn't much use if the different parts are out to the right side of the window. gnuplot isn't likely to use the discussion forum, I assume. What this paste bin is, I have no idea. It looks like hunks of code pasted there without username association or description. The one sort of new thing (or perhaps it is simply something I hadn't noticed with the existing SourceForge) is every 5th or 6th page navigation a Flash advert comes up. I'd say wait a while and see if Allure is improved and what the future is for CVS support. Dan |
|
From: Mojca M. <moj...@gm...> - 2012-10-04 09:35:40
|
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.) Mojca |
|
From: Daniel J S. <dan...@ie...> - 2012-10-05 02:53:55
|
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 |
|
From: Allin C. <cot...@wf...> - 2012-10-05 03:15:25
|
On Thu, 4 Oct 2012, Daniel J Sebald wrote: > 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. [...] > > I would say that either git or mercurial would be a better choice than > SVN. No doubt opinions will differ on this. Svn is closest to CVS, and therefore easiest to learn for people who are used to CVS, while offering various advantages over the latter. Git is very full-featured and is the VC system used by many leading open-source projects (notably the Linux kernel and the GNU C library) and therefore may be worth learning even though it's not close to CVS. For me personally, mercurial would be the last choice, simply because up to this point no software that I'm interested in resides in a mercurial repository. Allin Cottrell |
|
From: Daniel J S. <dan...@ie...> - 2012-10-05 05:17:07
|
On 10/04/2012 10:15 PM, Allin Cottrell wrote: > On Thu, 4 Oct 2012, Daniel J Sebald wrote: > >> 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. [...] >> >> I would say that either git or mercurial would be a better choice than >> SVN. > > No doubt opinions will differ on this. Svn is closest to CVS, and > therefore easiest to learn for people who are used to CVS, while > offering various advantages over the latter. Git is very > full-featured and is the VC system used by many leading open-source > projects (notably the Linux kernel and the GNU C library) and > therefore may be worth learning even though it's not close to CVS. > > For me personally, mercurial would be the last choice, simply > because up to this point no software that I'm interested in resides > in a mercurial repository. Another thing to consider is the HTML-based interface for the repository. That can often be helpful for browsing the latest developments, patches that might have introduced a bug, etc. Also, if I want to describe something to someone who may not be energized enough to clone the repository I'll give a link to the HTML file. Here's an example of mercurial's interface: http://hg.savannah.gnu.org/hgweb/octave which I believe is part of the mercurial software, i.e., just set up an address for the repository and it will automatically generate the page in a browser. The one category in the menu list I'd like to point out is the "graph", something that git doesn't appear to have (or I'm not aware of). Here's an example of a git repository HTMl interface: http://sourceware.org/git/?p=glibc.git;a=summary The graph shows the branch history for the project, e.g., where they bifurcate, where they combine. This is something that can be really useful on a bigger project. (Does gnuplot need such a thing? Not sure.) It's not the best graph tool I've seen, as it is line/page-based, but one gets used to it. The best graph and diff utilities I've seen are for a commercial product called Perforce. It's graph is graphical based where one can zoom in on the graph, scroll a position bar, click on a node and it takes a person to that commit. Perforce's diff utility will display the before and after file side-by-side with color coded adds and deletes. It's really nice. git/mercurial seem a tie in this category tipping toward mercurial for its graph printout, which could be better. Dan |
|
From: Tait <gnu...@t4...> - 2012-10-05 07:14:24
|
>>> 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. >> >> 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. [...] > > I would say that either git or mercurial would be a better choice than > SVN. (Disclosure: I like git; I find mercurial gets underfoot and is clumsy. But nothing is worse than CVS.) SVN has one distinct advantage over both git and mercurial: it is the lowest-common denominator. Both Mercurial and Git have excellent utilities that allow the end user to use git/mercurial to interact with an SVN server. Those who don't want to learn or be forced into a newer VCS like git or mercurial can use SVN itself. SVN becomes the best of all worlds. It retains familiarity for CVS users, and git/mercurial fans can use whichever they prefer and have most or all of the benefits of their tool of choice. Someone mentioned Perforce. This is a commercial product whose licenses are not free. I don't think we -- or SourceForge -- will adopt it. The feedback I've heard on it has mostly been negative. Bazar would be worth consideration, but it's not one of the choices listed by SourceForge. |
