Menu
▾
▴
gnuplot-beta
|
From: Tatsuro M. <tma...@ya...> - 2011-02-09 09:48:42
|
Hello The sourceforge cvs tree have been down more than two weeks. Shigeharu Takeno and I discussed this matter. We propose the distribution cvs source (2011-01-25) tar ball until the cvs server will come back for users' convenience. We can access the source tar all the below http://takeno.iee.niit.ac.jp/%7Eshige/unix/gnuplot/data/gnuplot-4.5.0-20110125.tar.gz Any comments and suggestions ? Regards Tatsuro -------------------------------------- Get the new Internet Explorer 8 optimized for Yahoo! JAPAN http://pr.mail.yahoo.co.jp/ie8/ |
|
From: Mojca M. <moj...@gm...> - 2011-02-09 10:07:06
|
On Wed, Feb 9, 2011 at 10:48, Tatsuro MATSUOKA wrote: > Hello > > The sourceforge cvs tree have been down more than two weeks. > Shigeharu Takeno and I discussed this matter. > We propose the distribution cvs source (2011-01-25) tar ball until the cvs server will come back for > users' convenience. > > We can access the source tar all the below > http://takeno.iee.niit.ac.jp/%7Eshige/unix/gnuplot/data/gnuplot-4.5.0-20110125.tar.gz > > Any comments and suggestions ? If anyone wants, the downloads are also available here: https://github.com/gnuplot/gnuplot (and complete history). I think that just clicking "Downloads" -> "Download .tar.gz" should get you the latest files, even though I'm not sure where the strange default name of downloaded file comes from (gnuplot-4-4-alpha-570-gcb5a396.tar.gz; the gcb5a396 are he first few characters from the sha hash, but "4-4-alpha" must come from some earlier tag ... 2009/05/31). I also have a complete backup of the CVS repository if that serves anyone ... Mojca |
|
From: Tatsuro M. <tma...@ya...> - 2011-02-09 21:58:36
|
Hello --- Mojca Miklavec <moj...@gm...> wrote: > On Wed, Feb 9, 2011 at 10:48, Tatsuro MATSUOKA wrote: > If anyone wants, the downloads are also available here: > https://github.com/gnuplot/gnuplot > (and complete history). Oh! It's nice. Thanks!! Tatsuro -------------------------------------- Get the new Internet Explorer 8 optimized for Yahoo! JAPAN http://pr.mail.yahoo.co.jp/ie8/ |
|
From: Tait <gnu...@t4...> - 2011-02-11 23:15:50
|
> > 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. |
|
From: Mojca M. <moj...@gm...> - 2011-02-12 08:40:51
|
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 |
|
From: Tait <gnu...@t4...> - 2011-02-14 06:05:52
|
> 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. 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). 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. Having a good tool means previously unimagined uses for it will begin to appear, once it's available and understood. Git and Mercurial both do well here. I don't think branching, per se, is what's magical. What git and projects built on top of git, like quilt, stgit, and so on, do well, is allow moving and merging of code with minimal effort. Here, CVS falls flat. 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. >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. > 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.) 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. |
|
From: Daniel J S. <dan...@ie...> - 2011-02-12 00:17:30
|
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. 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. Git is good at branching and such. But I don't think gnuplot development has the need for much branching. Dan |
|
From: Daniel J S. <dan...@ie...> - 2011-02-12 17:14:16
|
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 |
|
From: Mojca M. <moj...@gm...> - 2011-02-12 17:32:13
|
On Sat, Feb 12, 2011 at 18:13, Daniel J Sebald wrote:
>
>> 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.
There is no need to. I didn't talk about saving the whole repository.
But just as an example ... one could have one main repository and one
repository with patches where each patch would be in its own branch
(until it gets incorporated into main tree or deleted as useless).
People willing to play would just check out the branch with patch they
want to test without having to do anything else at all. Bringing
patches up-to-date and including them into main tree could be 99%
automatic (apart from cases when patches conflict). The other
alternative is to allow users to clone projects, apply the patches in
their personal repositories and submit patches as "pull requests".
But it all takes some expertise from the main developer.
> Looking at other projects
> that have used a distributed source control program would be a good plan.
Probably an extreme case:
https://github.com/mxcl/homebrew
Almost 1700 forks, 141 pull requests.
Mojca
|
|
From: Daniel J S. <dan...@ie...> - 2011-02-14 07:18:28
|
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 |
|
From: Tait <gnu...@t4...> - 2011-02-14 10:41:48
|
> > 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. Sorry, I should have been clearer. The index is what one manipulates with "git add". It's the "platform" that you described earlier. It is variously called the index, the cache (usually for options like git diff --cached), or the stage (but usually as a verb, "staged"). It all means the stuff that will become the next commit. > > 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. Correct. > Mobile phone free, and still going. I chose a poor analogy, then. The concept of branches in git is much the same as it was with CVS, but the practical usage is a world apart. In git, branching is easy and cheap. It is no effort at all to create a branch, delete it, move it in history (if there are no conflicts), merge it, or switch between branches. This makes branches a useful way to collect related sets of commits (changes). I make a new branch (locally on my computer) for every development idea I try. I can record my progress on these ideas as I go. When I'm done, it's easy to go back, clean, reorganize, and package it so someone else can make sense of the history. Or I can throw it away and nobody else knows what a horrible idea I had. Or I can carry forward my idea indefinitely, keeping it always up-to-date with the latest upstream changes (git calls this "rebase"). Nobody else benefits from the last scenario, but it makes maintaining my own private set of changes easy. With CVS, I would just accumulate more and more uncommitted changes, or I'd have to track my changes externally somehow. Either way, it's hard to revisit what I did, or keep it up to date with upstream changes. Easy branching is useful to developers even if the gnuplot project itself never actually creates a branch. And I think the project would want to create a few branches anyway. Developers can make their local changes in a different tool than the project uses (as I do currently with git and gnuplot's CVS, for example), but why force the use of two different tools? > > 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? I think I touched on this in the explanation of how the git project handles user contributions, but it comes down to tools for managing and incorporating contributions from other users, support for delegating tasks (like conflict resolution) to others, and minimizing the time involved in merging and creating releases. |
|
From: Mojca M. <moj...@gm...> - 2011-02-14 13:32:42
|
On Mon, Feb 14, 2011 at 08:18, Daniel J Sebald wrote: > On 02/14/2011 12:05 AM, Tait wrote: >> >> Importing history from CVS to either >> git or Mercurial is relatively pain-free. ... and already done. > 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.) With git (or mercurial) everyone who fetches the repository gets the whole history. So if someone deletes the repository on server, the copies will still be around at every developer. If somebody would delete CVS or SVN repository and if nobody had a backup, all the history would be lost. Neither git nor mercurial are capable of tracking timestamps of files and one cannot have $Version:$ headers expanded automatically though. Mojca |
|
From: Peter J. <pet...@gm...> - 2011-02-09 11:30:39
|
On Wed, Feb 9, 2011 at 10:48 AM, Tatsuro MATSUOKA <tma...@ya...> wrote: > Hello > > The sourceforge cvs tree have been down more than two weeks. [snip] > Any comments and suggestions ? > > Regards > > Tatsuro Now that the issue has been raised, I cannot help but wonder about the implications of this mishap on gnuplot's future. Sourceforge's admins have already expressed their intent of discontinuing their CVS service (see http://sourceforge.net/blog/sourceforge-attack-full-report/ ), meaning that gnuplot will have to migrate to SVN, git, or something else. Not that that would be a bad thing in itself, on the contrary, I'd consider any of the alternatives better than CVS. But in light of Sourceforge's response to this attack (and, well, according to some rumors, certain nefarious individuals were coming and going inside Sourceforge's system at will for quite some time now), we might want to think about ditching them altogether and move to a different service. Péter Juhász |
|
From: Hans-Bernhard B. <HBB...@t-...> - 2011-02-09 18:38:53
|
On 09.02.2011 12:30, Peter Juhasz wrote: > But in light of Sourceforge's response to this attack What exactly do you mean by that? If you have some concrete criticism, let's hear it. Otherwise I'm afraid I have to accuse you of spreading FUD. It's hard to see how SourceForge's reaction could have been any better. They've taken the issue as seriously as it gets, and they're drawing the _right_ consequences, in favour of the crowd-pleasing ones. Yes, that means things take time. But this clearly a case where it's better to be safe than quick. > we might want to think about ditching them altogether and move to a > different service. Pardon the French, but you're being silly. Whatever makes you think that other companies would fare any better than SF.net, under similar circumstances? |
