From: Hazen B. <hba...@ma...> - 2014-08-13 14:28:33
|
Sending this to a wider audience. In short, PLplot is now using git for version control. http://sourceforge.net/p/plplot/plplot/ci/master/tree/ -Hazen -------- Original Message -------- Subject: Re: [Plplot-core] git conversion status Date: Tue, 12 Aug 2014 16:24:27 -0400 From: Hazen Babcock <hba...@ma...> To: plp...@li... On 8/11/2014 6:47 PM, Hazen Babcock wrote: > > If there are no additional commits between today and tomorrow I'll clone > this to SF and change the SVN repo to read-only. All set now. Our SVN repository is (or should be) read-only under the "Old Code" tab. Our new git repository is available under the "Code" tab. Two initial suggestions: 1. Like github, SF is displaying the README.txt file. This appears to have last been modified in 2007. Maybe this should be the same as README.release? Or maybe it should be updated? 2. Clean up the repository by pruning off all the branches. Don't worry they'll still be there if you really want to look at them (as described here): http://stackoverflow.com/questions/3640764/can-i-recover-branch-after-the-deletion-in-git Many projects that I have seen only have a master branch in their release repository. -Hazen ------------------------------------------------------------------------------ _______________________________________________ Plplot-core mailing list Plp...@li... https://lists.sourceforge.net/lists/listinfo/plplot-core |
From: Alan W. I. <ir...@be...> - 2014-08-13 19:17:04
|
On 2014-08-13 10:28-0400 Hazen Babcock wrote: > > Sending this to a wider audience. In short, PLplot is now using git for > version control. > > http://sourceforge.net/p/plplot/plplot/ci/master/tree/ > > -Hazen > > -------- Original Message -------- > Subject: Re: [Plplot-core] git conversion status > Date: Tue, 12 Aug 2014 16:24:27 -0400 > From: Hazen Babcock <hba...@ma...> > To: plp...@li... > > On 8/11/2014 6:47 PM, Hazen Babcock wrote: >> >> If there are no additional commits between today and tomorrow I'll clone >> this to SF and change the SVN repo to read-only. > > All set now. Our SVN repository is (or should be) read-only under the > "Old Code" tab. Our new git repository is available under the "Code" tab. > > Two initial suggestions: > 1. Like github, SF is displaying the README.txt file. This appears to > have last been modified in 2007. Maybe this should be the same as > README.release? Or maybe it should be updated? > > 2. Clean up the repository by pruning off all the branches. Don't worry > they'll still be there if you really want to look at them (as described > here): > > http://stackoverflow.com/questions/3640764/can-i-recover-branch-after-the-deletion-in-git > > Many projects that I have seen only have a master branch in their > release repository. Many thanks, Hazen, for pushing this conversion project to completion. > [Suggestions] 2. Clean up the repository by pruning off all the branches. Don't worry > they'll still be there. >From my very recent first read of the Chapter on branching in "Pro Git" (<http://git-scm.com/book> and highly recommended), it appears git branches are extremely light-weight and simply point to a particular snapshot in the repository, and that chapter also confirms what you said about removing a branch does not remove the snapshot. > if you really want to look at them (as described > here): > > http://stackoverflow.com/questions/3640764/can-i-recover-branch-after-the-deletion-in-git That method does not seem fool-proof. See the expire subcommand for "git reflog". Furthermore, some of the PLplot branches are still active (e.g., test_cmake) and useful even though I will likely never want to merge that material to the master branch. So I would prefer branches not be deleted if they are active (test_cmake and perhaps others), and for the ones we decide to delete, I would like some permanent record of the branch that would allow us to reliably resurrect it again. My impression is you cannot delete tags. If that is true, could we make a specially named tag, e.g., branch_AM-LT for the tip of the currently existing AM-LT branch before deleting that branch? And then afterward be able to reliably resurrect the branch using that tag to access the last commit corresponding to the (old, deleted) branch head? And so on for the other branches we wish to delete? (Sorry that questions about policy for our git repo keep getting conflated with questions about git capabilities, but we are likely to be stuck with such conflation for quite a while until more of us become git experts.) Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: phil r. <phi...@ya...> - 2014-08-13 20:38:42
|
The impression I get from reading the docs and the post you linked Alan, is that there is a tendency for people coming from svn to forget that git is a distributed vcs. Perhaps some of these branches would be more at home in the various developers own repositories. I cloned the repository today and already generated two branches - partly to see how it works, but partly because it is so useful to be able to do so. That said, if for example you clone the repository now and continue to develop the cmake_test branch, but that branch gets deleted from the SF repository, does that make it really painful to merge it back in? I have a feeling the answer might be yes but I'm not sure. Maybe aim should be that any "live" branches should be merged into the master branch when possible (i.e. when the work in them is ready to merge back in), at which point they can be safely deleted. Then when they are needed in the future a developer creates their own local branches to do the same job. Of course these local repositories can be on github for collaborative purposes. To be honest it is so easy to create a branch that I have a feeling that you won't want a cmake_test branch, but instead you will create different branches for each test you do and then either discard them or merge them back in. I'm already thinking I will create a branch for working through removing exit() calls which I will regularly merge back in to my master and another branch for adding wxGCDC support which will itself branch to do specific smaller tasks then merge back to the wxGCDC branch, which will hopefully merge back into my master eventually. As far as dead branches are concerned - if they really are dead then there is presumably no reason to keep them, but I don't think it is useful to delete branches that we might want in the future. All that will happen is that instead of git holding a pointer to the branch head, one of us will end up with a text file containing the sha of the heads so we can find them again easily. Basically, I'm tending towards Alan's view of not deleting branches, but with the caveat that only if they have not been merged into master and they might be of some use at a later date. If they have been merged or they are of no use then they should be deleted. Of coarse none of these branches are mine, and I'm a newbie to git, so feel free to ignore me completely :-) Phil ________________________________ From: Alan W. Irwin <ir...@be...> To: Hazen Babcock <hba...@ma...> Cc: Plplot-devel mailing list <plp...@li...> Sent: Wednesday, 13 August 2014, 20:16 Subject: Re: [Plplot-devel] Fwd: Re: [Plplot-core] git conversion status On 2014-08-13 10:28-0400 Hazen Babcock wrote: > > Sending this to a wider audience. In short, PLplot is now using git for > version control. > > http://sourceforge.net/p/plplot/plplot/ci/master/tree/ > > -Hazen > > -------- Original Message -------- > Subject: Re: [Plplot-core] git conversion status > Date: Tue, 12 Aug 2014 16:24:27 -0400 > From: Hazen Babcock <hba...@ma...> > To: plp...@li... > > On 8/11/2014 6:47 PM, Hazen Babcock wrote: >> >> If there are no additional commits between today and tomorrow I'll clone >> this to SF and change the SVN repo to read-only. > > All set now. Our SVN repository is (or should be) read-only under the > "Old Code" tab. Our new git repository is available under the "Code" tab. > > Two initial suggestions: > 1. Like github, SF is displaying the README.txt file. This appears to > have last been modified in 2007. Maybe this should be the same as > README.release? Or maybe it should be updated? > > 2. Clean up the repository by pruning off all the branches. Don't worry > they'll still be there if you really want to look at them (as described > here): > > http://stackoverflow.com/questions/3640764/can-i-recover-branch-after-the-deletion-in-git > > Many projects that I have seen only have a master branch in their > release repository. Many thanks, Hazen, for pushing this conversion project to completion. > [Suggestions] 2. Clean up the repository by pruning off all the branches. Don't worry > they'll still be there. >>From my very recent first read of the Chapter on branching in "Pro Git" (<http://git-scm.com/book> and highly recommended), it appears git branches are extremely light-weight and simply point to a particular snapshot in the repository, and that chapter also confirms what you said about removing a branch does not remove the snapshot. > if you really want to look at them (as described > here): > > http://stackoverflow.com/questions/3640764/can-i-recover-branch-after-the-deletion-in-git That method does not seem fool-proof. See the expire subcommand for "git reflog". Furthermore, some of the PLplot branches are still active (e.g., test_cmake) and useful even though I will likely never want to merge that material to the master branch. So I would prefer branches not be deleted if they are active (test_cmake and perhaps others), and for the ones we decide to delete, I would like some permanent record of the branch that would allow us to reliably resurrect it again. My impression is you cannot delete tags. If that is true, could we make a specially named tag, e.g., branch_AM-LT for the tip of the currently existing AM-LT branch before deleting that branch? And then afterward be able to reliably resurrect the branch using that tag to access the last commit corresponding to the (old, deleted) branch head? And so on for the other branches we wish to delete? (Sorry that questions about policy for our git repo keep getting conflated with questions about git capabilities, but we are likely to be stuck with such conflation for quite a while until more of us become git experts.) Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ ------------------------------------------------------------------------------ _______________________________________________ Plplot-devel mailing list Plp...@li... https://lists.sourceforge.net/lists/listinfo/plplot-devel |
From: Hazen B. <hba...@ma...> - 2014-08-16 01:19:14
|
On 8/13/2014 4:38 PM, phil rosenberg wrote: > The impression I get from reading the docs and the post you linked Alan, is that there is a tendency for people coming from svn to forget that git is a distributed vcs. Perhaps some of these branches would be more at home in the various developers own repositories. I cloned the repository today and already generated two branches - partly to see how it works, but partly because it is so useful to be able to do so. Yes, I think we have agreed that the only branches in the SF repo should be "master", "next" and "release". All the other branches can live on cloned repos depending on user preference. If multiple people are going to work on them then they should be in a shared but "private" repo, not in the SF repo. > That said, if for example you clone the repository now and continue to develop the cmake_test branch, but that branch gets deleted from the SF repository, does that make it really painful to merge it back in? I have a feeling the answer might be yes but I'm not sure. The fact that it has been removed from theS F repo should not be an issue. I don't think this is really any different from a topic branch which never existed in the repo in the first place. -Hazen |
From: Alan W. I. <ir...@be...> - 2014-08-16 05:40:16
|
On 2014-08-15 21:19-0400 Hazen Babcock wrote: > On 8/13/2014 4:38 PM, phil rosenberg wrote: >> The impression I get from reading the docs and the post you linked Alan, is >> that there is a tendency for people coming from svn to forget that git is a >> distributed vcs. Perhaps some of these branches would be more at home in >> the various developers own repositories. I cloned the repository today and >> already generated two branches - partly to see how it works, but partly >> because it is so useful to be able to do so. > > Yes, I think we have agreed that the only branches in the SF repo should be > "master", "next" and "release". All the other branches can live on cloned > repos depending on user preference. If multiple people are going to work on > them then they should be in a shared but "private" repo, not in the SF repo. > >> That said, if for example you clone the repository now and continue to >> develop the cmake_test branch, but that branch gets deleted from the SF >> repository, does that make it really painful to merge it back in? I have a >> feeling the answer might be yes but I'm not sure. > > The fact that it has been removed from theS F repo should not be an issue. I > don't think this is really any different from a topic branch which never > existed in the repo in the first place. The above words made me double check that test_cmake has not been removed from the SF repo. I was very glad to see it (and the other weird branches) still there. Here is why. The test_cmake branch contains a lot of mundane test subprojects that test various aspects of CMake which are of little interest any more plus one interesting subproject called "test_ada" that should remain public since it tests all aspects of the CMake Ada language support facilities I developed as part of PLplot but which are of interest to others and which do need testing with "test_ada" fairly often and which require some maintenance on the rare occasions when that testing fails. Subversion branches could be used for absolutely any purpose, but in git with higher expectations of what branches mean, I think it makes no sense to keep this test_ada miniproject as part of a separate branch, and instead it should be located in a subdirectory of PLplot's cmake directory (similar to to the mini-project cmake/epa_build) in the master branch. So making that so and removing the test_cmake branch that contains test_ada is part of my future git plans. Furthermore, I would like some time to at least do a quick survey to make sure there are no other obvious "hidden gems" like test_ada located in what were subversion branches subdirectories before the corresponding branches are removed from the git repo. I do agree removal of all these weird (from the git point of view) branches is an excellent future goal so long as we have a fool-proof permanent way to resurrect those branches (even just for the purpose of understanding the early history of PLplot if someone becomes interested in that down the road). So is there such a method? For example, I asked before whether specially named tags (e.g., "historical_subversion_branch_test_cmake") constituted a permanent record that could be used as the basis of a fool-proof method of resurrecting all deleted subversion branches. However, that git question may have gotten lost in the shuffle because so far I haven't received a response. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Alan W. I. <ir...@be...> - 2014-08-16 18:03:39
|
On 2014-08-15 22:40-0700 Alan W. Irwin wrote: > I do agree removal of all these weird (from the git point of view) > branches is an excellent future goal so long as we have a fool-proof > permanent way to resurrect those branches (even just for the purpose > of understanding the early history of PLplot if someone becomes > interested in that down the road). > > So is there such a method? For example, I asked before whether > specially named tags (e.g., "historical_subversion_branch_test_cmake") > constituted a permanent record that could be used as the basis of a > fool-proof method of resurrecting all deleted subversion branches. It turns out the answer to that git question is tags are not a permanent record since they can be deleted (just had my first look at "git help tag" after reading the Pro Git explanation of tags too fast). So maybe a file documenting the deleted branches sufficiently to be able to resurrect them is the way to go? Ideas from the git gurus, please. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: phil r. <phi...@ya...> - 2014-08-16 23:29:44
|
Hi Alan I just had a play with this. So even if tags can be deleted, this is fine so long as nobody deletes them. So I just tested to find that deleting a branch does not delete the tags on that branch so the following sequence allows you to tag the head of a branch, delete the branch then restore that branch. git checkout -b deadend //make some changes to the deadend branch commit -a -m 'I made some changes' git tag -a deadendHead -m 'head of the branch I will delete' checkout master git branch -D deadend git tag //this shows a list of all tags, you should find deadendHead there despite having deleted deadend git show deadendHead //this will show, among other information the 40 character sha of the commit the tag points to //this can be used to check out this commit git checkout 0123456789abcde0123456789abcde01234567 //you get a handy message telling you how to reinstate this branch git checkout -b deadendResurrected git log //this shows you the commits proving that you are now in the resurrected branch that you previously deleted I hope you find that this is a suitable resurrection technique to allow you to go ahead with whatever clean up you feel is needed. Fundamentally I don't think there can ever be any foolproof method, but I think this comes as close as possible. By the way when listing all tags they are in alphabetical order so it would make sense to give all these head tags the same prefix so they are grouped together. Phil ________________________________ From: Alan W. Irwin <ir...@be...> To: Hazen Babcock <hba...@ma...> Cc: Plplot-devel mailing list <plp...@li...> Sent: Saturday, 16 August 2014, 19:03 Subject: Re: [Plplot-devel] Fwd: Re: [Plplot-core] git conversion status On 2014-08-15 22:40-0700 Alan W. Irwin wrote: > I do agree removal of all these weird (from the git point of view) > branches is an excellent future goal so long as we have a fool-proof > permanent way to resurrect those branches (even just for the purpose > of understanding the early history of PLplot if someone becomes > interested in that down the road). > > So is there such a method? For example, I asked before whether > specially named tags (e.g., "historical_subversion_branch_test_cmake") > constituted a permanent record that could be used as the basis of a > fool-proof method of resurrecting all deleted subversion branches. It turns out the answer to that git question is tags are not a permanent record since they can be deleted (just had my first look at "git help tag" after reading the Pro Git explanation of tags too fast). So maybe a file documenting the deleted branches sufficiently to be able to resurrect them is the way to go? Ideas from the git gurus, please. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ ------------------------------------------------------------------------------ _______________________________________________ Plplot-devel mailing list Plp...@li... https://lists.sourceforge.net/lists/listinfo/plplot-devel |
From: David M. <da...@as...> - 2014-08-17 17:45:37
|
Hi, Alan, On Aug 16, 2014, at 11:03 AM, Alan W. Irwin wrote: > Ideas from the git gurus, please. I think the ongoing concern/discussion of deleting branches in git might be due to a lingering svn mindset vis a vis branching. I could be wrong, but I think deleting a branch in subversion also deletes the entire set of commits that lived on that branch. This is not the case at all in git. In git, "commits" are first class objects in their own right, whereas "branches" are just pointers (aka references) to commits. If someone deletes a branch locally, the commit pointed to by the branch (before it was deleted) still exists in the git repository (as do all of its ancestral commits as well). Pushing the deletion of a branch so that the branch is also deleted in the remote repository is possible but not something that can be done by mistake; you really have to actively/explicitly delete the remote branch, but again the commits themselves are not deleted. The reflog tracks the local history of where references point in the local repository. This information is inherently local. Why would anyone but me care where my HEAD reference pointed at various points in my workflow? More importantly, if reflog info were not local, how would the histories of "HEAD" for multiple developers be reconciled? What would it mean to anyone anyway? When I was starting with git (from a CVS/SVN background), the thing that really helped me to understand git was reading about the four types of objects that git stores (blobs, trees, commits, and tags). Section 9.2 of the Pro Git book covers this material (though I think I first read about it elsewhere): http://git-scm.com/book/en/Git-Internals-Git-Objects It's also important to note that tags in git come in two types: lightweight tags and heavyweight tags. Both kinds of tags "point" to a specific commit, but lightweight tags are just references (like branches) whereas heavyweight tags are first class objects (like commits). For tagging releases, I far prefer heavyweight tags because they include extra metadata that a lightweight tag cannot (e.g. who created the tag, when it was created, optional message about the tag, optional signing of the tag). Hope this helps, Dave P.S. Another thing I really like about git is "gitk" which can be used to visualize and explore a git repo's history. Try that with subversion! :-) |
From: Hazen B. <hba...@ma...> - 2014-08-17 02:37:16
|
On 8/13/2014 3:16 PM, Alan W. Irwin wrote: > On 2014-08-13 10:28-0400 Hazen Babcock wrote: > > > That method does not seem fool-proof. See the expire subcommand for "git > reflog". Furthermore, some of the PLplot branches are still active > (e.g., test_cmake) and useful even though I will likely never want to > merge that material to the master branch. I've looked at this a little more and I'm not sure that I fully understand the concern. You are worried that someone will run "git reflog expire" on the master SF repo? It is not clear that to me that this is even possible. This link would suggest not: http://stackoverflow.com/questions/17857723/whats-the-difference-between-git-reflog-and-log "git reflog doesn't traverse HEAD's ancestry at all. The reflog is an ordered list of the commits that HEAD has pointed to: it's undo history for your repo. The reflog isn't part of the repo itself (it's stored separately to the commits themselves) and isn't included in pushes, fetches or clones; it's purely local." -Hazen |
From: Alan W. I. <ir...@be...> - 2014-08-17 06:41:51
|
On 2014-08-16 22:37-0400 Hazen Babcock wrote: > On 8/13/2014 3:16 PM, Alan W. Irwin wrote: >> On 2014-08-13 10:28-0400 Hazen Babcock wrote: >> >> >> That method does not seem fool-proof. See the expire subcommand for "git >> reflog". Furthermore, some of the PLplot branches are still active >> (e.g., test_cmake) and useful even though I will likely never want to >> merge that material to the master branch. > > I've looked at this a little more and I'm not sure that I fully understand > the concern. You are worried that someone will run "git reflog expire" on the > master SF repo? It is not clear that to me that this is even possible. This > link would suggest not: > > http://stackoverflow.com/questions/17857723/whats-the-difference-between-git-reflog-and-log > > "git reflog doesn't traverse HEAD's ancestry at all. The reflog is an ordered > list of the commits that HEAD has pointed to: it's undo history for your > repo. The reflog isn't part of the repo itself (it's stored separately to the > commits themselves) and isn't included in pushes, fetches or clones; it's > purely local." Hi Hazen: Thanks for looking further at reflog, but local doesn't sound like what I want since that would be a single point of failure (e.g., if I am keeping this information on my local disk repo, that disk could fail), and nobody could access that information other than me. Of course, you could choose that location as the SF repo, but then only certain privileged users can access that information via ssh and appropriate git commands. Also SF staff aperiodically change repo formats (as they did in the Allura conversion), and for such a mass conversion they might not even bother to keep the reflog info. Remember, my basic motivation is to allow access to our history by anybody that is interested in the future. Therefore, I far prefer to store the information in a file in the repo since that file is available to everyone, automatically backed up by everyone cloning it, and even in the unlikely event someone deletes that file in error you can still restore it from finding the parent of the associated commit in the log that deleted that file. (For git newbies here, see <http://stackoverflow.com/questions/953481/restore-a-deleted-file-in-a-git-repo>.) To make this file proposal concrete, I am suggesting storing the file in PLplot_repo_information/README_svn2git_conversion (a directory and name that are unlikely to be deleted by accident by anyone) that states the commands we used to do the conversion and test it (the contents of the AWIREADME file I sent you plus additional documentation of the subversion branches that were converted to git and then deleted with explicit instructions on how to resurrect each one of them). I think we should also store in that directory the 4 files we used for the conversion, i.e., the two files used with svn-all-fast-export, the convert tags bash script that was sourced, and my standalone bash script to test the results in that directory. Do you see git (or any other) issues with these ideas? If you forsee no obvious problems, then I will put this near the top of my git ToDo list to get rid of the historical subversion-style branches, and put resurrecting test_cmake and copying the test_ada subdirectory of that to a better location later in my ToDo list. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Hazen B. <hba...@ma...> - 2014-08-17 11:56:20
|
On 8/17/2014 2:41 AM, Alan W. Irwin wrote: > On 2014-08-16 22:37-0400 Hazen Babcock wrote: >> >> "git reflog doesn't traverse HEAD's ancestry at all. The reflog is an >> ordered list of the commits that HEAD has pointed to: it's undo >> history for your repo. The reflog isn't part of the repo itself (it's >> stored separately to the commits themselves) and isn't included in >> pushes, fetches or clones; it's purely local." > > Thanks for looking further at reflog, but local doesn't sound like what > I want > since that would be a single point of failure (e.g., if I am keeping > this information on my local disk repo, that disk could fail), and > nobody could access that information other than me. Now I'm confused, I thought you were against deleting branches in the SF repo because you were worried that some variant of the git reflog command would cause them to disappear forever from any and all records in the SF repo? I was responding specifically to your statement: "That method does not seem fool-proof. See the expire subcommand for "git reflog"." If you agree that git reflog is local then perhaps you could what other sequence of commands might lead to such a permanent loss of history? Or maybe you meant that once the branch is gone you might not be able to figure out from the log which SHA corresponded to the head of that particular branch? I agree that this could be difficult. Anyway I'm Ok with your proposed solution, see below. > Remember, my basic motivation is to allow access to our history by > anybody that is interested in the future. Therefore, I far prefer to > store the information in a file in the repo since that file is > available to everyone, automatically backed up by everyone cloning it, > and even in the unlikely event someone deletes that file in error you > can still restore it from finding the parent of the associated commit > in the log that deleted that file. (For git newbies here, see > <http://stackoverflow.com/questions/953481/restore-a-deleted-file-in-a-git-repo>.) > > > To make this file proposal concrete, I am suggesting storing the file > in PLplot_repo_information/README_svn2git_conversion (a directory and > name that are unlikely to be deleted by accident by anyone) that > states the commands we used to do the conversion and test it (the > contents of the AWIREADME file I sent you plus additional > documentation of the subversion branches that were converted to git > and then deleted with explicit instructions on how to resurrect each > one of them). I think we should also store in that directory the 4 > files we used for the conversion, i.e., the two files used with > svn-all-fast-export, the convert tags bash script that was sourced, > and my standalone bash script to test the results in that directory. > Do you see git (or any other) issues with these ideas? This is fine with me. Perhaps the directory should be called something like "historical" and "vcs_conversions", and you could include what was done for the CVS to SVN conversion as well? This would also get things ready our conversion to the next great thing in version control system in 5-10 years :). -Hazen |
From: Alan W. I. <ir...@be...> - 2014-08-25 01:30:28
|
On 2014-08-17 07:56-0400 Hazen Babcock wrote: > On 8/17/2014 2:41 AM, Alan W. Irwin wrote: >> To make this file proposal concrete, I am suggesting storing the file >> in PLplot_repo_information/README_svn2git_conversion (a directory and >> name that are unlikely to be deleted by accident by anyone) that >> states the commands we used to do the conversion and test it (the >> contents of the AWIREADME file I sent you plus additional >> documentation of the subversion branches that were converted to git >> and then deleted with explicit instructions on how to resurrect each >> one of them). I think we should also store in that directory the 4 >> files we used for the conversion, i.e., the two files used with >> svn-all-fast-export, the convert tags bash script that was sourced, >> and my standalone bash script to test the results in that directory. >> Do you see git (or any other) issues with these ideas? > > This is fine with me. Perhaps the directory should be called something like > "historical" and "vcs_conversions", and you could include what was done for > the CVS to SVN conversion as well? DONE. See 6c81eb2. The files are called historical_repository_conversions/README_cvs2svn_conversion historical_repository_conversions/README_svn2git_conversion historical_repository_conversions/authors.txt historical_repository_conversions/diff_git_versus_svn_tree.sh historical_repository_conversions/plplot.rules historical_repository_conversions/svn_tag2git_tag.sh In response to your request, the first one contains the overview of the cvs2svn conversion as gleaned from relevant plplot-devel posts in 2007. Once you do the branch removal we discussed, you should append a corresponding section to that second file describing what you did and how branches can be resurrected if needed. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: phil r. <phi...@ya...> - 2014-08-17 12:52:09
|
Hi Hazen and Alan Did you see the email I sent last night saying you can tag a branch head, then if the branch is deleted the tag remains? This makes it trivial to delete branches but make sure they can be restored providing nobody deletes the tag - and even if they did you could probably search the log to find where and when and find the sha of the tag, especially if we start all tags with "deletedBranch" or something. one view might be that this just clutters our tag space instead of branch space, but putting a file of shas in the project just clutters our file space. To me it is all equivalent in one sense, but I do se that there is a niceness associated with having clean branch space. Phil ________________________________ From: Hazen Babcock <hba...@ma...> To: Alan W. Irwin <ir...@be...> Cc: Plplot-devel mailing list <plp...@li...> Sent: Sunday, 17 August 2014, 12:56 Subject: Re: [Plplot-devel] Fwd: Re: [Plplot-core] git conversion status On 8/17/2014 2:41 AM, Alan W. Irwin wrote: > On 2014-08-16 22:37-0400 Hazen Babcock wrote: >> >> "git reflog doesn't traverse HEAD's ancestry at all. The reflog is an >> ordered list of the commits that HEAD has pointed to: it's undo >> history for your repo. The reflog isn't part of the repo itself (it's >> stored separately to the commits themselves) and isn't included in >> pushes, fetches or clones; it's purely local." > > Thanks for looking further at reflog, but local doesn't sound like what > I want > since that would be a single point of failure (e.g., if I am keeping > this information on my local disk repo, that disk could fail), and > nobody could access that information other than me. Now I'm confused, I thought you were against deleting branches in the SF repo because you were worried that some variant of the git reflog command would cause them to disappear forever from any and all records in the SF repo? I was responding specifically to your statement: "That method does not seem fool-proof. See the expire subcommand for "git reflog"." If you agree that git reflog is local then perhaps you could what other sequence of commands might lead to such a permanent loss of history? Or maybe you meant that once the branch is gone you might not be able to figure out from the log which SHA corresponded to the head of that particular branch? I agree that this could be difficult. Anyway I'm Ok with your proposed solution, see below. > Remember, my basic motivation is to allow access to our history by > anybody that is interested in the future. Therefore, I far prefer to > store the information in a file in the repo since that file is > available to everyone, automatically backed up by everyone cloning it, > and even in the unlikely event someone deletes that file in error you > can still restore it from finding the parent of the associated commit > in the log that deleted that file. (For git newbies here, see > <http://stackoverflow.com/questions/953481/restore-a-deleted-file-in-a-git-repo>.) > > > To make this file proposal concrete, I am suggesting storing the file > in PLplot_repo_information/README_svn2git_conversion (a directory and > name that are unlikely to be deleted by accident by anyone) that > states the commands we used to do the conversion and test it (the > contents of the AWIREADME file I sent you plus additional > documentation of the subversion branches that were converted to git > and then deleted with explicit instructions on how to resurrect each > one of them). I think we should also store in that directory the 4 > files we used for the conversion, i.e., the two files used with > svn-all-fast-export, the convert tags bash script that was sourced, > and my standalone bash script to test the results in that directory. > Do you see git (or any other) issues with these ideas? This is fine with me. Perhaps the directory should be called something like "historical" and "vcs_conversions", and you could include what was done for the CVS to SVN conversion as well? This would also get things ready our conversion to the next great thing in version control system in 5-10 years :). -Hazen ------------------------------------------------------------------------------ _______________________________________________ Plplot-devel mailing list Plp...@li... https://lists.sourceforge.net/lists/listinfo/plplot-devel |
From: Alan W. I. <ir...@be...> - 2014-08-17 18:12:47
|
On 2014-08-17 05:52-0700 phil rosenberg wrote: > Hi Hazen and Alan > Did you see the email I sent last night saying you can tag a branch head, then if the branch is deleted the tag remains? > This makes it trivial to delete branches but make sure they can be restored providing nobody deletes the tag - and even if they did you could probably search the log to find where and when and find the sha of the tag, especially if we start all tags with "deletedBranch" or something. I had proposed that same idea earlier, got cold feet because tags can be deleted, but then got the point you just made about deletion causes a log change that can be identified. So using tags this way would be OK, but I now prefer the file method to store the SHA ids required to resurrect a branch. After all, we are already going to store a file that documents all the things that were done for the conversion, and this branch deletion (with the possibility of resurrection) is just a continuation of that conversion process. By the way, Phil, I really appreciate your participation in these discussions and your obvious willingness to quickly get up to speed on git. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Alan W. I. <ir...@be...> - 2014-08-17 18:00:55
|
On 2014-08-17 07:56-0400 Hazen Babcock wrote: > On 8/17/2014 2:41 AM, Alan W. Irwin wrote: >> On 2014-08-16 22:37-0400 Hazen Babcock wrote: >>> >>> "git reflog doesn't traverse HEAD's ancestry at all. The reflog is an >>> ordered list of the commits that HEAD has pointed to: it's undo >>> history for your repo. The reflog isn't part of the repo itself (it's >>> stored separately to the commits themselves) and isn't included in >>> pushes, fetches or clones; it's purely local." >> >> Thanks for looking further at reflog, but local doesn't sound like what >> I want >> since that would be a single point of failure (e.g., if I am keeping >> this information on my local disk repo, that disk could fail), and >> nobody could access that information other than me. > > Now I'm confused, I thought you were against deleting branches in the SF repo > because you were worried that some variant of the git reflog command would > cause them to disappear forever from any and all records in the SF repo? I > was responding specifically to your statement: > > "That method does not seem fool-proof. See the expire subcommand for "git > reflog"." My understanding (which might have been wrong) when you first wrote about this and referred to the relevant stackoverflow discussion) is reflog contains (along with a lot of other information) SHA id's corresponding to branch heads and therefore could be used to resurrect deleted branches. But that is no good if reflog is expired (e.g., the default 90-day expiration that is used to keep all that information managable). Because that expiration would essential remove the needed SHA id information from the reflog. But regardless of whether I was confused or not on that subject, the local nature of the reflog makes this idea not practicable for the reasons I have mentioned so I prefer storing those essential SHA id's for deleted branch heads in a file instead. > > If you agree that git reflog is local then perhaps you could what other > sequence of commands might lead to such a permanent loss of history? Or maybe > you meant that once the branch is gone you might not be able to figure out > from the log which SHA corresponded to the head of that particular branch? Exactly the latter. > I > agree that this could be difficult. Anyway I'm Ok with your proposed > solution, see below. > >> Remember, my basic motivation is to allow access to our history by >> anybody that is interested in the future. Therefore, I far prefer to >> store the information in a file in the repo since that file is >> available to everyone, automatically backed up by everyone cloning it, >> and even in the unlikely event someone deletes that file in error you >> can still restore it from finding the parent of the associated commit >> in the log that deleted that file. (For git newbies here, see >> <http://stackoverflow.com/questions/953481/restore-a-deleted-file-in-a-git-repo>.) >> >> >> To make this file proposal concrete, I am suggesting storing the file >> in PLplot_repo_information/README_svn2git_conversion (a directory and >> name that are unlikely to be deleted by accident by anyone) that >> states the commands we used to do the conversion and test it (the >> contents of the AWIREADME file I sent you plus additional >> documentation of the subversion branches that were converted to git >> and then deleted with explicit instructions on how to resurrect each >> one of them). I think we should also store in that directory the 4 >> files we used for the conversion, i.e., the two files used with >> svn-all-fast-export, the convert tags bash script that was sourced, >> and my standalone bash script to test the results in that directory. >> Do you see git (or any other) issues with these ideas? > > This is fine with me. Good. > Perhaps the directory should be called something like > "historical" and "vcs_conversions", and you could include what was done for > the CVS to SVN conversion as well? Good ideas. I don't remember any of the CVS to SVN conversion except the pain, but I could go through the e-mail list conversations at the time to resurrect a description of what was done. > This would also get things ready our > conversion to the next great thing in version control system in 5-10 years > :). You are a cruel guy even to bring up that possibility, but I forgive you! :-) Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Alan W. I. <ir...@be...> - 2014-08-22 00:48:45
|
On 2014-08-17 11:00-0700 Alan W. Irwin wrote: >>> To make this file proposal concrete, I am suggesting storing the file >>> in PLplot_repo_information/README_svn2git_conversion (a directory and >>> name that are unlikely to be deleted by accident by anyone) that >>> states the commands we used to do the conversion and test it (the >>> contents of the AWIREADME file I sent you plus additional >>> documentation of the subversion branches that were converted to git >>> and then deleted with explicit instructions on how to resurrect each >>> one of them). I think we should also store in that directory the 4 >>> files we used for the conversion, i.e., the two files used with >>> svn-all-fast-export, the convert tags bash script that was sourced, >>> and my standalone bash script to test the results in that directory. >>> Do you see git (or any other) issues with these ideas? >> >> This is fine with me. > > Good. Hi Hazen: So we were all in agreement that storage (in a file) of the SHA1 id of the HEAD commits from each branch to be deleted would be enough to guarantee branch resurrection, but it turns out that is incorrect. Further reading shows that git automatically garbage collects (deletes) all "unreachable" commits after a suitable default period (usually 90 days, I think). So there are lots of warnings in the results for google searching for the terms <git resurrect branch> that the techniques only work for a while until garbage collection occurs. However, I found <http://stackoverflow.com/questions/1055877/will-a-commit-be-garbage-collected-if-its-refered-to-by-tag-but-not-by-branch> which indicated the part of the git-gc manual which notes "git gc tries very hard to be safe about the garbage it collects. In particular, it will keep not only objects referenced by your current set of branches and tags..." It is good that tags don't get garbage collected, because we have that situation (tag with no branch) for all our release tags. That is git branch --contains v5_10_0 produces no results which means the important commit (corresponding to the plplot-5.10.0 release) pointed to by that tag is not on a branch. So the variation on what was agreed to above to allow anyone to resurrect the historical svn branches that we want to delete is the branch HEAD's should all be tagged (so the garbage collection git monsters don't eat those commits alive) with a tag name something like svn_historical_branch_<branch_name>, then the branch deleted. Note I have already copied (because I had no interest in the history), added, committed and pushed the test_ada subdirectory that was the only part of those historical branches that I am currently aware of that has important use going forward. But if someone else wants to copy something from these historical branches, then branch resurrection should be available to them indefinitely without worrying about garbage collection. So as far as I am concerned, you can proceed with the above process. I could do it locally, but I am not sure how to propagate the deleted branches and corresponding new tags to the official repo. Also, once the official repo is updated that way, how are those deleted branches and new tags propagated to everyone else? Will the next "git fetch" or "git pull" do that automatically? Once you have completed the above process, and the resulting deleted branches and new tags are propagated (see the question above) to my local repo, then I would be willing to write up the resurrection process (and list all the relevant svn_historical_branch_... tags) in the file documenting our conversion from svn to git. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Hazen B. <hba...@ma...> - 2014-08-22 13:45:48
|
On 8/21/2014 8:48 PM, Alan W. Irwin wrote: > So we were all in agreement that storage (in a file) of the SHA1 id of > the HEAD commits from each branch to be deleted would be enough to > guarantee branch resurrection, but it turns out that is incorrect. > Further reading shows that git automatically garbage collects > (deletes) all "unreachable" commits after a suitable default period > (usually 90 days, I think). So there are lots of warnings in the > results for google searching for the terms <git resurrect branch> that > the techniques only work for a while until garbage collection occurs. Hm, that is my take on this as well. I agree that if we want to preserve the branches then we'll need to tag them. Buried in the comments to the first answer to this question is an explanation of how to push the tags to the remote repository: http://stackoverflow.com/questions/2342821/git-branch-deletion If you are really worried about history preservation then you should also implement a server side hook to prevent tag deletion. -Hazen |
From: Alan W. I. <ir...@be...> - 2014-08-23 00:47:47
|
On 2014-08-22 09:45-0400 Hazen Babcock wrote: > On 8/21/2014 8:48 PM, Alan W. Irwin wrote: >> So we were all in agreement that storage (in a file) of the SHA1 id of >> the HEAD commits from each branch to be deleted would be enough to >> guarantee branch resurrection, but it turns out that is incorrect. >> Further reading shows that git automatically garbage collects >> (deletes) all "unreachable" commits after a suitable default period >> (usually 90 days, I think). So there are lots of warnings in the >> results for google searching for the terms <git resurrect branch> that >> the techniques only work for a while until garbage collection occurs. > > Hm, that is my take on this as well. I agree that if we want to preserve the > branches then we'll need to tag them. Buried in the comments to the first > answer to this question is an explanation of how to push the tags to the > remote repository: > > http://stackoverflow.com/questions/2342821/git-branch-deletion Thank goodness for stackoverflow. What a great response that deals with essentially all questions we have had about this issue. > > If you are really worried about history preservation then you should also > implement a server side hook to prevent tag deletion. I think it is an excellent idea to do everything we can to preserve our development history. Accordingly, I have now modified the update hook appropriately and put it under git control (see latest push of ffada3a). I have tested that logic with a "play" bare server repo and a local working directory repo that uses the bare one as a remote. For that case, git push --tags works for propagating new local tags to the official repo (consistent with the stackoverflow answer). And it nicely errors out if you attempt to reuse an old tag for a different commit. i.e., git tag -f <oldtagname> <newcommit ID> git push --tags However, "git push --tags" completely ignores locally deleted tags (one of a number of arcane things about git that are difficult to understand). In order to attempt to propagate tag deletes to the server you need to run instead the alternative syntax git push --delete origin <tagname> The current update hook obligingly errors out in that case as well. So all seems well with its logic, but by all means try it yourself for your own play repos. I have just now propagated this new version to the correct part of the SF repo using the following two commands. ssh airwin,pl...@sh... create (wait for a few minutes until it responds with the message that your shell access is ready to go [for the next 4 hours]). software@raven> scp \ /home/software/plplot_svn/HEAD/plplot.git/git_hooks/update \ airwin,pl...@sh...:/home/git/p/plplot/plplot.git/hooks If anything screws up with that update logic, i.e., any of us are getting error messages from attempting to make a legit push that include no invalid tag deletes, tag reuses, or merge commits, then one of us will need to adjust the logic in git_hooks/update, push it so others can see the change that has been made, and do the equivalent two commands above to deploy/activate it. If you have time, and now that I have made it impossible for tags to be deleted/reused for our SF repo, then I would appreciate you following up by taking responsibility for the safe branch deletion of all the svn-generated branches other than master. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Hazen B. <hba...@ma...> - 2014-08-25 01:59:38
|
On 8/24/2014 9:30 PM, Alan W. Irwin wrote: > On 2014-08-17 07:56-0400 Hazen Babcock wrote: >> >> This is fine with me. Perhaps the directory should be called something >> like "historical" and "vcs_conversions", and you could include what >> was done for the CVS to SVN conversion as well? > > DONE. See 6c81eb2. > > The files are called > > historical_repository_conversions/README_cvs2svn_conversion > historical_repository_conversions/README_svn2git_conversion > historical_repository_conversions/authors.txt > historical_repository_conversions/diff_git_versus_svn_tree.sh > historical_repository_conversions/plplot.rules > historical_repository_conversions/svn_tag2git_tag.sh > > In response to your request, the first one contains the overview of the > cvs2svn conversion > as gleaned from relevant plplot-devel posts in 2007. Thank you. > Once you do the branch removal we discussed, you should append a > corresponding section to that second file describing what you did and > how branches can be resurrected if needed. Ok. I hope to have some time for this in the coming week. -Hazen |
From: Alan W. I. <ir...@be...> - 2014-08-25 19:54:27
|
On 2014-08-13 10:28-0400 Hazen Babcock wrote: > 1. Like github, SF is displaying the README.txt file. This appears to > have last been modified in 2007. Maybe this should be the same as > README.release? Or maybe it should be updated? Thanks for this suggestion. I ultimately decided to update the README file based on the content of our website. But when re-reading our website content in preparation for that change I found some areas of www/index.php, www/downloads.php, etc., that needed reorganizing and rewording. So this has turned into a substantially larger effort than I originally estimated, but I hope to finish the update of the website content and corresponding README file later today. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Alan W. I. <ir...@be...> - 2014-08-28 15:24:15
|
On 2014-08-25 12:54-0700 Alan W. Irwin wrote: > On 2014-08-13 10:28-0400 Hazen Babcock wrote: > >> 1. Like github, SF is displaying the README.txt file. This appears to >> have last been modified in 2007. Maybe this should be the same as >> README.release? Or maybe it should be updated? > > Thanks for this suggestion. I ultimately decided to update the README > file based on the content of our website. But when re-reading our > website content in preparation for that change I found some areas of > www/index.php, www/downloads.php, etc., that needed reorganizing and > rewording. So this has turned into a substantially larger effort than > I originally estimated, but I hope to finish the update of the website > content and corresponding README file later today. Hi Hazen: My README and website changes have been pushed as of d5b1568, and the corresponding changes to the website have been uploaded. Please take a critical look at README and http://plplot.sourceforge.net and http://plplot.sourceforge.net/downloads.php (where most of the website changes occurred) in case you spot any additional changes that should be done. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Hazen B. <hba...@ma...> - 2014-08-28 16:44:33
|
On 8/28/2014 11:24 AM, Alan W. Irwin wrote: > On 2014-08-25 12:54-0700 Alan W. Irwin wrote: > >> On 2014-08-13 10:28-0400 Hazen Babcock wrote: >> >>> 1. Like github, SF is displaying the README.txt file. This appears to >>> have last been modified in 2007. Maybe this should be the same as >>> README.release? Or maybe it should be updated? >> >> Thanks for this suggestion. I ultimately decided to update the README >> file based on the content of our website. But when re-reading our >> website content in preparation for that change I found some areas of >> www/index.php, www/downloads.php, etc., that needed reorganizing and >> rewording. So this has turned into a substantially larger effort than >> I originally estimated, but I hope to finish the update of the website >> content and corresponding README file later today. > > My README and website changes have been pushed as of d5b1568, and the > corresponding changes to the website have been uploaded. Please take > a critical look at README and http://plplot.sourceforge.net and > http://plplot.sourceforge.net/downloads.php (where most of the website > changes occurred) in case you spot any additional changes that should > be done. Overall it looks good to me. In the README file, should I be able to click on the links when viewed here? http://sourceforge.net/p/plplot/plplot/ci/master/tree/ -Hazen |
From: Alan W. I. <ir...@be...> - 2014-08-28 17:46:11
|
On 2014-08-28 12:44-0400 Hazen Babcock wrote: > On 8/28/2014 11:24 AM, Alan W. Irwin wrote: >> My README and website changes have been pushed as of d5b1568, and the >> corresponding changes to the website have been uploaded. Please take >> a critical look at README and http://plplot.sourceforge.net and >> http://plplot.sourceforge.net/downloads.php (where most of the website >> changes occurred) in case you spot any additional changes that should >> be done. > > Overall it looks good to me. Thanks for that review. > In the README file, should I be able to click on the links when viewed here? > http://sourceforge.net/p/plplot/plplot/ci/master/tree/ I don't think that is possible with plain text (which we want this file to be for the case when this README file is included, say, in a tarball). According to <http://sourceforge.net/p/forge/documentation/Files-Readme/> raw html is simply escaped for plain text files. Of course, the angle-bracketed style I am using in this README for URL's is not html, but the implication of the SF documentation or readme files is there is not much you can do to make links clickable for plain text files. I also looked at http://sourceforge.net/p/plplot/plplot/ci/master/tree/doc/docbook/ There the URL's in the README file in that directory are not angle-bracketed, but those links are still not clickable indicating my angle brackets in the README file in the top-level directory are not interfering with clickability. Until I looked at that last case (where that directory also includes a file called README.developers which was updated more recently than README in that directory) I was concerned about an implication in the above SF documentation that the latest updated README.* file would be the one displayed. Clearly, from the doc/docbook/README case that rule does not apply to files called exactly "README" so the next time we update one of README.developers, README.release, or README.Release_managers_cookbook in the top-level directory, the README file in that directory should still be displayed at <http://sourceforge.net/p/plplot/plplot/ci/master/tree/> (which is the result we want). Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: David M. <da...@as...> - 2014-08-28 18:42:34
|
Hi, Alan, On Aug 28, 2014, at 10:46 AM, Alan W. Irwin wrote: > On 2014-08-28 12:44-0400 Hazen Babcock wrote: > >> In the README file, should I be able to click on the links when viewed here? >> http://sourceforge.net/p/plplot/plplot/ci/master/tree/ > > I don't think that is possible with plain text (which we want this > file to be for the case when this README file is included, say, in a > tarball). FWIW, Markdown is a very nearly plain text file format that is often used for README files (e.g. on github). I see in the link you provided that sourceforge supports Markdown, but only for README files with a markdown-like extension. If you would like the URLs in the README files to be links on the sourceforge repository browsing page (an possibly other places?), then it sounds like you could rename them to README.md (and README.developers.md etc). This might necessitate some reformatting if some previous plain text formatting gets mis-interpreted as unwanted markdown formatting. The Markdown syntax is very non-intrusive to a human reader. To humans, markdown files read very much like well formatted plain text files so they are well suited for inclusion in tarballs. Dave |
From: Alan W. I. <ir...@be...> - 2014-08-28 19:35:51
|
On 2014-08-28 11:42-0700 David MacMahon wrote: > Hi, Alan, > > On Aug 28, 2014, at 10:46 AM, Alan W. Irwin wrote: > >> On 2014-08-28 12:44-0400 Hazen Babcock wrote: >> >>> In the README file, should I be able to click on the links when viewed here? >>> http://sourceforge.net/p/plplot/plplot/ci/master/tree/ >> >> I don't think that is possible with plain text (which we want this >> file to be for the case when this README file is included, say, in a >> tarball). > > FWIW, Markdown is a very nearly plain text file format that is often used for README files (e.g. on github). I see in the link you provided that sourceforge supports Markdown, but only for README files with a markdown-like extension. If you would like the URLs in the README files to be links on the sourceforge repository browsing page (an possibly other places?), then it sounds like you could rename them to README.md (and README.developers.md etc). This might necessitate some reformatting if some previous plain text formatting gets mis-interpreted as unwanted markdown formatting. > > The Markdown syntax is very non-intrusive to a human reader. To humans, markdown files read very much like well formatted plain text files so they are well suited for inclusion in tarballs. > Hi Dave: Thanks for reminding me of markdown which I must have encountered before because I certainly like the angle bracket syntax for URL's. I think it would be a good idea to convert our README files to markdown syntax whenever the opportunity/time was available. Actually, I have already unknowingly started doing that by using the angle-bracket syntax for URL's in the top-level README. But obviously that is not enough since the links are not clickable despite the statement at <http://sourceforge.net/p/forge/documentation/markdown_syntax/> that "SourceForge uses markdown syntax everywhere to allow you to create rich text markup [....]" According to http://sourceforge.net/p/forge/documentation/Files-Readme/ it may be that all I would have to do was change the README name to README.md to make the SF software translate that file from markdown to html, but then according to that same documention we would not be in a good situation because any other file in the same directory with readme or README somewhere in the name would take precedence if updated later than README.md. That precedence issue is not much of a concern for the file release area where you typically upload some README file after uploading the tarball. But for the git browsing area precedence would be a concern for a number of our source code directories. Anyhow, the Allura software that runs SourceForge may not have rules in place to deal with the file precedence issue for the git browsing case, or there may be special rules in that case (such as the one I just discovered where README has precedence over all other name forms). For now I think it is a good idea to encourage markdown syntax in README files, but I suggest we leave the filename as is and hope SF figures out they should apply the markdown transformation in the case where README files have markdown syntax or else figures out the precedence issue if the markdown format can be recognized by Allura only if there is a special filename suffix such as ".md". Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |