From: Hazen B. <hba...@ma...> - 2014-01-30 21:36:00
|
Hello, I know this has come up before. However, I've been using git alot at work and I feel that it has many advantages over SVN and I think we should again consider switching over (after the next release of course). To get an idea of the power of git I would suggest reading the first 3 chapters of this (online) book: http://git-scm.com/book And I was even inspired enough to create a git clone of the PLplot project which is available here: https://github.com/HazenBabcock/PLplot The conversion was performed using svn2git as described here: https://github.com/nirvdrum/svn2git While I did run into some issues (and bugs in conversion program) along the way, I believe that it is "complete and accurate", and includes all the branches and version tags. If we do make this switch, I'd also suggest moving the project to Github, but that is another discussion. best, -Hazen |
From: Alan W. I. <ir...@be...> - 2014-01-30 22:51:57
|
On 2014-01-30 16:35-0500 Hazen Babcock wrote: > Hello, > > I know this has come up before. However, I've been using git alot at > work and I feel that it has many advantages over SVN and I think we > should again consider switching over (after the next release of course). > To get an idea of the power of git I would suggest reading the first 3 > chapters of this (online) book: > http://git-scm.com/book > > And I was even inspired enough to create a git clone of the PLplot > project which is available here: > https://github.com/HazenBabcock/PLplot > > The conversion was performed using svn2git as described here: > https://github.com/nirvdrum/svn2git > > While I did run into some issues (and bugs in conversion program) along > the way, I believe that it is "complete and accurate", and includes all > the branches and version tags. Hi Hazen: Can you confirm you have been able to preserve all our svn history (which includes our cvs history) in that git repository back to revision 1? If so, that would be a very promising sign concerning the quality of the svn2git conversion tool (or workarounds you used for its conversion bugs). I am more welcoming towards the idea of converting PLplot to a git repository than previously. Thanks to many git recommendations like yours, I do plan to start learning how to use git in the near future. My one collaborator for the timeephemeris project (much less complicated than PLplot) also prefers git, and because of his needs and because I thought it was time to learn git I plan to switch that project from svn to git in the next month or so and will presumably learn git rather fast after that. So let's see how that goes, but assuming that conversion and my practical use of git after that is a success, then I would be willing to go along with a switch to git later this year if our other PLplot core developers are willing to do that as well. I have just reviewed the subset of the svn commands that I ordinarily use with PLplot and other projects. Those are add cat checkout (co) commit (ci) copy (cp) delete (del, remove, rm) diff (di) export help (?, h) log move (mv, rename, ren) propdel (pdel, pd) propedit (pedit, pe) propget (pget, pg) proplist (plist, pl) propset (pset, ps) revert status (stat, st) update (up) You don't have to do this to convince me since I am going to be learning git regardless later this year, but it might help your case with those developers here who are not familiar yet with git and are wondering how painful using git is going to be to create a short summary of how a developer would go about normal PLplot development in a git world. I further suggest you keep that summary as simple as possible (just giving the minimal git commands that do the equivalent of the above svn commands) because one of the intimidating factors for git is the large command set with large numbers of options. That complexity makes git very powerful indeed, but also makes it difficult/intimidating to learn. 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-01-31 16:45:59
|
On 1/30/2014 5:51 PM, Alan W. Irwin wrote: > On 2014-01-30 16:35-0500 Hazen Babcock wrote: > >> Hello, >> >> I know this has come up before. However, I've been using git alot at >> work and I feel that it has many advantages over SVN and I think we >> should again consider switching over (after the next release of course). >> To get an idea of the power of git I would suggest reading the first 3 >> chapters of this (online) book: >> http://git-scm.com/book >> >> And I was even inspired enough to create a git clone of the PLplot >> project which is available here: >> https://github.com/HazenBabcock/PLplot >> >> The conversion was performed using svn2git as described here: >> https://github.com/nirvdrum/svn2git >> >> While I did run into some issues (and bugs in conversion program) along >> the way, I believe that it is "complete and accurate", and includes all >> the branches and version tags. > > Hi Hazen: > > Can you confirm you have been able to preserve all our svn history > (which includes our cvs history) in that git repository back to > revision 1? If so, that would be a very promising sign concerning the > quality of the svn2git conversion tool (or workarounds you used > for its conversion bugs). > > I am more welcoming towards the idea of converting PLplot to a git > repository than previously. Thanks to many git recommendations like > yours, I do plan to start learning how to use git in the near future. > My one collaborator for the timeephemeris project (much less > complicated than PLplot) also prefers git, and because of his needs > and because I thought it was time to learn git I plan to switch that > project from svn to git in the next month or so and will presumably > learn git rather fast after that. So let's see how that goes, but > assuming that conversion and my practical use of git after that is a > success, then I would be willing to go along with a switch to git > later this year if our other PLplot core developers are willing to do > that as well. > > I have just reviewed the subset of the svn commands that I ordinarily > use with PLplot > and other projects. > > Those are > add > cat > checkout (co) > commit (ci) > copy (cp) > delete (del, remove, rm) > diff (di) > export > help (?, h) > log > move (mv, rename, ren) > propdel (pdel, pd) > propedit (pedit, pe) > propget (pget, pg) > proplist (plist, pl) > propset (pset, ps) > revert > status (stat, st) > update (up) > > You don't have to do this to convince me since I am going to be > learning git regardless later this year, but it might help your case > with those developers here who are not familiar yet with git and are > wondering how painful using git is going to be to create a short > summary of how a developer would go about normal PLplot development in > a git world. I further suggest you keep that summary as simple as > possible (just giving the minimal git commands that do the equivalent > of the above svn commands) because one of the intimidating factors for > git is the large command set with large numbers of options. That > complexity makes git very powerful indeed, but also makes it > difficult/intimidating to learn. Hi Alan, Regarding the conversion: 1. The first ever commit? $git log | tail Author: furnish <fu...@us...> Date: Wed May 20 21:36:02 1992 +0000 Initial checkin of the whole PLPLOT project. commit 60a5c3966d86eef16dbf391dc40647fa3fcedb30 Author: no_author <no_...@us...> Date: Wed May 20 21:36:02 1992 +0000 New repository initialized by cvs2svn. 2. Alan's first commit? $git log | grep airwin -A 5 | tail [snip] Author: airwin <ai...@us...> Date: Wed May 10 21:24:06 2000 +0000 Alan W. Irwin. Logic for changing power of 10 to scale z axes is now consistent between the left and right z axes. 3. Hazen's first commit? $git log | grep hbabcock -A 5 | tail [snip] Author: hbabcock <hba...@us...> Date: Sun Feb 6 18:25:25 2005 +0000 Added AquaTerm driver As an aside, since a git repository is always local this is fast operation. Anyway, it looks like history is all there? I provide some (untested) examples of how one might use git below, but I think that the git book really does a great job of explaining things, and it doesn't actually take that long to read the first 3 chapters :). 1. Basic (SVN like) work: git clone https://github.com/HazenBabcock/PLplot.git .. work on file1.x .. git add file1.x git commit -m file1.x .. work on file2.x .. .. what did I change anyway? .. git status git add file2.x git commit -m file2.x .. that was a mistake .. git reset HEAD~1 .. make correction .. git add file2.x git commit -m file2.x git push origin master (all the work is local until the changes are pushed back to the remote repository by git push) 2. Work on a branch: .. dev1 .. git branch -b epa_build .. work on epa_build .. add .. commit .. .. push epa_build to a remote repository so that other can evaluate .. git push origin epa_build .. dev2 .. git fetch git checkout epa_build .. tests & agrees that epa_build works well .. .. dev1 .. .. merge epa_build into master .. git checkout master git merge epa_build git push origin master .. delete the epa_build branch if it is no longer needed .. git branch -d epa_build 3. Work with someone who is not a PLplot developer (this is where I think git really has an advantage): .. non-dev .. git clone dev-repo git branch -b go_bindings .. work on go_bindings .. git push non-dev-repo go_bindings .. dev1 .. git remote add non-dev-repo git fetch non-dev-repo git checkout go_bindings .. see what has been changed in go_bindings compared to master .. git diff go_bindings..master .. makes some changes, suggests others .. git push dev-repo go_bindings .. non-dev .. git fetch dev-repo git checkout go_bindings git merge dev-repo/go_bindings .. implements changes .. git push non-dev-repo go_bindings .. dev1 .. git fetch non-dev-repo git checkout go_bindings git merge non-dev-repo/go_bindings .. likes go_bindings .. git checkout master git merge go_bindings git push origin master Where non-dev-repo is a publicly available repository. Note that git makes it much easier for someone who is not a core developer to contribute and it makes it much easier to evaluate the contributions as you don't have to keep swapping and applying patch files and/or both have write access to the same repo. It appears that git does not have a properties feature like SVN, so I don't think there is anything like the SVN prop commands. -Hazen |
From: Alan W. I. <ir...@be...> - 2014-01-31 20:58:17
|
On 2014-01-31 11:45-0500 Hazen Babcock wrote: > On 1/30/2014 5:51 PM, Alan W. Irwin wrote: >> On 2014-01-30 16:35-0500 Hazen Babcock wrote: >> >>> Hello, >>> >>> I know this has come up before. However, I've been using git alot at >>> work and I feel that it has many advantages over SVN and I think we >>> should again consider switching over (after the next release of course). >>> To get an idea of the power of git I would suggest reading the first 3 >>> chapters of this (online) book: >>> http://git-scm.com/book >>> >>> And I was even inspired enough to create a git clone of the PLplot >>> project which is available here: >>> https://github.com/HazenBabcock/PLplot >>> >>> The conversion was performed using svn2git as described here: >>> https://github.com/nirvdrum/svn2git >>> >>> While I did run into some issues (and bugs in conversion program) along >>> the way, I believe that it is "complete and accurate", and includes all >>> the branches and version tags. >> >> Hi Hazen: >> >> Can you confirm you have been able to preserve all our svn history >> (which includes our cvs history) in that git repository back to >> revision 1? If so, that would be a very promising sign concerning the >> quality of the svn2git conversion tool (or workarounds you used >> for its conversion bugs). >> >> I am more welcoming towards the idea of converting PLplot to a git >> repository than previously. Thanks to many git recommendations like >> yours, I do plan to start learning how to use git in the near future. >> My one collaborator for the timeephemeris project (much less >> complicated than PLplot) also prefers git, and because of his needs >> and because I thought it was time to learn git I plan to switch that >> project from svn to git in the next month or so and will presumably >> learn git rather fast after that. So let's see how that goes, but >> assuming that conversion and my practical use of git after that is a >> success, then I would be willing to go along with a switch to git >> later this year if our other PLplot core developers are willing to do >> that as well. >> >> I have just reviewed the subset of the svn commands that I ordinarily >> use with PLplot >> and other projects. >> >> Those are >> add >> cat >> checkout (co) >> commit (ci) >> copy (cp) >> delete (del, remove, rm) >> diff (di) >> export >> help (?, h) >> log >> move (mv, rename, ren) >> propdel (pdel, pd) >> propedit (pedit, pe) >> propget (pget, pg) >> proplist (plist, pl) >> propset (pset, ps) >> revert >> status (stat, st) >> update (up) >> >> You don't have to do this to convince me since I am going to be >> learning git regardless later this year, but it might help your case >> with those developers here who are not familiar yet with git and are >> wondering how painful using git is going to be to create a short >> summary of how a developer would go about normal PLplot development in >> a git world. I further suggest you keep that summary as simple as >> possible (just giving the minimal git commands that do the equivalent >> of the above svn commands) because one of the intimidating factors for >> git is the large command set with large numbers of options. That >> complexity makes git very powerful indeed, but also makes it >> difficult/intimidating to learn. > > Hi Alan, > > Regarding the conversion: > 1. The first ever commit? > $git log | tail > Author: furnish <fu...@us...> > Date: Wed May 20 21:36:02 1992 +0000 > > Initial checkin of the whole PLPLOT project. > > commit 60a5c3966d86eef16dbf391dc40647fa3fcedb30 > Author: no_author <no_...@us...> > Date: Wed May 20 21:36:02 1992 +0000 > > New repository initialized by cvs2svn. > > 2. Alan's first commit? > $git log | grep airwin -A 5 | tail > [snip] > Author: airwin <ai...@us...> > Date: Wed May 10 21:24:06 2000 +0000 > > Alan W. Irwin. Logic for changing power of 10 to scale z axes is now > consistent between the left and right z axes. > > 3. Hazen's first commit? > $git log | grep hbabcock -A 5 | tail > [snip] > Author: hbabcock <hba...@us...> > Date: Sun Feb 6 18:25:25 2005 +0000 > > Added AquaTerm driver > > As an aside, since a git repository is always local this is fast operation. > Anyway, it looks like history is all there? That's a convincing demo! :-) > > > I provide some (untested) examples of how one might use git below, but I > think that the git book really does a great job of explaining things, and it > doesn't actually take that long to read the first 3 chapters :). > > 1. Basic (SVN like) work: > git clone https://github.com/HazenBabcock/PLplot.git > .. work on file1.x .. > git add file1.x > git commit -m file1.x > .. work on file2.x .. > .. what did I change anyway? .. > git status > git add file2.x > git commit -m file2.x > .. that was a mistake .. > git reset HEAD~1 > .. make correction .. > git add file2.x > git commit -m file2.x > git push origin master > (all the work is local until the changes are pushed back to the remote > repository by git push) > > 2. Work on a branch: > .. dev1 .. > git branch -b epa_build > .. work on epa_build .. add .. commit .. > .. push epa_build to a remote repository so that other can evaluate .. > git push origin epa_build > > .. dev2 .. > git fetch > git checkout epa_build > .. tests & agrees that epa_build works well .. > > .. dev1 .. > .. merge epa_build into master .. > git checkout master > git merge epa_build > git push origin master > .. delete the epa_build branch if it is no longer needed .. > git branch -d epa_build > > > 3. Work with someone who is not a PLplot developer (this is where I think git > really has an advantage): > > .. non-dev .. > git clone dev-repo > git branch -b go_bindings > .. work on go_bindings .. > git push non-dev-repo go_bindings > > .. dev1 .. > git remote add non-dev-repo > git fetch non-dev-repo > git checkout go_bindings > .. see what has been changed in go_bindings compared to master .. > git diff go_bindings..master > .. makes some changes, suggests others .. > git push dev-repo go_bindings > > .. non-dev .. > git fetch dev-repo > git checkout go_bindings > git merge dev-repo/go_bindings > .. implements changes .. > git push non-dev-repo go_bindings > > .. dev1 .. > git fetch non-dev-repo > git checkout go_bindings > git merge non-dev-repo/go_bindings > .. likes go_bindings .. > git checkout master > git merge go_bindings > git push origin master Thanks very much for this summary. It will help me a lot for the planned timeephemeris conversion to git and should reassure others here about the effect of doing such a conversion for PLplot. > > Where non-dev-repo is a publicly available repository. Note that git makes it > much easier for someone who is not a core developer to contribute and it > makes it much easier to evaluate the contributions as you don't have to keep > swapping and applying patch files and/or both have write access to the same > repo. I think this is a really important point. I am convinced that assuming the current PLplot developers are willing to go along with moving PLplot from svn to git, that step will attract additional core developers and also make it easier to collaborate with non-core developers. So this would be a classic case of taking advantage of the power of the "network effect". > It appears that git does not have a properties feature like SVN, so I don't > think there is anything like the SVN prop commands. The current svn properties we use are (1) svn:keywords (used to update a special file comment with a new version number when committing); (2) svn:executable (used to specify if the file is executable), (3) svn:eol-style (used to specify the kind of line-endings that the checked-out version will have), and (4) svn:mime-type (used to specify if the file is a binary file that should remain unmolested (e.g., by not doing line-ending modification on checkout or keyword substitution on checkin). I did some further investigation: According to http://stackoverflow.com/questions/2059326/git-equivalent-of-subversions-url-keyword-expansion, support of svn:keywords is not available with git. However, the historical trend is to remove such version specification commentary from our source code since check-in of a file with such special commentary changes the file and therefore unnecessarily regenerates the build after that checkin. Even if we stayed with svn I would not mind removing all svn:keywords properties so it is actually a positive (in my view) that we would be forced to drop them if we converted to git. "man git-config" mentions setting up configuration for filesystems that do not support the executable bit. The implication is that the git repository stores an execute bit for files, and this is also stated specificially in http://stackoverflow.com/questions/7048763/how-to-stop-git-from-making-files-non-executable-on-cygwin So I think (2) is covered. According to http://stackoverflow.com/questions/2127429/can-i-make-git-svn-handle-svneol-style and "man git-config" it appears that git supports line ending conversions so (3) appears to be covered. Also from my general git background reading, git supports binary blob files so I think (4) is covered as well. In sum, I don't think (1) is a showstopper, but care must be used in the conversion of our svn git repository so that (2) the executable bit is automatically set for executable files on checkout for those filesystems that support that, (3) the correct line ending are used for Unix and Windows systems for non-blob files, and (4) the blob files (such as www/img/bg.jpg) are properly identified as such to git so they don't undergo line-ending transformations. So Hazen, to put these concerns to rest can you check that (2), (3), and (4) are true for your git repo using a Windows checkout (which I think has filesystems that do not support the execute permissions bit and which should certainly have Windows line endings for non-blob files) and a Linux (or Mac OS X) checkout? 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: Chris M. <dev...@gm...> - 2014-02-01 13:02:20
|
I've worked with a number of projects that moved from svn to git via the automated conversion. No hiccups. Oh, you forgot the best part, only one .git directory at the top level of your source tree! :-) --Chris On Fri, Jan 31, 2014 at 3:58 PM, Alan W. Irwin <ir...@be...> wrote: > On 2014-01-31 11:45-0500 Hazen Babcock wrote: > >> On 1/30/2014 5:51 PM, Alan W. Irwin wrote: >>> On 2014-01-30 16:35-0500 Hazen Babcock wrote: >>> >>>> Hello, >>>> >>>> I know this has come up before. However, I've been using git alot at >>>> work and I feel that it has many advantages over SVN and I think we >>>> should again consider switching over (after the next release of course). >>>> To get an idea of the power of git I would suggest reading the first 3 >>>> chapters of this (online) book: >>>> http://git-scm.com/book >>>> >>>> And I was even inspired enough to create a git clone of the PLplot >>>> project which is available here: >>>> https://github.com/HazenBabcock/PLplot >>>> >>>> The conversion was performed using svn2git as described here: >>>> https://github.com/nirvdrum/svn2git >>>> >>>> While I did run into some issues (and bugs in conversion program) along >>>> the way, I believe that it is "complete and accurate", and includes all >>>> the branches and version tags. >>> >>> Hi Hazen: >>> >>> Can you confirm you have been able to preserve all our svn history >>> (which includes our cvs history) in that git repository back to >>> revision 1? If so, that would be a very promising sign concerning the >>> quality of the svn2git conversion tool (or workarounds you used >>> for its conversion bugs). >>> >>> I am more welcoming towards the idea of converting PLplot to a git >>> repository than previously. Thanks to many git recommendations like >>> yours, I do plan to start learning how to use git in the near future. >>> My one collaborator for the timeephemeris project (much less >>> complicated than PLplot) also prefers git, and because of his needs >>> and because I thought it was time to learn git I plan to switch that >>> project from svn to git in the next month or so and will presumably >>> learn git rather fast after that. So let's see how that goes, but >>> assuming that conversion and my practical use of git after that is a >>> success, then I would be willing to go along with a switch to git >>> later this year if our other PLplot core developers are willing to do >>> that as well. >>> >>> I have just reviewed the subset of the svn commands that I ordinarily >>> use with PLplot >>> and other projects. >>> >>> Those are >>> add >>> cat >>> checkout (co) >>> commit (ci) >>> copy (cp) >>> delete (del, remove, rm) >>> diff (di) >>> export >>> help (?, h) >>> log >>> move (mv, rename, ren) >>> propdel (pdel, pd) >>> propedit (pedit, pe) >>> propget (pget, pg) >>> proplist (plist, pl) >>> propset (pset, ps) >>> revert >>> status (stat, st) >>> update (up) >>> >>> You don't have to do this to convince me since I am going to be >>> learning git regardless later this year, but it might help your case >>> with those developers here who are not familiar yet with git and are >>> wondering how painful using git is going to be to create a short >>> summary of how a developer would go about normal PLplot development in >>> a git world. I further suggest you keep that summary as simple as >>> possible (just giving the minimal git commands that do the equivalent >>> of the above svn commands) because one of the intimidating factors for >>> git is the large command set with large numbers of options. That >>> complexity makes git very powerful indeed, but also makes it >>> difficult/intimidating to learn. >> >> Hi Alan, >> >> Regarding the conversion: >> 1. The first ever commit? >> $git log | tail >> Author: furnish <fu...@us...> >> Date: Wed May 20 21:36:02 1992 +0000 >> >> Initial checkin of the whole PLPLOT project. >> >> commit 60a5c3966d86eef16dbf391dc40647fa3fcedb30 >> Author: no_author <no_...@us...> >> Date: Wed May 20 21:36:02 1992 +0000 >> >> New repository initialized by cvs2svn. >> >> 2. Alan's first commit? >> $git log | grep airwin -A 5 | tail >> [snip] >> Author: airwin <ai...@us...> >> Date: Wed May 10 21:24:06 2000 +0000 >> >> Alan W. Irwin. Logic for changing power of 10 to scale z axes is now >> consistent between the left and right z axes. >> >> 3. Hazen's first commit? >> $git log | grep hbabcock -A 5 | tail >> [snip] >> Author: hbabcock <hba...@us...> >> Date: Sun Feb 6 18:25:25 2005 +0000 >> >> Added AquaTerm driver >> >> As an aside, since a git repository is always local this is fast operation. >> Anyway, it looks like history is all there? > > That's a convincing demo! :-) > >> >> >> I provide some (untested) examples of how one might use git below, but I >> think that the git book really does a great job of explaining things, and it >> doesn't actually take that long to read the first 3 chapters :). >> >> 1. Basic (SVN like) work: >> git clone https://github.com/HazenBabcock/PLplot.git >> .. work on file1.x .. >> git add file1.x >> git commit -m file1.x >> .. work on file2.x .. >> .. what did I change anyway? .. >> git status >> git add file2.x >> git commit -m file2.x >> .. that was a mistake .. >> git reset HEAD~1 >> .. make correction .. >> git add file2.x >> git commit -m file2.x >> git push origin master >> (all the work is local until the changes are pushed back to the remote >> repository by git push) >> >> 2. Work on a branch: >> .. dev1 .. >> git branch -b epa_build >> .. work on epa_build .. add .. commit .. >> .. push epa_build to a remote repository so that other can evaluate .. >> git push origin epa_build >> >> .. dev2 .. >> git fetch >> git checkout epa_build >> .. tests & agrees that epa_build works well .. >> >> .. dev1 .. >> .. merge epa_build into master .. >> git checkout master >> git merge epa_build >> git push origin master >> .. delete the epa_build branch if it is no longer needed .. >> git branch -d epa_build >> >> >> 3. Work with someone who is not a PLplot developer (this is where I think git >> really has an advantage): >> >> .. non-dev .. >> git clone dev-repo >> git branch -b go_bindings >> .. work on go_bindings .. >> git push non-dev-repo go_bindings >> >> .. dev1 .. >> git remote add non-dev-repo >> git fetch non-dev-repo >> git checkout go_bindings >> .. see what has been changed in go_bindings compared to master .. >> git diff go_bindings..master >> .. makes some changes, suggests others .. >> git push dev-repo go_bindings >> >> .. non-dev .. >> git fetch dev-repo >> git checkout go_bindings >> git merge dev-repo/go_bindings >> .. implements changes .. >> git push non-dev-repo go_bindings >> >> .. dev1 .. >> git fetch non-dev-repo >> git checkout go_bindings >> git merge non-dev-repo/go_bindings >> .. likes go_bindings .. >> git checkout master >> git merge go_bindings >> git push origin master > > Thanks very much for this summary. It will help me a lot for the > planned timeephemeris conversion to git and should reassure others > here about the effect of doing such a conversion for PLplot. > >> >> Where non-dev-repo is a publicly available repository. Note that git makes it >> much easier for someone who is not a core developer to contribute and it >> makes it much easier to evaluate the contributions as you don't have to keep >> swapping and applying patch files and/or both have write access to the same >> repo. > > I think this is a really important point. I am convinced that > assuming the current PLplot developers are willing to go along with > moving PLplot from svn to git, that step will attract additional core > developers and also make it easier to collaborate with non-core > developers. So this would be a classic case of taking advantage of > the power of the "network effect". > >> It appears that git does not have a properties feature like SVN, so I don't >> think there is anything like the SVN prop commands. > > The current svn properties we use are (1) svn:keywords (used to update > a special file comment with a new version number when committing); (2) > svn:executable (used to specify if the file is executable), (3) > svn:eol-style (used to specify the kind of line-endings that the > checked-out version will have), and (4) svn:mime-type (used to specify > if the file is a binary file that should remain unmolested (e.g., by > not doing line-ending modification on checkout or keyword substitution > on checkin). > > I did some further investigation: > > According to > http://stackoverflow.com/questions/2059326/git-equivalent-of-subversions-url-keyword-expansion, > support of svn:keywords is not available with git. However, the > historical trend is to remove such version specification commentary > from our source code since check-in of a file with such special > commentary changes the file and therefore unnecessarily regenerates > the build after that checkin. Even if we stayed with svn I would not > mind removing all svn:keywords properties so it is actually a positive > (in my view) that we would be forced to drop them if we converted to > git. > > "man git-config" mentions setting up configuration for filesystems > that do not support the executable bit. The implication is that the > git repository stores an execute bit for files, and this is also > stated specificially in > http://stackoverflow.com/questions/7048763/how-to-stop-git-from-making-files-non-executable-on-cygwin > So I think (2) is covered. > > According to > http://stackoverflow.com/questions/2127429/can-i-make-git-svn-handle-svneol-style > and "man git-config" it appears that git supports line ending > conversions so (3) appears to be covered. > > Also from my general git background reading, git supports binary blob > files so I think (4) is covered as well. > > In sum, I don't think (1) is a showstopper, but care must be used in > the conversion of our svn git repository so that (2) the executable bit is > automatically set for executable files on checkout for those > filesystems that support that, (3) the correct line ending are used for > Unix and Windows systems for non-blob files, and (4) the blob files (such > as www/img/bg.jpg) are properly identified as such to git so > they don't undergo line-ending transformations. > > So Hazen, to put these concerns to rest can you check that (2), (3), > and (4) are true for your git repo using a Windows checkout (which I > think has filesystems that do not support the execute permissions bit > and which should certainly have Windows line endings for non-blob > files) and a Linux (or Mac OS X) checkout? > > 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 > __________________________ > > ------------------------------------------------------------------------------ > WatchGuard Dimension instantly turns raw network data into actionable > security intelligence. It gives you real-time visual feedback on key > security issues and trends. Skip the complicated setup - simply import > a virtual appliance and go from zero to informed in seconds. > http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clktrk > _______________________________________________ > Plplot-devel mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel |
From: Hazen B. <hba...@ma...> - 2014-02-04 20:36:57
|
On 1/31/2014 3:58 PM, Alan W. Irwin wrote: > > I did some further investigation: > > According to > http://stackoverflow.com/questions/2059326/git-equivalent-of-subversions-url-keyword-expansion, > > support of svn:keywords is not available with git. However, the > historical trend is to remove such version specification commentary > from our source code since check-in of a file with such special > commentary changes the file and therefore unnecessarily regenerates > the build after that checkin. Even if we stayed with svn I would not > mind removing all svn:keywords properties so it is actually a positive > (in my view) that we would be forced to drop them if we converted to > git. > > "man git-config" mentions setting up configuration for filesystems > that do not support the executable bit. The implication is that the > git repository stores an execute bit for files, and this is also > stated specificially in > http://stackoverflow.com/questions/7048763/how-to-stop-git-from-making-files-non-executable-on-cygwin > > So I think (2) is covered. > > According to > http://stackoverflow.com/questions/2127429/can-i-make-git-svn-handle-svneol-style > > and "man git-config" it appears that git supports line ending > conversions so (3) appears to be covered. > > Also from my general git background reading, git supports binary blob > files so I think (4) is covered as well. > > In sum, I don't think (1) is a showstopper, but care must be used in > the conversion of our svn git repository so that (2) the executable bit is > automatically set for executable files on checkout for those > filesystems that support that, (3) the correct line ending are used for > Unix and Windows systems for non-blob files, and (4) the blob files (such > as www/img/bg.jpg) are properly identified as such to git so > they don't undergo line-ending transformations. > > So Hazen, to put these concerns to rest can you check that (2), (3), > and (4) are true for your git repo using a Windows checkout (which I > think has filesystems that do not support the execute permissions bit > and which should certainly have Windows line endings for non-blob > files) and a Linux (or Mac OS X) checkout? Based on my experience and some tests using the PLplot git repo: (2) executable bit (linux) - This seems to be set correctly based on an analysis of the scripts directory. (3) line endings - The correct line endings are used for unix and windows. (4) blob files - These are properly identified. -Hazen |
From: Alan W. I. <ir...@be...> - 2014-02-04 22:05:52
|
On 2014-02-04 15:36-0500 Hazen Babcock wrote: > On 1/31/2014 3:58 PM, Alan W. Irwin wrote: >> >> I did some further investigation: >> >> According to >> http://stackoverflow.com/questions/2059326/git-equivalent-of-subversions-url-keyword-expansion, >> >> support of svn:keywords is not available with git. However, the >> historical trend is to remove such version specification commentary >> from our source code since check-in of a file with such special >> commentary changes the file and therefore unnecessarily regenerates >> the build after that checkin. Even if we stayed with svn I would not >> mind removing all svn:keywords properties so it is actually a positive >> (in my view) that we would be forced to drop them if we converted to >> git. >> >> "man git-config" mentions setting up configuration for filesystems >> that do not support the executable bit. The implication is that the >> git repository stores an execute bit for files, and this is also >> stated specificially in >> http://stackoverflow.com/questions/7048763/how-to-stop-git-from-making-files-non-executable-on-cygwin >> >> So I think (2) is covered. >> >> According to >> http://stackoverflow.com/questions/2127429/can-i-make-git-svn-handle-svneol-style >> >> and "man git-config" it appears that git supports line ending >> conversions so (3) appears to be covered. >> >> Also from my general git background reading, git supports binary blob >> files so I think (4) is covered as well. >> >> In sum, I don't think (1) is a showstopper, but care must be used in >> the conversion of our svn git repository so that (2) the executable bit is >> automatically set for executable files on checkout for those >> filesystems that support that, (3) the correct line ending are used for >> Unix and Windows systems for non-blob files, and (4) the blob files (such >> as www/img/bg.jpg) are properly identified as such to git so >> they don't undergo line-ending transformations. >> >> So Hazen, to put these concerns to rest can you check that (2), (3), >> and (4) are true for your git repo using a Windows checkout (which I >> think has filesystems that do not support the execute permissions bit >> and which should certainly have Windows line endings for non-blob >> files) and a Linux (or Mac OS X) checkout? > > Based on my experience and some tests using the PLplot git repo: > (2) executable bit (linux) - This seems to be set correctly based on an > analysis of the scripts directory. > (3) line endings - The correct line endings are used for unix and windows. > (4) blob files - These are properly identified. Hi Hazen: Those results look good. Therefore, as far as I am concerned, you have addressed all the preliminary concerns I had, and assuming my conversion of the much smaller timeephem project is a success, then I think it is a good idea (because of the "network effect" advantages I discussed) to convert the PLplot official repo to git. I think I will be able to start that timeephem conversion two to three weeks from now. (It will likely not be sooner than that because of the forthcoming PLplot release, and because I have to release a new version of libLASi right after that PLplot release.) And finishing that timeephem repo conversion, familiarizing myself with git, and testing the result is going to take a while longer (probably until April 1st or so). So Hazen, assuming no other core PLplot developer have questions about the conversion of the official PLplot repo to git would you be willing to do that conversion (at SourceForge, see below) after I have finished my timeephem git evaluation, i.e., roughly April 1st? You also mentioned migrating the official repo (and I assume the rest of PLplot) to github, but let's put that off and stick with git at SourceForge for at least a year if not longer on the principle of not introducing too many major disruptions at once. 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: Jerry <lan...@qw...> - 2014-02-05 00:39:07
|
On Feb 4, 2014, at 3:05 PM, Alan W. Irwin <ir...@be...> wrote: > So Hazen, assuming no other core PLplot developer have questions about > the conversion of the official PLplot repo to git How big will the local copy be? And yes, the learning curve is kinda big. I fiddled around some time back with git w.r.t. LyX, the document processor. As I recall, the local storage requirements can be large. Jerry |
From: Alan W. I. <ir...@be...> - 2014-02-05 05:26:06
|
On 2014-02-04 17:20-0700 Jerry wrote: > > On Feb 4, 2014, at 3:05 PM, Alan W. Irwin <ir...@be...> wrote: > >> So Hazen, assuming no other core PLplot developer have questions about >> the conversion of the official PLplot repo to git > > How big will the local copy be? And yes, the learning curve is kinda big. I fiddled around some time back with git w.r.t. LyX, the document processor. As I recall, the local storage requirements can be large. @Jerry: Good question on local size which I hope Hazen is in a position to answer. @Hazen: Here is a related question. My understanding from superficial reading is that git users normally have a local repository (unlike the svn case where there is normally just one repository). But if someone is worried about the disk space that is required by that local git repository, is there also a detached repository mode for git (i.e., so the user could simply use the SourceForge repository without copying all of the repository to his own computer)? 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: Hezekiah M. C. <hez...@us...> - 2014-02-05 14:50:40
|
On Tue, Feb 4, 2014 at 7:20 PM, Jerry <lan...@qw...> wrote: > > On Feb 4, 2014, at 3:05 PM, Alan W. Irwin <ir...@be...> wrote: > >> So Hazen, assuming no other core PLplot developer have questions about >> the conversion of the official PLplot repo to git > > How big will the local copy be? And yes, the learning curve is kinda big. I fiddled around some time back with git w.r.t. LyX, the document processor. As I recall, the local storage requirements can be large. > The last time I checked a checkout of a complete PLplot history was approximately 20 megabytes. This was about a year ago. Moving to git and github for PLplot will be a significant benefit to the project I expect. Both tools make external contributions much easier to make, review and merge. github's review tools are rather excellent compared to others I've used. Hez |
From: Maurice L. <mj...@br...> - 2014-02-05 04:38:33
|
As part of the pilot effort, be sure to test interoperability with git under Cygwin. In a previous position I worked with another developer who used that configuration, and his added files had their permissions all messed up when checking out under Linux. Basically all the rwx bits were set. When I unset the ones I didn't want, he got conflicts when trying to check out. Might be an easily resolved issue, I never did figure it out. Was a few years back. -- Maurice LeBrun |
From: Alan W. I. <ir...@be...> - 2014-02-05 05:15:37
|
On 2014-02-04 22:19-0600 Maurice LeBrun wrote: > As part of the pilot effort, be sure to test interoperability with git under > Cygwin. In a previous position I worked with another developer who used that > configuration, and his added files had their permissions all messed up when > checking out under Linux. Basically all the rwx bits were set. When I unset > the ones I didn't want, he got conflicts when trying to check out. Might be > an easily resolved issue, I never did figure it out. Was a few years back. @Maurice: Thanks for that notice of a possible git problem with Cygwin permissions. @Arjen: As the only one here with both Cygwin and timeephem experience, are you game to do such a test for timeephem after I do a preliminary conversion to git for that project? 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: Arjen M. <Arj...@de...> - 2014-02-05 07:24:23
|
Hi Alan, > -----Original Message----- > From: Alan W. Irwin [mailto:ir...@be...] > Sent: Wednesday, February 05, 2014 6:15 AM > To: Arjen Markus; Maurice LeBrun > > @Maurice: > > Thanks for that notice of a possible git problem with Cygwin permissions. > I have seen some problems with permissions under Cygwin - both with PLplot and with another, unrelated, project. Cygwin tries very hard to unite the POSIX style of file permissions with the Windows style and they are in some respects simply incompatible. I do think things have improved over the past few years, but I have no idea how that relates to git. > @Arjen: > > As the only one here with both Cygwin and timeephem experience, are you game to > do such a test for timeephem after I do a preliminary conversion to git for that project? > Sure, as I have never worked with git, that ought to be an interesting experience ;). Regards, Arjen DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail. |
From: Chris M. <dev...@gm...> - 2014-02-05 11:01:52
|
I've had no permissions problems with cygwin + git since PDL switched to git a few years ago. The only problems with windows systems happen when folks edit a unix line endings file and save it as a windows line endings text file and then push that change. --Chris On Wed, Feb 5, 2014 at 2:23 AM, Arjen Markus <Arj...@de...> wrote: > Hi Alan, > >> -----Original Message----- >> From: Alan W. Irwin [mailto:ir...@be...] >> Sent: Wednesday, February 05, 2014 6:15 AM >> To: Arjen Markus; Maurice LeBrun >> >> @Maurice: >> >> Thanks for that notice of a possible git problem with Cygwin permissions. >> > > I have seen some problems with permissions under Cygwin - both with PLplot and with > another, unrelated, project. Cygwin tries very hard to unite the POSIX style of file permissions > with the Windows style and they are in some respects simply incompatible. I do think things > have improved over the past few years, but I have no idea how that relates to git. > >> @Arjen: >> >> As the only one here with both Cygwin and timeephem experience, are you game to >> do such a test for timeephem after I do a preliminary conversion to git for that project? >> > > Sure, as I have never worked with git, that ought to be an interesting experience ;). > > Regards, > > Arjen > DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail. > > ------------------------------------------------------------------------------ > Managing the Performance of Cloud-Based Applications > Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. > Read the Whitepaper. > http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk > _______________________________________________ > Plplot-devel mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel |
From: Arjen M. <Arj...@de...> - 2014-02-05 11:11:40
|
Hi Chris, good to hear that. But I do remember - from, admittedly, long ago - that at installation time of Cygwin you could opt for either Windows or Linux line endings. Maybe that option has been dropped and we will not have to deal with any complications of that kind ... oh, regardless, I just realize: people can edit files with their favourite Windows editor and commit them under Cygwin. Hm, is there any way to prevent that? (Right now, I edit the files under Windows but I also commit them under Windows - which makes for a consistent view.) Regards, Arjen > -----Original Message----- > From: Chris Marshall [mailto:dev...@gm...] > Sent: Wednesday, February 05, 2014 12:02 PM > To: Arjen Markus > Cc: Alan W. Irwin; Plplot-devel mailing list > Subject: Re: [Plplot-devel] git (again) > > I've had no permissions problems with cygwin + git since PDL switched to git a few > years ago. The only problems with windows systems happen when folks edit a unix > line endings file and save it as a windows line endings text file and then push that > change. > > --Chris > > > On Wed, Feb 5, 2014 at 2:23 AM, Arjen Markus <Arj...@de...> wrote: > > Hi Alan, > > > >> -----Original Message----- > >> From: Alan W. Irwin [mailto:ir...@be...] > >> Sent: Wednesday, February 05, 2014 6:15 AM > >> To: Arjen Markus; Maurice LeBrun > >> > >> @Maurice: > >> > >> Thanks for that notice of a possible git problem with Cygwin permissions. > >> > > > > I have seen some problems with permissions under Cygwin - both with > > PLplot and with another, unrelated, project. Cygwin tries very hard to > > unite the POSIX style of file permissions with the Windows style and > > they are in some respects simply incompatible. I do think things have improved > over the past few years, but I have no idea how that relates to git. > > > >> @Arjen: > >> > >> As the only one here with both Cygwin and timeephem experience, are > >> you game to do such a test for timeephem after I do a preliminary conversion to > git for that project? > >> > > > > Sure, as I have never worked with git, that ought to be an interesting experience ;). > > > > Regards, > > > > Arjen > > DISCLAIMER: This message is intended exclusively for the addressee(s) and may > contain confidential and privileged information. If you are not the intended recipient > please notify the sender immediately and destroy this message. Unauthorized use, > disclosure or copying of this message is strictly prohibited. The foundation 'Stichting > Deltares', which has its seat at Delft, The Netherlands, Commercial Registration > Number 41146461, is not liable in any way whatsoever for consequences and/or > damages resulting from the improper, incomplete and untimely dispatch, receipt > and/or content of this e-mail. > > > > ---------------------------------------------------------------------- > > -------- Managing the Performance of Cloud-Based Applications Take > > advantage of what the Cloud has to offer - Avoid Common Pitfalls. > > Read the Whitepaper. > > http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg. > > clktrk _______________________________________________ > > Plplot-devel mailing list > > Plp...@li... > > https://lists.sourceforge.net/lists/listinfo/plplot-devel > DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail. |
From: Hazen B. <hba...@ma...> - 2014-02-05 15:26:00
|
On 2/5/2014 12:25 AM, Alan W. Irwin wrote: > >> How big will the local copy be? And yes, the learning curve is kinda > big. I fiddled around some time back with git w.r.t. LyX, the document > processor. As I recall, the local storage requirements can be large. > > @Jerry: > > Good question on local size which I hope Hazen is in a position to > answer. > > @Hazen: > > Here is a related question. My understanding from superficial reading > is that git users normally have a local repository (unlike the svn > case where there is normally just one repository). But if someone is > worried about the disk space that is required by that local git > repository, is there also a detached repository mode for git (i.e., so > the user could simply use the SourceForge repository without copying > all of the repository to his own computer)? This is no longer true? I checked out PLplot using git (master branch) and svn (trunk), which I believe to be roughly equivalent and the sizes are: (svn checkout http://svn.code.sf.net/p/plplot/code/trunk plplot) SVN: 36.2MB (43.8MB on disk) (git clone https://github.com/HazenBabcock/PLplot.git) GIT: 40.1MB (44.0MB on disk) I'm pretty sure that there is nothing like a detached repository mode. Everything is local as they say. -Hazen |
From: Jerry <lan...@qw...> - 2014-02-05 23:01:35
|
On Feb 5, 2014, at 8:25 AM, Hazen Babcock <hba...@ma...> wrote: > On 2/5/2014 12:25 AM, Alan W. Irwin wrote: >> >>> How big will the local copy be? And yes, the learning curve is kinda >> big. I fiddled around some time back with git w.r.t. LyX, the document >> processor. As I recall, the local storage requirements can be large. >> >> @Jerry: >> >> Good question on local size which I hope Hazen is in a position to >> answer. >> >> @Hazen: >> >> Here is a related question. My understanding from superficial reading >> is that git users normally have a local repository (unlike the svn >> case where there is normally just one repository). But if someone is >> worried about the disk space that is required by that local git >> repository, is there also a detached repository mode for git (i.e., so >> the user could simply use the SourceForge repository without copying >> all of the repository to his own computer)? > > This is no longer true? I checked out PLplot using git (master branch) and svn (trunk), which I believe to be roughly equivalent and the sizes are: > > (svn checkout http://svn.code.sf.net/p/plplot/code/trunk plplot) > SVN: 36.2MB (43.8MB on disk) > > (git clone https://github.com/HazenBabcock/PLplot.git) > GIT: 40.1MB (44.0MB on disk) That's interesting. My superficial understanding of git (also) is that the user stores the entire history of a project locally (with the advantage that checking stuff in and out is very fast). That means that apparently the PLplot history is stored very efficiently since the git size is only a little larger than the svn size. Also, I didn't spend enough time learning git to figure out what advantage there is when updating the master with a local repo--there still must be issues with conflicts. And is there any mechanism to lock a file while it is being edited, since it is checked out from the local repo and the master has no clue of the file's status. I recall we had a discussion of this recently w.r.t. svn where most agreed that conflicts like this are a rare event but there is indeed a locking mechanism of some sort if one chooses to use it. Jerry > > I'm pretty sure that there is nothing like a detached repository mode. Everything is local as they say. > > -Hazen > |
From: Alan W. I. <ir...@be...> - 2014-02-05 17:58:00
|
On 2014-02-05 06:01-0500 Chris Marshall wrote: > I've had no permissions problems with cygwin + git since PDL > switched to git a few years ago. The only problems with windows > systems happen when folks edit a unix line endings file and > save it as a windows line endings text file and then push that > change. Hi Chris: For our svn repository there are no text files with fixed Unix or Windows line endings. Instead, they are all native, i.e., they are converted to/from the proper line endings for the given platform on checkout or commit. >From my reading (look at the documentation of repository properties available when you run the git help config command) git has a property for text files called core.eol, and native is the default for that property. So as long as we don't fiddle with that default (and Hazen's tests of the PLplot git repository he created were reassuring on that point), then all our text files will have the correct native treatment of line endings. Therefore, we should never run into the problem you described that occurs if fixed (either Unix or Windows) line endings are used instead of native line endings unless someone goes out of their way (e.g., by fiddling with the core.eol configuration property for the repository) to allow text files with fixed line endings. 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-02-09 05:54:31
|
On 2014-02-05 09:57-0800 Alan W. Irwin wrote: > For our svn repository there are no text files with fixed Unix > or Windows line endings. Instead, they are all native, i.e., they are > converted to/from the proper line endings for the given platform on > checkout or commit. Oh well. I should have said _in theory_ there are no text files with fixed line endings in our svn repository. In fact, it is not difficult to screw this up with svn, and I did so when I created most of the files in the cmake/epa_build tree and forgot to set the svn:eol-style property for each of those new files. Fortunately, in this case the fix was easy; the files in that tree are all text files which allowed me with one svn command to set (revision 12987) svn:eol-style to native for all files under svn control in that tree. In git (at least for new files) you don't have to set anything special; text files are treated as having native line endings by default according to the git documentation. And that is arguably a much better default than the svn case where line endings are under no control at all by default. 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-02-06 11:27:24
|
On 2/4/2014 5:05 PM, Alan W. Irwin wrote: > > So Hazen, assuming no other core PLplot developer have questions about > the conversion of the official PLplot repo to git would you be willing > to do that conversion (at SourceForge, see below) after I have > finished my timeephem git evaluation, i.e., roughly April 1st? Yes I am willing to do this. -Hazen |
From: Alan W. I. <ir...@be...> - 2014-04-02 08:14:28
|
On 2014-02-06 06:27-0500 Hazen Babcock wrote: > On 2/4/2014 5:05 PM, Alan W. Irwin wrote: >> >> So Hazen, assuming no other core PLplot developer have questions about >> the conversion of the official PLplot repo to git would you be willing >> to do that conversion (at SourceForge, see below) after I have >> finished my timeephem git evaluation, i.e., roughly April 1st? > > Yes I am willing to do this. Hi Hazen: I haven't forgotten this important topic, but since the release of 5.10.0 I have obviously been caught up in a number of PLplot development issues. So I have had to substantially delay the serious look at git (including converting the timeephem project from svn to git) that I had planned for March. Anyhow, it looks like roughly a week or so from now I will finally be able to start that serious look. Thus, my latest rough estimate is it will likely be May 1st or so when I will finally be in a position to give you the go ahead to convert the PLplot svn repository 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-04-03 16:56:33
|
On 4/2/2014 4:14 AM, Alan W. Irwin wrote: > On 2014-02-06 06:27-0500 Hazen Babcock wrote: > >> On 2/4/2014 5:05 PM, Alan W. Irwin wrote: >>> >>> So Hazen, assuming no other core PLplot developer have questions about >>> the conversion of the official PLplot repo to git would you be willing >>> to do that conversion (at SourceForge, see below) after I have >>> finished my timeephem git evaluation, i.e., roughly April 1st? >> >> Yes I am willing to do this. > > I haven't forgotten this important topic, but since the release of > 5.10.0 I have obviously been caught up in a number of PLplot > development issues. So I have had to substantially delay the serious > look at git (including converting the timeephem project from svn to > git) that I had planned for March. Anyhow, it looks like roughly a > week or so from now I will finally be able to start that serious look. > Thus, my latest rough estimate is it will likely be May 1st or so when > I will finally be in a position to give you the go ahead to convert > the PLplot svn repository to git. Hi Alan, That sounds fine to me. -Hazen |
From: Alan W. I. <ir...@be...> - 2014-07-30 07:41:49
|
Hazen already knows about this, but just to let this list know as well my first attempt to convert the timeephem svn repo to a git repo appears to be a complete success with regard to the history (i.e., all revisions with some well-understood exceptions appear to be present in the git history as expected). Hazen is doing the equivalent with PLplot of everything I have done with timeephem, and that is a big help to me with my timeephem conversion, and I hope vice versa. In sum, it is looking good so far, but there is still quite a bit of additional testing needed for the git repositories for timeephem and PLplot that have been created as well as some other practical steps required before the official conversion to git repositories for both projects will be completed. More later as the testing of these git repos continues. 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-04 08:09:20
|
On 2014-07-30 00:41-0700 Alan W. Irwin wrote: > In sum, it is looking good so far, but there is still quite a bit of > additional testing needed for the git repositories for timeephem and > PLplot that have been created as well as some other practical steps > required before the official conversion to git repositories for both > projects will be completed. > > More later as the testing of these git repos continues. I have created a bash script to do this testing which compares directory trees for (sampled) revisions of svn/trunk, and the HEAD revisions of the svn/branches and svn/tags with their corresponding git directory trees. This script has worked well for the timeephem case. The result is I am completely satisfied with the comprehensive test results generated by this script for the local timeephem git repository I have created, and the next step is configuration of the timeephem project at SF to switch from an svn to git repository there. I have shared that testing script with Hazen so he should not be too far behind me in reporting complete testing success (I hope) for the PLplot git case as well. Soon after he reports such success, PLplot will be switching to a git repo at SF, and those here who still do not know git will have to learn it in order to continue to develop PLplot. I am happy to say that I have found git (at the substantially more than newbie level required by the above script) quite easy to learn in a day or so starting from no git knowlege at all. That learning process was greatly accelerated by reading the first few chapters in the highly recommended Pro Git book which is a free download from http://git-scm.com/book. git newbies should especially note that git subcommands often have the same names as svn subcommands, (e.g., git checkout versus svn checkout). But also note that the two subcommands with the same name have either subtle or obvious semantic differences between git and svn. So because of those semantic differences my best advice is to completely forget your svn subcommand knowledge. Furthermore, git help <commandname> is your friend, and if you are running bash, there is a nice bash extension available for git (at least on Debian) that allows tab completion for all fields of a git command. For example, "git checkout <tab>" tells you all possible git ID's you have access to for a particular git repository, and that is a huge convenience. In sum, I thank Hazen for doing such a good job of advocating git for PLplot, and I am very much looking forward to the git era for PLplot (and timeephem) that should be happening fairly soon. 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-04 23:12:17
|
On 2014-08-04 01:09-0700 Alan W. Irwin wrote: > [....]The result is I am completely satisfied with the comprehensive > test results generated by this script for the local timeephem git > repository I have created, and the next step is configuration of the > timeephem project at SF to switch from an svn to git repository there. I have done that now, and the local clone of that SF repo for timeephem passes all the same comprehensive tests that I did for the original local repo via my tailored test script. So this effort officially completes my conversion of timeephem from a SF subversion repository (now kept read-only) to a git SF repository, and the timeephem development from now on will utilize git instead of svn. Now that I am done with the timeephem case, my understanding is Hazen plans to follow up with the completion of the same conversion from svn to git for the PLplot case utilizing my experience for the timeephem case. 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 __________________________ |