On Wed, Jun 17, 2015 at 2:38 AM, Laszlo Ersek <ler...@redhat.com> wrote: > 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?)
Yes, this would be my strong preference as well. Either we move to a single git repo as the primary repository, or we keep svn. Moving to git with anything other than a single git repo as the primary repository is a big step backwards. > > 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. Agreed. Now that I understand how the SVN edk2 repository is used internally at Intel (and maybe other places), I actually think that the SVN repository as master, with an officially supported git mirror, is the best technical solution for the diverse requirement set that the various users of the repository have. Git just doesn't support the company internal use cases as well as Subversion does. The only people who need to care that SVN is the master are those with commit access - the maintainers. I would expect that all community development will happen based on the git repository, and I think this should be recommended by the project. The usage of SVN as the primary repository becomes an implementation detail to the community at large. > >> 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. I also rebase patches many times before they are suitable for submission, and more times based on feedback after submission. I can't imagine doing this with Subversion. > > 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 ------------------------------------------------------------------------------ _______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
