On 06/17/15 03:10, Peterson, Joe wrote: > Hello all, > > There are a lot of conflicting ideas on how we should lay out our > EDK2 repo using Git. We have Submodules, Subtrees, using soft links, > etc. Some of the suggestions won't work for various reasons- ex. repo > isn't supported on Windows, which is very common amongst EDK2 users. > > > What are everyone's thoughts on just staying with SVN with our mirror > on github for people who want to use git locally (and they can check > in using git svn)
I prefer to stay with the current setup (ie. SVN is the primary, the git mirror is r/o) over switching to a split-up git environment. (I believe the same has been voiced by others -- Ard maybe?) Nonetheless, patches should be formatted, documented (ie. in commit messages), and posted to edk2-devel with git tools, in the git way. That is to say, I don't mind the "SVN backend as primary" going forward, but user interaction & public workflow should be centered on git 100%. No more patches formatted with "svn" (the utility), no more patches in attachments, and no more direct commits made with "svn" (the utility), please. This means that the people who use git locally (including committing with "git svn dcommit") must be the *exact* same set as the people who post patches to edk2-devel How stuff gets pulled into Intel's internal builds via SVN externals should not affect the edk2-devel workflow; the latter should migrate to git entirely. > I know there was a lot of support and several > requests to move to git, so I would like to understand a little more > about why people feel subversion isn't working out for us. There are two (groups) of issues with subversion. - The first is that its centralized model / server is not suitable for distributed development between independent parties. This limitation can be mostly worked around by using git-svn for interfacing with the server, and doing the rest of the development with git exclusively (ie. structuring / rebasing patch series locally, formatting them, sending them, applying or fetching them for testing and review, and so on). - The second problem is that the svn toolset (what developers use) is much inferior to git's. Since an SVN clone does not have full local history (independently of every other SVN clone in the world), tools that are crucial for development, like "git rebase", simply don't exist with "svn". This has a very bad effect on the patches that get posted to edk2-devel by direct users of "svn". In order to lay out a feature as a patchset, in small steps that are hopefully easy to understand for reviewers, I usually rebase a patchset, locally, several tens of times, before posting it the very first time. This entire *mindset* is nonexistent with "svn" users (because it is impossible to implement with "svn"). This has extremely negative consequences for the patches that get posted and committed. One cannot really appreciate the difference that git (the toolset) makes until one learns to use it. (It was the same for me, before I learned git, there's no doubt about it.) Summary: - the svn toolset dictates horrible development practices; we need to get rid of it universally, for all aspects of public development - the SVN repository as "primary commit store" works acceptably (with the git-svn utility) Thanks Laszlo ------------------------------------------------------------------------------ _______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
