On Tue, 2012-03-27 at 21:44 +0200, Peter Gavin wrote: > Hello, > > So after some discussion with a few developers, I feel that its time > that any issues the group has concerning the development repository > need to be resolved, especially since I'm doing a lot of work > coalescing a lot of contributions, and there seems to be some concern > from some members with respect to the current SVN setup. I'm > currently using git for my work, and I'm currently working on two > trees: > > or1k-src: I started this tree by cvs checkout'ing the sourceware.org > src tree (see http://sourceware.org/cgi-bin/cvsweb.cgi/?cvsroot=src), > and doing cvs updates in one branch, while keeping my work in another > branch. The CVS subdirectories are also watched by git. Whenever I do > a cvs update, I rebase my work tree on top of it so my work can always > be made into a diff against the upstream tree. So far, I've completed > the binutils port to use cgen, and I'm currently working on getting > gdb to use cgen (I'd say the gdb part is halfway done). > > or1k-gcc: This is a clone of the gcc read-only git tree. The gcc > read-only git tree is a git-svn clone of the main gcc svn repo. I > periodically rebase my work on top of the upstream, again to make > diffs easier. I started off this tree by cloning Giuseppe's gcc tree. > > So, as I've mentioned, I prefer git, but I understand some devs and > many users prefer svn. Git has the advantage of making tracking an > upstream tree simple (via rebasing), while svn AFAIK does not. > However, git does have decent svn interoperability, so that gives us a > couple of options: > > 1. The central repo can still be svn, and users/devs wishing to use > git can use git-svn to pull/push changes. > > 2. (My preference.) The central repo can use git, and a read-only svn > mirror can be provided by using a cron job to push changes from the > git repo into the svn repo. This keeps it simple for users who don't > care about making changes and are accustomed to SVN, but still want to > keep the most recent version of everything. Devs would be best off > changing to git. I think this would be the best way to handle the > or1k-src repo (which tracks a CVS upstream), because trying to make 3 > different VC tools work together will be a nightmare.
Hi Pete, Thanks for this post - it is a well thought out analysis of the situation. I'm surprised there have not been more comments. Thank you also for the work you are doing. I look forward to trying out your tool chain when it is complete. I know it is less convenient for you, but for the reasons outlined by Olof in his email (I'll reply to that as well), I strongly recommend option 1. In addition, while at present you are the only active developer, over the years there have been quite a number of others. They contribute from time-to-time as their time permits. Making your change would require them all to change to a git-based flow, and I would be reluctant to add that burden to them. For binutils/newlib/gdb there is a particular issue that upstream is a centralised system (CVS). We hold it in a related, but different centralised system (SVN). To then add a third decentralised system (git) seems a potential source of chaos. The opportunity for little details like file modes or line endings to get messed up is immense. We do have open source developers who work in Windows environments, and some parts of the GCC test suite do rely on enforcing particular file formats to allow OS specific testing. We should be making more use of git on OpenCores (it has git facilities, but no one uses them). In particular that is the correct place to hold Linux, uClibc and BusyBox, since they are git upstream. Let me know how I can help. Best wishes, Jeremy -- Tel: +44 (1590) 610184 Cell: +44 (7970) 676050 SkypeID: jeremybennett Email: [email protected] Web: www.embecosm.com _______________________________________________ OpenRISC mailing list [email protected] http://lists.openrisc.net/listinfo/openrisc
