directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kiran Ayyagari <kayyag...@apache.org>
Subject Re: Git ?
Date Fri, 27 Jun 2014 11:02:19 GMT
On Fri, Jun 27, 2014 at 2:31 PM, Emmanuel Lécharny <elecharny@gmail.com>
wrote:

> Le 27/06/2014 09:41, Pierre-Arnaud Marcelot a écrit :
> > On 26 Jun 2014, at 20:41, Stefan Seelmann <mail@stefan-seelmann.de>
> 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

Mime
View raw message