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 <furn...@users.sourceforge.net> > Date: Wed May 20 21:36:02 1992 +0000 > > Initial checkin of the whole PLPLOT project. > > commit 60a5c3966d86eef16dbf391dc40647fa3fcedb30 > Author: no_author <no_aut...@users.sourceforge.net> > 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 <air...@users.sourceforge.net> > 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 <hbabc...@users.sourceforge.net> > 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 Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
