Hi Gary, That is quite a good summary of git-svn. The command:
$ git svn dcommit to perform a commit to the subversion repository is very useful - I'd forgotten about this one. With this, the git-svn technique is not such a bad temporary solution. The link at the end, http://www.jukie.net/~bart/blog/svn-branches-in-git, is also very useful. But it does not solve the problem of the subversion branch management which I would still need to perform with svnmerge.py. Branch management is the primary deficiency of the git-svn solution. My main worries with the git-svn solution are the caveats as described in the git-svn documentation (https://www.kernel.org/pub/software/scm/git/docs/git-svn.html#_caveats), specifically: "For the sake of simplicity and interoperating with Subversion, it is recommended that all git svn users clone, fetch and dcommit directly from the SVN server, and avoid all git clone/pull/merge/push operations between git repositories and branches. The recommended method of exchanging code between git branches and users is git format-patch and git am, or just 'dcommit’ing to the SVN repository." This blocks a lot of the git functionality. So I believe that it's not as ideal as migrating the entire repository to git. Cheers, Edward On 24 July 2013 15:57, Gary Thompson <[email protected]> wrote: > > > Hi > > > this may be of some use on the git vs svn debate > > http://maymay.net/blog/2009/02/24/how-to-use-git-svn-as-the-only-subversion-client-youll-need/ > > regards > gary > > > On 07/24/2013 10:44 AM, Edward d'Auvergne wrote: > > Hi Troels, > > This is the second message, the positive one :) I will start off with > repeating the end of the last message > (http://thread.gmane.org/gmane.science.nmr.relax.devel/4244/focus=4245). > I think that switching to git is a good idea and I would personally > benefit from having a distributed version control system (writing code > on the train, plane, etc. would be much easier). Switching to git has > been something that I have considered for many years now. The reason > why relax still uses subversion is that git is not currently supported > by the Gna! infrastructure. Note that a shift is also incredibly > disruptive, so a quiet period in relax's development is needed for > this to even be considered. I consider the migration to git as a real > solution and that git-svn is just a distraction. > > Now, for the suggestion of using the archived mailing list messages, > you should take note that the messages at > http://www.mail-archive.com/[email protected]/ do not always > appear. This is also a problem at > http://dir.gmane.org/gmane.science.nmr.relax.scm. I don't know why, > but at random times a message will not be archived. It is quite rare, > but would be fatal for maintaining a separate git repository. The > other aspect that would be fatal is that you can see that the revision > numbers are out of order in these archives. The messages do not > appear in order and can be delayed by days. We can, however, get the > relax-commits mailing list to push out emails to a dedicated email > address - partly resolving this issue. There are still issues of the > automatic subversion hooks at Gna! sending the message to the > relax-commits mailing list. I don't know if it is the svn hooks or > the mailing list archivers which are the cause of the missing or > delayed messages. > > Also note that the subversion work flow described in > http://wiki.nmr-relax.com/Git_development is not correct. This is the > work flow for a new developer. For an accepted developer, the > subversion process is much simpler - write code, then commit. Patch > review is not part of this process. If a process is in place, there > should be no patches involved - it takes too much time. Therefore the > figure http://wiki.nmr-relax.com/File:Git_development.png is not > correct, and one of the standard git-svn solutions might be > sufficient. One problem with this git-svn process is branch > management. For this, the developer maintaining a branch will require > their git repository, a copy of the branch in an svn checked out copy, > and the use of the svnmerge.py script to keep the branch in sync (via > the svn code). These complications might outweigh the benefits of > using git. > > The better alternative, as mentioned above, would be to have the > entire relax subversion repository migrated to git. This might have > already have happened if the Gna! infrastructure supported git. This > is not really a suitable solution for now, but having a wiki page in > the future describing the full migration might be useful for the > process. Therefore my suggestion is to have the goal of getting Gna! > to support git. > > Note that the Gna! maintainers are quite inactive - they only make > sure that the infrastructure continues to function correctly. > Therefore they have refused in past service requests to add this > feature. But they have indicated in private discussions with > individual developers that they are happy to have someone join them to > help make some minor changes. One of the key people to discuss this > with is zerodeux (http://gna.org/users/zerodeux). You should know the > admins (http://gna.org/projects/admin), especially the names of the > top 3, as well as beuc (http://gna.org/users/beuc). And also note > that Eric S. Raymond (http://gna.org/users/esr) is an admin (if you > don't know who this is, see > http://en.wikipedia.org/wiki/Eric_S._Raymond). If you are interested, > persistent and competent enough, you may be able to join the Gna! > admins and set up git. You don't have to be in the same league as ESR > for this ;) > > But you should also research the history of the Savane project > (http://en.wikipedia.org/wiki/GNU_Savannah#Savane). That Savane has > stopped development (http://gna.org/projects/savane/). That there are > two incomplete derivative projects > (http://savannah.nongnu.org/p/savane-cleanup and > http://savannah.nongnu.org/p/savane), but that Gna! is running on the > old savane code. You should also read about Gna! > (http://about.gna.org/) and know that Gna! is the European equivalent > of GNA Savannah (US-based), but that the Gna! philosophy is slightly > different - it is more 'free software' oriented than 'open source' > oriented. Gna! is also smaller than Savannah, and less up to date (it > uses the old savane code and hence it has no git support, whereas > Savannah uses savane-cleanup and has git support). > > There are some very big names in open source there, including the one > who pioneered the 'open source' philosophy. So I would suggest to > first build up some trust. This would be to first contribute code to > relax and to become an accepted developer. Then the Gna! people will > take you more seriously. I would also recommend that you try to set > up a project on Gna!, maybe with your original scripts (after becoming > a relax developer). This is more as a permanent repository and > reference rather than an active project. This will teach you a huge > amount about the open source infrastructure - and that the source code > repository is only a tiny part of this. This is the infrastructure > behind SourgeForge, GNU Savannah, and Gna! There is a lot to learn. > So maybe the suggestion of getting Gna! to support git, by becoming a > Gna! admin and upgrading the entire site (maybe with ESR helping) to > savane-cleanup, might be too much effort. > > The git-svn way might be easiest, but first try to get the code out > and become a full relax developer. Then the git-svn picture > (http://wiki.nmr-relax.com/Git_development) will be quite different > and much simpler. I still think that git-svn would be a non-ideal > temporary solution. > > Regards, > > Edward > > > > On 24 July 2013 01:54, Troels Emtekær Linnet <[email protected]> wrote: > > Hi relax developers. > > I would like to suggest yet another development possibility by using Git. > > Motivation: > Subversion needs an online repository, to store each commits. > Subsequent calls to svn diff > patch will generate the difference > according to the last revision. > Therefore the development at the moment require to: > * make some lines of code > * make a path file and a commit message > * use the support tracker to upload patch and commit message > wait for acceptance > wait for commit to official repository > then do an svn update > then return to point 1 > > This takes time, and require that repository maintainer is online. > If the above scheme is not followed, the patch files will come out of sync. > > I suggest to introduce yet another development possibility by using Git. > > I do not suggest to shift away from the GNA! infrasctructure, > I merely suggest to use the powers of Git, to collaborate on a feature > development, before > releasing a patch for review and commit to SVN repository. > > This is maintained by a server, who tracks the relax-commit messages at > http://www.mail-archive.com/[email protected]/ > > That server translates the history, and commits to github. > > Here a range of developers can pull the latest changes. > Make feature branches. Share those branches. > Make edits online. Use android/iphone apps. > Work on trains/planes etc. Allowing offline commits. > > When the feature is ready, easily make a patch file, and upload > to the GNA trackers. > > The patch file contains all the commit messages, and > changes between each commit. > > That should make it easy to review, and comment on. > > Git also allow to squash commits and rewrite commits. > A feature highly appreciated, based on the review comments. > > I have made a wiki page, from where we can start discussing. > Here I tried to make an image of my idea. > I am very skilled in MS paint. :-) > > http://wiki.nmr-relax.com/Git_development > > Best > Troels Emtekær Linnet > > _______________________________________________ > relax (http://www.nmr-relax.com) > > This is the relax-devel mailing list > [email protected] > > To unsubscribe from this list, get a password > reminder, or change your subscription options, > visit the list information page at > https://mail.gna.org/listinfo/relax-devel > > _______________________________________________ > relax (http://www.nmr-relax.com) > > This is the relax-devel mailing list > [email protected] > > To unsubscribe from this list, get a password > reminder, or change your subscription options, > visit the list information page at > https://mail.gna.org/listinfo/relax-devel > > > > -- > ------------------------------------------------------------------- > Dr Gary Thompson [Homans Lab Research Coordinator] > > Astbury Centre for Structural Molecular Biology, > University of Leeds, > Leeds, LS2 9JT, West-Yorkshire, UK Tel. +44-113-3433024 > email: [email protected] Fax +44-113-3431935 > ------------------------------------------------------------------- > > > > > _______________________________________________ > relax (http://www.nmr-relax.com) > > This is the relax-devel mailing list > [email protected] > > To unsubscribe from this list, get a password > reminder, or change your subscription options, > visit the list information page at > https://mail.gna.org/listinfo/relax-devel > _______________________________________________ relax (http://www.nmr-relax.com) This is the relax-devel mailing list [email protected] To unsubscribe from this list, get a password reminder, or change your subscription options, visit the list information page at https://mail.gna.org/listinfo/relax-devel
