On Fri, Jun 27, 2014 at 2:31 PM, Emmanuel Lécharny <[email protected]> wrote:
> Le 27/06/2014 09:41, Pierre-Arnaud Marcelot a écrit : > > On 26 Jun 2014, at 20:41, Stefan Seelmann <[email protected]> > wrote: > > > >> On 06/26/2014 06:35 PM, Emmanuel Lécharny wrote: > >>> Hi guys, > >>> > >>> since the inception of the project, we are using Subversion (well, at > >>> the very begining, it was on CVS). We are all used to it, but I'm quite > >>> sure that most of us are also using Git on a side project. > >>> > >>> I'm a bit fed up of switching from Git to Svn, and back. I work a few > >>> weeks using SVN, then when I come back to Git, I have to read the doco > >>> again, because I don't remember all the fancy commands to use it > >>> efficiently. The very same things after a few weeks using Git. > >>> > >>> What about moving the full project to git ? Do you think it would be > too > >>> much of a pain ? > >>> > >> I'm ok with it, but I can also live with svn. > > Same for me. > > Although I’m working more on Git these days, I’m still comfortable with > SVN. > > > ya, still in my SVN comfort zone, but am ok with the move to git > >> If we move we need to discuss the repo structure. Should we put the > >> whole svn into a single git repo (I think no) or create a git repo per > >> subproject (yes IMHO)? > > +1 for me too. > > > I would favor more than one repo. > > +1 for more than one repo > > > > >> We have many subprojects now (shared/api, > >> mavibot, jdbm, server, studio, escimo) which deserve its own git repo. > >> What about the smaller repos (parent-project, buildtools (is this still > >> required?) clients). > both ldap and kerberos clients are internally used in the tests so I suggest we keep them where they are i.e in shared and apacheds modules > >> I think sandbox and deceased don't need to be > >> migrated, as SVN will still be available read-only. > > +1. Sounds reasonable too me. > > +1 > > +1 > > > >> I have a small concern regarding the studio repo, as it includes > >> binaries from various Eclipse versions, the .git directory of the > >> current git-mirror is 700 MB. That means when cloning the studio git > >> repo on has to download the full 700 MB. > > That’s indeed a big concern. I’d be tempted to have that in another > repository, that we can even use online as a real maven repository. > > Without requiring us to have it checked out on our computers. > > Would Tycho solve this issue ? > > Otherwise, we can probably avoid migrating all the history, in order to > avoid loading hundreds of megabytes. > > In any case, at some point, we should find a way to access to those bins > by other means than having them in SVN. This is just overkilling. > > setting up Studio workspace is already complicated(I have recently tried but it is taking more time to setup than the time it took to implement a fix, so my fix is still lying there waiting to be tested) so -1 to move Studio to git until we find a solution to keep the binary jars out of the repo. > > > >> Other things to consider (not a complete list) > >> * Is there a mailing list integration for commits > >> * Maven release should work with git, update of <scm> section in POMs is > >> required > >> * Is there are a git alternative to viewvc, or just use github instead? > > +1 on those questions. > > Mina has move to git a few years (months) ago I guess, Emmanuel, are all > these things available yet? > > - We have ML integrations for commits > - Maven release works just fine with Git > - you can check the previous commits : > https://git-wip-us.apache.org/repos/asf?p=mina.git;a=summary > > > -- Kiran Ayyagari http://keydap.com
