IMO, if we're switching to git, we should just be clear up front that all committers will be expected to switch to git as well -- or at least, if they want to use something else (e.g. mercurial's git bridge/etc), that it's their own problem. It is truly NOT that big an imposition to require the use of git. And knowing how to use git at at least a basic level is an important skill for a lot of software development now -- no matter what LLVM does, so I don't feel bad for making anyone spend time learning how to use it. I really don't think that promising and requiring that svn-client using people (especially committers: read-only access seems a lot less potentially problematic) will keep getting a good development experience after the migration is a good idea. I mean, if SVN also happens to work with the chosen hosting/workflow in the end, that's fine, I guess. But, I feel that should be considered a "if it works, that's okay, but it's not recommended, and is not guaranteed" kind of thing. Making that a requirement locks us into the use of github as the primary repository: no other git hosting has svn support, afaik. It means we can't introduce any workflows that wouldn't work well for svn users -- or if we do, that such users will probably complain anew when that happens. And if github's svn bridge turns out to have fatal problems, do we then abandon the migration? On Wed, Jun 1, 2016 at 2:36 PM, Aaron Ballman via cfe-dev < cfe-dev at lists.llvm.org> wrote:> On Wed, Jun 1, 2016 at 2:18 PM, Renato Golin via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > On 1 June 2016 at 17:02, John Criswell <jtcriswel at gmail.com> wrote: > >> Do you have a set of volunteers lined up to do such a migration? Getting > >> people willing to do the migration will obviously be key, and that was > the > >> one thing I didn't see in the original email. > > > > Hi John, > > > > Well, first we need to know if people are in favour, then if the > > migration won't bring any serious problem, and then we can think of a > > migration plan. :) > > > > So far, it seems people are mostly in favour, with a few that reported > > being locked into SVN. I had anticipated that, and have proposed > > GitHub's SVN integration, which allows read-write access, so it should > > be mostly ok. We need more tests on that side to be sure, though. > > > > The biggest problem we're facing right now is how to sync the repos. > > The existing llvm-repos format with all projects as sub-modules seem > > to be a good candidate, but I still haven't seen a consensus on how > > we'd do that. > > > > About the migration plan, most people seem to agree a step-by-step > > process is necessary. So, first we move to git-only, possibly with > > sub-modules, > > Despite people's reservations of a git-only repository? I mean, we > still don't know that this will even work for people who wish to stay > with SVN. I am really not comfortable with this decision based on "it > should be mostly ok" from above, but maybe I am misunderstanding > something. > > ~Aaron > _______________________________________________ > cfe-dev mailing list > cfe-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160601/fbf1a9d0/attachment.html>
On Wed, Jun 1, 2016 at 3:25 PM, James Y Knight <jyknight at google.com> wrote:> IMO, if we're switching to git, we should just be clear up front that all > committers will be expected to switch to git as well -- or at least, if they > want to use something else (e.g. mercurial's git bridge/etc), that it's > their own problem.So anyone still using svn should not expect it to work? That sounds like a great way to alienate (at least some) active contributors. However, I do agree that clarity would be nice regarding whether the decision to switch to git has been "finalized" or not.> It is truly NOT that big an imposition to require the use of git.One thing to keep in mind is how well supported the tools are for the platforms we have contributors actively developing on. As a data point, I'm on Windows. Last time I tried using TortoiseGit (which admittedly was over a year ago), it was not ready for production use due to crashes with simple operations. On the other hand, TortoiseSVN works very well. While I can certainly make use of the command line, I don't predominately live in one like others might on non-Windows systems. So yes, it may be an imposition to require the use of git. I've not used the git integration in MSVC, so I can't speak to how well that may work with a project as complex as ours (perhaps someone else has experience and can speak to it), but that may also be a viable alternative for those of us on Windows that are already using MSVC. Other GUI alternatives may also exist that I'm simply unaware of.> And knowing how to use git at at least a basic level is an important skill for a > lot of software development now -- no matter what LLVM does, so I don't feel > bad for making anyone spend time learning how to use it. > > I really don't think that promising and requiring that svn-client using > people (especially committers: read-only access seems a lot less potentially > problematic) will keep getting a good development experience after the > migration is a good idea. I mean, if SVN also happens to work with the > chosen hosting/workflow in the end, that's fine, I guess. But, I feel that > should be considered a "if it works, that's okay, but it's not recommended, > and is not guaranteed" kind of thing.I'm uncomfortable with the idea of jettisoning SVN entirely right out of the gate. ~Aaron> Making that a requirement locks us into the use of github as the primary > repository: no other git hosting has svn support, afaik. > It means we can't introduce any workflows that wouldn't work well for svn > users -- or if we do, that such users will probably complain anew when that > happens. > And if github's svn bridge turns out to have fatal problems, do we then > abandon the migration? > > > > On Wed, Jun 1, 2016 at 2:36 PM, Aaron Ballman via cfe-dev > <cfe-dev at lists.llvm.org> wrote: >> >> On Wed, Jun 1, 2016 at 2:18 PM, Renato Golin via llvm-dev >> <llvm-dev at lists.llvm.org> wrote: >> > On 1 June 2016 at 17:02, John Criswell <jtcriswel at gmail.com> wrote: >> >> Do you have a set of volunteers lined up to do such a migration? >> >> Getting >> >> people willing to do the migration will obviously be key, and that was >> >> the >> >> one thing I didn't see in the original email. >> > >> > Hi John, >> > >> > Well, first we need to know if people are in favour, then if the >> > migration won't bring any serious problem, and then we can think of a >> > migration plan. :) >> > >> > So far, it seems people are mostly in favour, with a few that reported >> > being locked into SVN. I had anticipated that, and have proposed >> > GitHub's SVN integration, which allows read-write access, so it should >> > be mostly ok. We need more tests on that side to be sure, though. >> > >> > The biggest problem we're facing right now is how to sync the repos. >> > The existing llvm-repos format with all projects as sub-modules seem >> > to be a good candidate, but I still haven't seen a consensus on how >> > we'd do that. >> > >> > About the migration plan, most people seem to agree a step-by-step >> > process is necessary. So, first we move to git-only, possibly with >> > sub-modules, >> >> Despite people's reservations of a git-only repository? I mean, we >> still don't know that this will even work for people who wish to stay >> with SVN. I am really not comfortable with this decision based on "it >> should be mostly ok" from above, but maybe I am misunderstanding >> something. >> >> ~Aaron >> _______________________________________________ >> cfe-dev mailing list >> cfe-dev at lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev > >
I think we should start two other threads: one about git tooling on Windows and one about infrastructure problems migrating to git. I'm confident we can solve both problems relatively easily. Cheers, Renato On 1 Jun 2016 10:09 p.m., "Aaron Ballman" <aaron at aaronballman.com> wrote:> On Wed, Jun 1, 2016 at 3:25 PM, James Y Knight <jyknight at google.com> > wrote: > > IMO, if we're switching to git, we should just be clear up front that all > > committers will be expected to switch to git as well -- or at least, if > they > > want to use something else (e.g. mercurial's git bridge/etc), that it's > > their own problem. > > So anyone still using svn should not expect it to work? That sounds > like a great way to alienate (at least some) active contributors. > However, I do agree that clarity would be nice regarding whether the > decision to switch to git has been "finalized" or not. > > > It is truly NOT that big an imposition to require the use of git. > > One thing to keep in mind is how well supported the tools are for the > platforms we have contributors actively developing on. As a data > point, I'm on Windows. Last time I tried using TortoiseGit (which > admittedly was over a year ago), it was not ready for production use > due to crashes with simple operations. On the other hand, TortoiseSVN > works very well. While I can certainly make use of the command line, I > don't predominately live in one like others might on non-Windows > systems. So yes, it may be an imposition to require the use of git. > > I've not used the git integration in MSVC, so I can't speak to how > well that may work with a project as complex as ours (perhaps someone > else has experience and can speak to it), but that may also be a > viable alternative for those of us on Windows that are already using > MSVC. Other GUI alternatives may also exist that I'm simply unaware > of. > > > And knowing how to use git at at least a basic level is an important > skill for a > > lot of software development now -- no matter what LLVM does, so I don't > feel > > bad for making anyone spend time learning how to use it. > > > > I really don't think that promising and requiring that svn-client using > > people (especially committers: read-only access seems a lot less > potentially > > problematic) will keep getting a good development experience after the > > migration is a good idea. I mean, if SVN also happens to work with the > > chosen hosting/workflow in the end, that's fine, I guess. But, I feel > that > > should be considered a "if it works, that's okay, but it's not > recommended, > > and is not guaranteed" kind of thing. > > I'm uncomfortable with the idea of jettisoning SVN entirely right out > of the gate. > > ~Aaron > > > Making that a requirement locks us into the use of github as the primary > > repository: no other git hosting has svn support, afaik. > > It means we can't introduce any workflows that wouldn't work well for svn > > users -- or if we do, that such users will probably complain anew when > that > > happens. > > And if github's svn bridge turns out to have fatal problems, do we then > > abandon the migration? > > > > > > > > On Wed, Jun 1, 2016 at 2:36 PM, Aaron Ballman via cfe-dev > > <cfe-dev at lists.llvm.org> wrote: > >> > >> On Wed, Jun 1, 2016 at 2:18 PM, Renato Golin via llvm-dev > >> <llvm-dev at lists.llvm.org> wrote: > >> > On 1 June 2016 at 17:02, John Criswell <jtcriswel at gmail.com> wrote: > >> >> Do you have a set of volunteers lined up to do such a migration? > >> >> Getting > >> >> people willing to do the migration will obviously be key, and that > was > >> >> the > >> >> one thing I didn't see in the original email. > >> > > >> > Hi John, > >> > > >> > Well, first we need to know if people are in favour, then if the > >> > migration won't bring any serious problem, and then we can think of a > >> > migration plan. :) > >> > > >> > So far, it seems people are mostly in favour, with a few that reported > >> > being locked into SVN. I had anticipated that, and have proposed > >> > GitHub's SVN integration, which allows read-write access, so it should > >> > be mostly ok. We need more tests on that side to be sure, though. > >> > > >> > The biggest problem we're facing right now is how to sync the repos. > >> > The existing llvm-repos format with all projects as sub-modules seem > >> > to be a good candidate, but I still haven't seen a consensus on how > >> > we'd do that. > >> > > >> > About the migration plan, most people seem to agree a step-by-step > >> > process is necessary. So, first we move to git-only, possibly with > >> > sub-modules, > >> > >> Despite people's reservations of a git-only repository? I mean, we > >> still don't know that this will even work for people who wish to stay > >> with SVN. I am really not comfortable with this decision based on "it > >> should be mostly ok" from above, but maybe I am misunderstanding > >> something. > >> > >> ~Aaron > >> _______________________________________________ > >> cfe-dev mailing list > >> cfe-dev at lists.llvm.org > >> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev > > > > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160601/af8c0562/attachment.html>