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" <aa...@aaronballman.com> wrote: > On Wed, Jun 1, 2016 at 3:25 PM, James Y Knight <jykni...@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-...@lists.llvm.org> wrote: > >> > >> On Wed, Jun 1, 2016 at 2:18 PM, Renato Golin via llvm-dev > >> <llvm-...@lists.llvm.org> wrote: > >> > On 1 June 2016 at 17:02, John Criswell <jtcris...@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-...@lists.llvm.org > >> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev > > > > >
_______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
