On Jul 25, 2011, at 3:22 PM, Jason Kim wrote:> On Sun, Jul 24, 2011 at 9:54 AM, FlyLanguage <flylanguage at gmail.com> wrote: > Lot of good points. > > > Yep, switching to git would require a lot of work on the project > > maintainers' side. Commit hooks, setting up repositories, rewording > > policies in terms of the commands of the new tools, and that only to > > regain the status the project already has - [...] > > All of which could be done on a mirror, with pushes to svn during the > transition. Once it can be treated as the "official mainline", turn off > svn. If it turn out ugly, keep svn. > > Forcing transitioning to git makes no sense for a lot of us - for example, we have lots of scripts that depend on svn revision numbers - all those could be redone for git, but who wants to do work that they don't have to? What "problem" is it solving? > > Besides, the git-svn readonly bridge is a great solution for those who want to use git - While I agree that dvcs is better (I use mercurial AND git internally), I just don't see the rationale for forcing those who have adopted svn to their workflow to go through a disruptive switch.Great point. A potential conversion to git should be motivated by its benefits - assuming no development policy change - and that benefit needs to be greater than the various costs of conversion. -Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110725/c0f4fca5/attachment.html>
Chris Lattner <clattner at apple.com> writes:> On Jul 25, 2011, at 3:22 PM, Jason Kim wrote:> Great point. A potential conversion to git should be motivated by its > benefits - assuming no development policy change - and that benefit > needs to be greater than the various costs of conversion.Here are the most important benefits I see for the LLVM projects: - git greatly simplifies the work for groups that want to keep a private repository for internal development but eventually want to move that code to the public repository. Right now, there is NO tool support for doing this. It is a royal pain. - git allows different groups to share a codebase outside of master/upstream. Think of two academic research groups who want to explore a new transformation but don't want that work pushed to the public until it's done and published. This kind of development has no support whatsoever in svn. - git provides a set of tools built-in to interact with the submit patch -> review -> update patch -> submit patch iterative process. I'm thinking mainly things like git send-email, git rebase -i and git add -i. - git allows easy backtracking of decision points, allowing one to explore a line of development and then reformulate the set of commits made before actually sending them upstream to master. For me, it is more helpful to be able to just code up a feature and once it's working, go back and break out the individual patch sets into logical groups. I tend to poorly anticipate how a feature/fix should be presented to upstream before I've actually implemented it. git decouples those two activities. -Dave
On 7/28/11 4:40 PM, David A. Greene wrote:> Chris Lattner<clattner at apple.com> writes: > >> On Jul 25, 2011, at 3:22 PM, Jason Kim wrote: >> Great point. A potential conversion to git should be motivated by its >> benefits - assuming no development policy change - and that benefit >> needs to be greater than the various costs of conversion. > Here are the most important benefits I see for the LLVM projects: > > - git greatly simplifies the work for groups that want to keep a private > repository for internal development but eventually want to move that > code to the public repository. Right now, there is NO tool support > for doing this. It is a royal pain. > > - git allows different groups to share a codebase outside of > master/upstream. Think of two academic research groups who want to > explore a new transformation but don't want that work pushed to the > public until it's done and published. This kind of development has no > support whatsoever in svn.Just to offer an alternative perspective on the above point, I suspect that one of the reasons why maintaining out-of-tree code is such a pain is because people are adding their passes into LLVM instead of using the LLVM projects system. For those unfamiliar with it, the LLVM projects system allows external software source trees to link into LLVM's build system. Source code in the project uses LLVM header files and libraries just like in-tree code, and project Makefiles look nearly identical to LLVM's Makefiles. The whole purpose of the project system is to allow people to write their own LLVM passes in their own source trees (which, of course, can live in its own revision control system) as if they were writing in-tree code. Moving code from a project into LLVM shouldn't be terribly difficult, especially if you write it so that the code is within the llvm namespace and you create a local include/llvm tree for header files (aside: we didn't do this for SAFECode, which made the SAFECode patch to LLVM more difficult than necessary to create. Live and learn). The projects system is used extensively here at Illinois (the publicly available SAFECode and Poolalloc projects use it, and we have another three internal projects using it) and is documented at http://llvm.org/docs/Projects.html. I think the main drawback of the projects system is that it doesn't work for modifications of LLVM (including core LLVM changes, changes to existing transforms, and code-generator changes). However, for writing transform/analysis passes and LLVM-based tools, it works fine. -- John T.> > - git provides a set of tools built-in to interact with the submit patch > -> review -> update patch -> submit patch iterative process. I'm > thinking mainly things like git send-email, git rebase -i and git add -i. > > - git allows easy backtracking of decision points, allowing one to > explore a line of development and then reformulate the set of commits > made before actually sending them upstream to master. For me, it is > more helpful to be able to just code up a feature and once it's > working, go back and break out the individual patch sets into logical > groups. I tend to poorly anticipate how a feature/fix should be > presented to upstream before I've actually implemented it. git > decouples those two activities. > > -Dave > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> - git allows easy backtracking of decision points, allowing one to > explore a line of development and then reformulate the set of commits > made before actually sending them upstream to master. For me, it is > more helpful to be able to just code up a feature and once it's > working, go back and break out the individual patch sets into logical > groups. I tend to poorly anticipate how a feature/fix should be > presented to upstream before I've actually implemented it. git > decouples those two activities.This is actually one of the major points why I'm in the process of moving my own (LLVM-unrelated) development process from svn to git. Currently, I tend to break out small incremental changes to they're easier to review, but this works only up to a certain point. What happens is that I find I need some "enabler" change. Adding a data structure to carry enough context to the place where my new code needs it. The other thing is "sideline work": while reviewing code for my change, I find something unrelated that should really be fixed right away. Low-hanging fruit and such. I commit enablers and sideline changes, but I find I can't do so if there is already main-task work done in that file. With git, I can single out individual changes in a file and send them off as a preparatory commit. With SVN, I have to set up a separate workdir, start the IDE, do the change, and commit it; then merge it back into my mainline workdir. That's so much more work that it disrupts the flow of work, so I don't do it and end with a jumble of unrelated changes in a single patch. Anybody I'd be sending the patch to would probably reject it as "too many unrelated changes". I'd probably end up redoing any change twice: once just to get a clean base, then doing it "right" as a series of individually applicable small patches. Which is raising the entry barrier for contributing to LLVM considerably. At least for people with a workflow similar to mine.