- converted svn rcdb repository to github repository in standard way. put it in the markito3 account on github
- cloned original jeffersonlab/rcdb (mostly empty) to local disk
- in the local repo:
- git remote add rcdb_mmi https://github.com/markito3/rcdb
- git pull rcdb_mmi master:rcdb_mmi_merge
- git push
- jeffersonlab/rcdb has svn files and history now
Under Fedora 23:
sudo dnf install git-svn sudo gem install svn2git
Had to do this because svn2git went south on RHEL7 desktop (lorentz). Could not find git-svn in the repositories anywhere on that machine.
• create a branch, push to github
• make existing branch track the one on github
• check in more changes on the local branch
• push without arguments
• ends up going to tracked branch
Questions and answers for plan to conversion to use of the new git repository:
- Where to locate the new JLab working version?
- In /group/halld/Software/build_scripts. This is a move from SVN location under scripts. The old location is misleading now since build_scripts is no longer an SVN subdirectory of scripts.
- Is the working version an archive or a clone?
- It is a clone. That way one can inquire about version information.
- Is the working version a release branch or master?
- For now is is a temporary branch. See below.
The conversion was done at SVN revision 19207. The last change to build_scripts previoiusly was at revision 19203.
The head of the build_scripts master branch does not support getting code from Git repositories at all. It does support getting source from Subversion repositories. Before conversion of build_scripts to Git, in special versions of Makefile_hdds and Makefile_sim-recon an archive is made from the local JLab Git repositories to support the nightly builds. The build_halld.csh script did this by changing the checkout (from subversion) of build_scripts to get these special versions at revision 19034 of build scripts via svn update. Note that this only worked at JLab. Here is the relevant part of the script.
< # temp update of git-enabled makefiles
< pushd build_scripts
< svn update -r19034 Makefile_hdds Makefile_sim-recon
In git this commit this svn revision is commit 16fa07793df6bf77359dd597a5e99cf685dd2f70
On JLab, in the Software/build_scripts repository, made branch nightly_temp that uses the local-only git enabled versions of Makefile_hdds and Makefile_sim-recon. It also has a modified version of build_halld.csh that will git-archive from this branch. That repository has this branch checked-out so that the special version of build_halld.csh is out there to be used.
The nightly build is now accessing build_scripts in this location, i. e., /group/halld/Software/build_scripts.
Rev 19042 2015-07-15 17:35:06
incremental conversion did not work, sim-recon/src/plugins directory did not make it, starting over
- delete the practice repositories on GitHub
- create a blank repository to receive the converted repository on GitHub
- make a copy of the complete Subversion repository on the local disk with rsync
- use svn2git to do the conversion using the local-disk-resident version of the Subversion repository
- in the resulting git repository, delete branches and tags not related to the package, as well as all “@revision” branches and tags
- clone a bare copy of the repository (–bare option)
- push the bare copy to the GitHub repository with the –mirror option
- add repositories to the list of those owned by the gluex team on GitHub
The sim-recon conversion with svn2git took about 8 hours. hdds took about 20 hours
Notes on conversion from subversion to git for gluex.
- What happens if a pull request has a conflict?
- It cannot be merged on the github site. instructions on how to do it on the command line are available.
- Should we use rebasing?
- rebasing introduces possibilities for errors, commits are replayed on another branch, thus commits exist (in an operational sense) twice. Thus the admonition, do not rebase commits that exist outside your local repository. Pull requests generated on github satisfy this no-go situation for rebasing by construction. Rebasing an expert operation, IMHO.
- How are we notified of pull requests
- those interested in acting on pull should “watch” the appropriate repository. go to settings/notification to configure how you are notified. go to the repository page (after logging in) to mark the repository as being watched/not-watched/ignored by you using the pull down menu at the top of the page