You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Jason van Zyl <ja...@tesla.io> on 2012/09/04 21:55:27 UTC
Git as the canonical SCM
How's Git doing at Apache these days?
Anyone interested in pursuing putting Maven in Git as the canonical SCM?
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder & CTO, Sonatype
Founder, Apache Maven
http://twitter.com/jvanzyl
---------------------------------------------------------
To do two things at once is to do neither.
-- Publilius Syrus, Roman slave, first century B.C.
Re: Git as the canonical SCM
Posted by Dennis Lundberg <de...@apache.org>.
On 2012-09-04 22:10, Dennis Lundberg wrote:
> On 2012-09-04 21:55, Jason van Zyl wrote:
>> How's Git doing at Apache these days?
>
> A pilot was started some time ago, with a few volunteering projects. I
> have heard anything about its progress in a while. I'll ask over @infra
> and report back here.
It seems that it's not yet ready [1] for prime time.
[1] https://git-wip-us.apache.org/docs/switching-to-git.html
>> Anyone interested in pursuing putting Maven in Git as the canonical SCM?
>>
>> Thanks,
>>
>> Jason
>>
>> ----------------------------------------------------------
>> Jason van Zyl
>> Founder & CTO, Sonatype
>> Founder, Apache Maven
>> http://twitter.com/jvanzyl
>> ---------------------------------------------------------
>>
>> To do two things at once is to do neither.
>>
>> -- Publilius Syrus, Roman slave, first century B.C.
>>
>>
>>
>>
>>
>>
>
>
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Git as the canonical SCM
Posted by Dennis Lundberg <de...@apache.org>.
On 2012-09-04 21:55, Jason van Zyl wrote:
> How's Git doing at Apache these days?
A pilot was started some time ago, with a few volunteering projects. I
have heard anything about its progress in a while. I'll ask over @infra
and report back here.
> Anyone interested in pursuing putting Maven in Git as the canonical SCM?
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder & CTO, Sonatype
> Founder, Apache Maven
> http://twitter.com/jvanzyl
> ---------------------------------------------------------
>
> To do two things at once is to do neither.
>
> -- Publilius Syrus, Roman slave, first century B.C.
>
>
>
>
>
>
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Git as the canonical SCM
Posted by Chris Graham <ch...@gmail.com>.
I have no desire to keep a copy of the entire repo locally.
>From what I can see, the current SVN is well managed and well understood. I
see little value in changing, other than to pander to the current fad in
scm.
-Chris
On Wed, Sep 5, 2012 at 5:55 AM, Jason van Zyl <ja...@tesla.io> wrote:
> How's Git doing at Apache these days?
>
> Anyone interested in pursuing putting Maven in Git as the canonical SCM?
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder & CTO, Sonatype
> Founder, Apache Maven
> http://twitter.com/jvanzyl
> ---------------------------------------------------------
>
> To do two things at once is to do neither.
>
> -- Publilius Syrus, Roman slave, first century B.C.
>
>
>
>
>
>
Re: Git as the canonical SCM
Posted by Kristian Rosenvold <kr...@gmail.com>.
And, as I commented in
https://cwiki.apache.org/confluence/display/MAVEN/Scheme+for+managing+Maven+source+in+Git,
I think we're perfectly happy just to keep the current module
structure. There may be some opportunities related to changing it, but
I think most of us can agree on just keeping up the existing top-level
modules. (Some of the current asf git clones are not good, but that's
a different issue)
So at the end of the day, most of this discussion is really about if
we can be even smarter ;) And sorry for insulting cvs users out there,
I feel your pain.
Kristian
2012/9/6 Kristian Rosenvold <kr...@gmail.com>:
> 2012/9/6 Chris Graham <ch...@gmail.com>:
>> The fact that a lot of people have said +1 and there are still discussions
>> around how to best set up a repo, means to me, that there is lots more room
>> for dissussion.
>
> We have a hundred projects or more ;) A substantial group of people
> here have been through extensive git migrations, so we know the basic moves.
> I know it can be hard to distinguish when we're discussing nitty-gritty details
> from hugely important issues, since most of the time we're not being very clear
> about this (and we always discuss as if it's vitally important ;).
>
> I think it's safe to expect that we'll be going through a few
> alternatives for some
> of the projects. And migrating everything is probably a quite long story.
>
> Kristian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Git as the canonical SCM
Posted by Kristian Rosenvold <kr...@gmail.com>.
2012/9/6 Chris Graham <ch...@gmail.com>:
> The fact that a lot of people have said +1 and there are still discussions
> around how to best set up a repo, means to me, that there is lots more room
> for dissussion.
We have a hundred projects or more ;) A substantial group of people
here have been through extensive git migrations, so we know the basic moves.
I know it can be hard to distinguish when we're discussing nitty-gritty details
from hugely important issues, since most of the time we're not being very clear
about this (and we always discuss as if it's vitally important ;).
I think it's safe to expect that we'll be going through a few
alternatives for some
of the projects. And migrating everything is probably a quite long story.
Kristian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Git as the canonical SCM
Posted by Chris Graham <ch...@gmail.com>.
Has anyone stopped to ask any other projects (both apache and non-apache)
who have done what is being proposed here:
- How they found it?
- What did they do well?
- What did they do poorly?
- What pain points did they have?
- What would they do differently, if they had to do it again?
- What benefits did they receive?
- Did the expected benfits match the results?
(just to name a few questions off of the top of my head, I'm sure that
there are others).
Effectively, a PIR of a project that has already gone this route.
The fact that a lot of people have said +1 and there are still discussions
around how to best set up a repo, means to me, that there is lots more room
for dissussion.
-Chris
On Thu, Sep 6, 2012 at 3:30 PM, David Jencks <da...@yahoo.com> wrote:
>
> On Sep 5, 2012, at 10:08 PM, Kristian Rosenvold wrote:
>
> > 2012/9/5 Romain Manni-Bucau <rm...@gmail.com>:
> >> Last note: i think the plugin you speak about (create a kind of virtual
> >> project) will be a nightmare. Scm are nice but can be broken and when
> you
> >> dont have a 1:1 with remote repo it is even harder
> >
> > I would really like some elaboration on this, since I'm not sure I
> > understand what
> > you're trying to say. I work with the maven codebase
> > all the time and I generally find working with layered components that
> are
> > from different release modules to be a little painful although
> > manageable. Most of this pain does
> > /not/ stem from the fact that they are in different version control
> systems
> > or different checkouts from the version control system (which they are).
>
> I think from my experience that your proposed plugin is sort of essential
> for working with maven code. I usually give up quickly because I can't
> find all the dependencies that some plugin I want to improve uses in a
> finite amount of time.
>
> However, I wonder how useful it will be on projects with more separation
> between interface and implementation, as in some osgi projects. If you
> have a module AIntf with interfaces and then the implementations in AImpl
> and project B uses AIntf how do you know to check out AImpl? (or the
> several AImpls). I'd love to see this work....
>
> >
> > I like to think there are a few main use cases for checking out code:
> > A) I want to fix a single problem/issue and when I'm done with that
> > I'm going to submit a patch and get on with my life.
> > B) I'm hooked. I fix things in a limited subset of the code base all
> > the time. So I need to keep it recent, fresh and patched.
> > C) I'm all over the place. I do global updates to dependencies and
> > reformat code like there's no tomorrow.
> >
> > I think these are the three models we need to support well. I think
> > especially A is important, since it's the
> > gateway to entry ;)
>
> I like this division.
>
> And BTW as a very occasional maven patcher and git user elsewhere I think
> git would be an improvement over svn.
>
> thanks!
> david jencks
>
> >
> > Kristian
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Git as the canonical SCM
Posted by David Jencks <da...@yahoo.com>.
On Sep 5, 2012, at 10:08 PM, Kristian Rosenvold wrote:
> 2012/9/5 Romain Manni-Bucau <rm...@gmail.com>:
>> Last note: i think the plugin you speak about (create a kind of virtual
>> project) will be a nightmare. Scm are nice but can be broken and when you
>> dont have a 1:1 with remote repo it is even harder
>
> I would really like some elaboration on this, since I'm not sure I
> understand what
> you're trying to say. I work with the maven codebase
> all the time and I generally find working with layered components that are
> from different release modules to be a little painful although
> manageable. Most of this pain does
> /not/ stem from the fact that they are in different version control systems
> or different checkouts from the version control system (which they are).
I think from my experience that your proposed plugin is sort of essential for working with maven code. I usually give up quickly because I can't find all the dependencies that some plugin I want to improve uses in a finite amount of time.
However, I wonder how useful it will be on projects with more separation between interface and implementation, as in some osgi projects. If you have a module AIntf with interfaces and then the implementations in AImpl and project B uses AIntf how do you know to check out AImpl? (or the several AImpls). I'd love to see this work....
>
> I like to think there are a few main use cases for checking out code:
> A) I want to fix a single problem/issue and when I'm done with that
> I'm going to submit a patch and get on with my life.
> B) I'm hooked. I fix things in a limited subset of the code base all
> the time. So I need to keep it recent, fresh and patched.
> C) I'm all over the place. I do global updates to dependencies and
> reformat code like there's no tomorrow.
>
> I think these are the three models we need to support well. I think
> especially A is important, since it's the
> gateway to entry ;)
I like this division.
And BTW as a very occasional maven patcher and git user elsewhere I think git would be an improvement over svn.
thanks!
david jencks
>
> Kristian
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Git as the canonical SCM
Posted by Kristian Rosenvold <kr...@gmail.com>.
2012/9/5 Romain Manni-Bucau <rm...@gmail.com>:
> Last note: i think the plugin you speak about (create a kind of virtual
> project) will be a nightmare. Scm are nice but can be broken and when you
> dont have a 1:1 with remote repo it is even harder
I would really like some elaboration on this, since I'm not sure I
understand what
you're trying to say. I work with the maven codebase
all the time and I generally find working with layered components that are
from different release modules to be a little painful although
manageable. Most of this pain does
/not/ stem from the fact that they are in different version control systems
or different checkouts from the version control system (which they are).
I like to think there are a few main use cases for checking out code:
A) I want to fix a single problem/issue and when I'm done with that
I'm going to submit a patch and get on with my life.
B) I'm hooked. I fix things in a limited subset of the code base all
the time. So I need to keep it recent, fresh and patched.
C) I'm all over the place. I do global updates to dependencies and
reformat code like there's no tomorrow.
I think these are the three models we need to support well. I think
especially A is important, since it's the
gateway to entry ;)
Kristian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Git as the canonical SCM
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Im not a mvn community member but use if everyday and would like to share
my thought about this thread: "don't make sthg trivial hard"
Git is awesome for the purpose it was created.
In this thread there are several issues not all linked to the scm
Last note: i think the plugin you speak about (create a kind of virtual
project) will be a nightmare. Scm are nice but can be broken and when you
dont have a 1:1 with remote repo it is even harder
Just my thoughts...
Le 5 sept. 2012 20:54, "Kristian Rosenvold" <kr...@gmail.com>
a écrit :
> 2012/9/5 Mark Struberg <st...@yahoo.de>:
> > Well, I consider myself a git black-belt user as well (I even wrote
> parts of the german man pages).
> I know you are ;)
>
> > Let's just consider we will abandon some old plugin because we replaced
> it with a much better approach. In SVN you just create a branch for
> maintenance and delete the plugin from trunk. Nobody will see this obsolete
> plugin if he checks out the trunk. But in GIT you still have the repo
> around. And for knowing which ones are in use and which aren't anymore you
> would need to clone all of them.
> >
> > There are 2 use cases when maintaining plugins:
> > 1.) a plugin specific fix
> > 2.) a cross-cutting fix which concerns many plugins (upgrade of
> technologies, introducing a new pattern, etc)
> >
> > Especially for 2.) it would become _much_ harder to do this properly as
> you cannot easily make sure that you checked all plugins!
>
> I think the concerns you raise are legit and reasonable, but a switch
> also opens a lot of new posssibilities.
>
> You seem to be assuming we keep everything else as-is and not change
> too much documentation or the way we document stuff? As I mentioned
> earlier today, make a plugin that checks out the entire dependency
> tree and create a project for you. Or how about something as brutally
> simple as a large page of "git clone" statements lined up in a
> copy-pasteable manner that will clone every single repo in the
> codebase nicely side by side? We could even make a plugin to do it and
> auto-generate a pom.xml that'll load everything ;) The plugin that
> checks out the entire depth of the dependency sources could offer to
> roll all checked out dependencies to snapshot mode to facilitate
> super-easy access to making changes across the board....[I seem to be
> boling with different ideas in this topic today]
>
> You also seem to be assuming that the current svn setup is easy for
> users wishing to take a simple dive into some bug they want to fix or
> some feature they want to add. I'll add my 5c that the current
> dependency structure in maven (and high modularization) has you in a
> hell-hole of checkouts long before you even *reach* the plexus-jungle.
> I remember this very clearly from the first time I started checking
> out maven sources. There's no end to the stuff, and it's not easily
> accessible to a beginner.
>
> Of course, now I'm familiar with the jungle ;)
>
> Kristian
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Git as the canonical SCM
Posted by Kristian Rosenvold <kr...@gmail.com>.
2012/9/5 Mark Struberg <st...@yahoo.de>:
> Well, I consider myself a git black-belt user as well (I even wrote parts of the german man pages).
I know you are ;)
> Let's just consider we will abandon some old plugin because we replaced it with a much better approach. In SVN you just create a branch for maintenance and delete the plugin from trunk. Nobody will see this obsolete plugin if he checks out the trunk. But in GIT you still have the repo around. And for knowing which ones are in use and which aren't anymore you would need to clone all of them.
>
> There are 2 use cases when maintaining plugins:
> 1.) a plugin specific fix
> 2.) a cross-cutting fix which concerns many plugins (upgrade of technologies, introducing a new pattern, etc)
>
> Especially for 2.) it would become _much_ harder to do this properly as you cannot easily make sure that you checked all plugins!
I think the concerns you raise are legit and reasonable, but a switch
also opens a lot of new posssibilities.
You seem to be assuming we keep everything else as-is and not change
too much documentation or the way we document stuff? As I mentioned
earlier today, make a plugin that checks out the entire dependency
tree and create a project for you. Or how about something as brutally
simple as a large page of "git clone" statements lined up in a
copy-pasteable manner that will clone every single repo in the
codebase nicely side by side? We could even make a plugin to do it and
auto-generate a pom.xml that'll load everything ;) The plugin that
checks out the entire depth of the dependency sources could offer to
roll all checked out dependencies to snapshot mode to facilitate
super-easy access to making changes across the board....[I seem to be
boling with different ideas in this topic today]
You also seem to be assuming that the current svn setup is easy for
users wishing to take a simple dive into some bug they want to fix or
some feature they want to add. I'll add my 5c that the current
dependency structure in maven (and high modularization) has you in a
hell-hole of checkouts long before you even *reach* the plexus-jungle.
I remember this very clearly from the first time I started checking
out maven sources. There's no end to the stuff, and it's not easily
accessible to a beginner.
Of course, now I'm familiar with the jungle ;)
Kristian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Git as the canonical SCM
Posted by Mark Struberg <st...@yahoo.de>.
Well, I consider myself a git black-belt user as well (I even wrote parts of the german man pages).
But the problems I explained mostly happens to users which do not have that much GIT foo.
It's just pretty easy to mess up a repo with git pull (especially when using --rebase or core.autorebase=true)
Anyway, my main concern is how to effectively slice up the repos without having tons of unnecessary repos lying around at the end of the day. Because that is exactly what happened to a few projects I know!
Let's just consider we will abandon some old plugin because we replaced it with a much better approach. In SVN you just create a branch for maintenance and delete the plugin from trunk. Nobody will see this obsolete plugin if he checks out the trunk. But in GIT you still have the repo around. And for knowing which ones are in use and which aren't anymore you would need to clone all of them.
There are 2 use cases when maintaining plugins:
1.) a plugin specific fix
2.) a cross-cutting fix which concerns many plugins (upgrade of technologies, introducing a new pattern, etc)
Especially for 2.) it would become _much_ harder to do this properly as you cannot easily make sure that you checked all plugins!
LieGrue,
strub
----- Original Message -----
> From: Kristian Rosenvold <kr...@gmail.com>
> To: Maven Developers List <de...@maven.apache.org>; Mark Struberg <st...@yahoo.de>
> Cc:
> Sent: Wednesday, September 5, 2012 2:32 PM
> Subject: Re: Git as the canonical SCM
>
> While I'm sure it's academically interesting, I'm not sure if this
> discussion is all that relevant for practical purposes. We
> adapt/optimize for the technologies we use, and in moving to git I'm
> quite convinced anything other than 1 release unit = 1 repo is
> suboptimal. All the chit-chat about sparse checkouts is basically how
> to live with suboptimal repos, and there is really no good reason why
> we should choose to do that.
>
> As for your considerations on mixed merge/rebase workflows, you're
> describing some hard cases that are quite far from beginners workflow
> that require decent understanding of how things work. I work daily
> with multiple remotes (apache/github) merges and rebases and I hardly
> even think about it. But then again I'm probably a black belt user.
> I'm not going to scare off beginners about the wonders of rebasing
> merge commits because it is a problem they shouldnt be running into.
>
> Kristian
>
> 2012/9/5 Mark Struberg <st...@yahoo.de>:
>>> No longer true, git has sparse checkout support (I believe since
> 1.7.0).
>>
>> I hear this argument over and over again, and it is still wrong!
>>
>>
>> The sparse checkout support is only fragmentaric at least! It's for
> sure not comparable with the sparse checkout features of SVN. I'd rather
> call it 'farce checkout' :)
>>
>> Try creating a sparse branch
>> Try creating a sparse tag
>> Try getting multiple sparse checkouts at the same time
>>
>>
>> git is good, but it it's basic design decisions does not fit to all
> project setups.
>> E.g. GIT is still primarily intended for only pushing to your own repo. Try
> to do a git merge and later rebase of a concurring merge conflict. You will end
> up with all commits duplicated in the history...
>>
>> LieGrue,
>> strub
>>
>>
>>
>> ----- Original Message -----
>>> From: Stanislav Ochotnicky <so...@redhat.com>
>>> To: Maven Developers List <de...@maven.apache.org>
>>> Cc:
>>> Sent: Wednesday, September 5, 2012 9:51 AM
>>> Subject: Re: Git as the canonical SCM
>>>
>>> Quoting Olivier Lamy (2012-09-04 22:23:11)
>>> ...
>>>> Due to lack of support of sparse checkout in git, I (perso)
> don't want
>>>> we have to create a git repo per plugin etc...
>>>> IMHO That will be a pain to manage.
>>>
>>> No longer true, git has sparse checkout support (I believe since
> 1.7.0).
>>> See http://git-scm.com/docs/git-read-tree.html (search for Sparse
>>> checkout section). There are multiple examples spread through the
>>> interwebs, one would be:
>>>
> http://jasonkarns.com/blog/subdirectory-checkouts-with-git-sparse-checkout/
>>>
>>> And there's always shallow clones which are fine for sending
>>> format-patch(es).
>>>
>>> That said, the code should IMHO be split into repositories depending on
>>> their releases (i.e. code that gets releases simultaneously should be
> in
>>> one repo, code that has multiple parts which get their own release tags
>>> should be in separate repos)
>>>
>>> --
>>> Stanislav Ochotnicky <so...@redhat.com>
>>> Software Engineer - Base Operating Systems Brno
>>>
>>> PGP: 7B087241
>>> Red Hat Inc. http://cz.redhat.com
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Git as the canonical SCM
Posted by Kristian Rosenvold <kr...@gmail.com>.
While I'm sure it's academically interesting, I'm not sure if this
discussion is all that relevant for practical purposes. We
adapt/optimize for the technologies we use, and in moving to git I'm
quite convinced anything other than 1 release unit = 1 repo is
suboptimal. All the chit-chat about sparse checkouts is basically how
to live with suboptimal repos, and there is really no good reason why
we should choose to do that.
As for your considerations on mixed merge/rebase workflows, you're
describing some hard cases that are quite far from beginners workflow
that require decent understanding of how things work. I work daily
with multiple remotes (apache/github) merges and rebases and I hardly
even think about it. But then again I'm probably a black belt user.
I'm not going to scare off beginners about the wonders of rebasing
merge commits because it is a problem they shouldnt be running into.
Kristian
2012/9/5 Mark Struberg <st...@yahoo.de>:
>> No longer true, git has sparse checkout support (I believe since 1.7.0).
>
> I hear this argument over and over again, and it is still wrong!
>
>
> The sparse checkout support is only fragmentaric at least! It's for sure not comparable with the sparse checkout features of SVN. I'd rather call it 'farce checkout' :)
>
> Try creating a sparse branch
> Try creating a sparse tag
> Try getting multiple sparse checkouts at the same time
>
>
> git is good, but it it's basic design decisions does not fit to all project setups.
> E.g. GIT is still primarily intended for only pushing to your own repo. Try to do a git merge and later rebase of a concurring merge conflict. You will end up with all commits duplicated in the history...
>
> LieGrue,
> strub
>
>
>
> ----- Original Message -----
>> From: Stanislav Ochotnicky <so...@redhat.com>
>> To: Maven Developers List <de...@maven.apache.org>
>> Cc:
>> Sent: Wednesday, September 5, 2012 9:51 AM
>> Subject: Re: Git as the canonical SCM
>>
>> Quoting Olivier Lamy (2012-09-04 22:23:11)
>> ...
>>> Due to lack of support of sparse checkout in git, I (perso) don't want
>>> we have to create a git repo per plugin etc...
>>> IMHO That will be a pain to manage.
>>
>> No longer true, git has sparse checkout support (I believe since 1.7.0).
>> See http://git-scm.com/docs/git-read-tree.html (search for Sparse
>> checkout section). There are multiple examples spread through the
>> interwebs, one would be:
>> http://jasonkarns.com/blog/subdirectory-checkouts-with-git-sparse-checkout/
>>
>> And there's always shallow clones which are fine for sending
>> format-patch(es).
>>
>> That said, the code should IMHO be split into repositories depending on
>> their releases (i.e. code that gets releases simultaneously should be in
>> one repo, code that has multiple parts which get their own release tags
>> should be in separate repos)
>>
>> --
>> Stanislav Ochotnicky <so...@redhat.com>
>> Software Engineer - Base Operating Systems Brno
>>
>> PGP: 7B087241
>> Red Hat Inc. http://cz.redhat.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Git as the canonical SCM
Posted by Mark Struberg <st...@yahoo.de>.
> No longer true, git has sparse checkout support (I believe since 1.7.0).
I hear this argument over and over again, and it is still wrong!
The sparse checkout support is only fragmentaric at least! It's for sure not comparable with the sparse checkout features of SVN. I'd rather call it 'farce checkout' :)
Try creating a sparse branch
Try creating a sparse tag
Try getting multiple sparse checkouts at the same time
git is good, but it it's basic design decisions does not fit to all project setups.
E.g. GIT is still primarily intended for only pushing to your own repo. Try to do a git merge and later rebase of a concurring merge conflict. You will end up with all commits duplicated in the history...
LieGrue,
strub
----- Original Message -----
> From: Stanislav Ochotnicky <so...@redhat.com>
> To: Maven Developers List <de...@maven.apache.org>
> Cc:
> Sent: Wednesday, September 5, 2012 9:51 AM
> Subject: Re: Git as the canonical SCM
>
> Quoting Olivier Lamy (2012-09-04 22:23:11)
> ...
>> Due to lack of support of sparse checkout in git, I (perso) don't want
>> we have to create a git repo per plugin etc...
>> IMHO That will be a pain to manage.
>
> No longer true, git has sparse checkout support (I believe since 1.7.0).
> See http://git-scm.com/docs/git-read-tree.html (search for Sparse
> checkout section). There are multiple examples spread through the
> interwebs, one would be:
> http://jasonkarns.com/blog/subdirectory-checkouts-with-git-sparse-checkout/
>
> And there's always shallow clones which are fine for sending
> format-patch(es).
>
> That said, the code should IMHO be split into repositories depending on
> their releases (i.e. code that gets releases simultaneously should be in
> one repo, code that has multiple parts which get their own release tags
> should be in separate repos)
>
> --
> Stanislav Ochotnicky <so...@redhat.com>
> Software Engineer - Base Operating Systems Brno
>
> PGP: 7B087241
> Red Hat Inc. http://cz.redhat.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Git as the canonical SCM
Posted by Stanislav Ochotnicky <so...@redhat.com>.
Quoting Olivier Lamy (2012-09-04 22:23:11)
...
> Due to lack of support of sparse checkout in git, I (perso) don't want
> we have to create a git repo per plugin etc...
> IMHO That will be a pain to manage.
No longer true, git has sparse checkout support (I believe since 1.7.0).
See http://git-scm.com/docs/git-read-tree.html (search for Sparse
checkout section). There are multiple examples spread through the
interwebs, one would be:
http://jasonkarns.com/blog/subdirectory-checkouts-with-git-sparse-checkout/
And there's always shallow clones which are fine for sending
format-patch(es).
That said, the code should IMHO be split into repositories depending on
their releases (i.e. code that gets releases simultaneously should be in
one repo, code that has multiple parts which get their own release tags
should be in separate repos)
--
Stanislav Ochotnicky <so...@redhat.com>
Software Engineer - Base Operating Systems Brno
PGP: 7B087241
Red Hat Inc. http://cz.redhat.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Git as the canonical SCM
Posted by Arnaud Héritier <ah...@gmail.com>.
jenkins does it (1 plugin = 1 repo ) and I sincerely see no solution
to avoid that.
Each plugin or each lib has its own lifecycle and requires to have its
own git repo to be clean
That's why on jenkins we have the IRC bot to manage them
But it is easier on github because they provide many APIs to do such
remote management.
On ASF side I don't think we'll have soon such tooling :(
On the other hand the only annoying thing to do its the conversion
itself and then to update projects (SCM ...). After that we could ask
to sync them on github and we can easily provide some script to clone
all repos from a given organisation. Unlike Jenkins we don't have a
flow of repos creation really important on ASF side.
My 2 cents.
Arnaud
On Tue, Sep 4, 2012 at 10:23 PM, Olivier Lamy <ol...@apache.org> wrote:
> 2012/9/4 Andrew Waterman <aw...@ecosur.mx>:
>> The drools guys did a really nice move from Subversion a few years back.
>>
>> http://blog.athico.com/2010/12/drools-migrated-to-git.html
>>
>> One of the key things they did, was reorganize their poms and project structure.
>>
>> I'd be willing to help out. I think there could be a lot more to this move than just importing from subversion, but it depends on what you guys want to do.
>
> Yup I agree.
> I use git on other oss projects (Apache: cloudstack and non Apache:
> jenkins ...) and git svn for some asf projects.
> Due to lack of support of sparse checkout in git, I (perso) don't want
> we have to create a git repo per plugin etc...
> IMHO That will be a pain to manage.
>
>>
>> best wishes,
>>
>> Andrew
>>
>> On Sep 4, 2012, at 3:09 PM, "Jason Pyeron" <jp...@pdinc.us> wrote:
>>
>>>> -----Original Message-----
>>>> From: Jason van Zyl
>>>> Sent: Tuesday, September 04, 2012 15:55
>>>>
>>>> How's Git doing at Apache these days?
>>>>
>>>> Anyone interested in pursuing putting Maven in Git as the
>>>> canonical SCM?
>>>
>>> Comments from the peanut gallery: It would make it very nice to contribute back.
>>> Since I do not have a sandbox access I have thrown away fixes because there was
>>> no efficient way to track them until they were accepted as patches. (same
>>> problem in struts, commons, ...)
>>>
>>> We would be very happy here at PD Inc if that was done.
>>>
>>> -Jason Pyeron
>>>
>>> --
>>> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>>> - -
>>> - Jason Pyeron PD Inc. http://www.pdinc.us -
>>> - Principal Consultant 10 West 24th Street #100 -
>>> - +1 (443) 269-1555 x333 Baltimore, Maryland 21218 -
>>> - -
>>> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>>> This message is copyright PD Inc, subject to license 20080407P00.
>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>
>
>
>
> --
> Olivier Lamy
> Talend: http://coders.talend.com
> http://twitter.com/olamy | http://linkedin.com/in/olamy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
--
-----
Arnaud Héritier
06-89-76-64-24
http://aheritier.net
Mail/GTalk: aheritier@gmail.com
Twitter/Skype : aheritier
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Git as the canonical SCM
Posted by Jason van Zyl <ja...@tesla.io>.
+1
All reasonable, and we can certainly try it with a few repos people are interested.
On Sep 5, 2012, at 3:31 AM, Kristian Rosenvold wrote:
> I think we should move to git; probably starting with a few
> repositories. I will not go into the argument as to why (it's been
> covered like a zillion times, link by Andrew covers a lot of it),
> other than to mention that the immense ease of moving around in
> history means that I never have to consider a patch "stale" since I
> can easily review it at the point in history it was created;
> additionally there's a much-improved chance I can move this to the top
> of history without being stale)
>
> Basically I've been meaning to start av vote suggesting that we:
>
> 1) Decide to move *all* maven projects to git, time frame subject to
> project/asf/infra capacity. We're in no immense hurry.
> 2) Kick off the effort by moving 2-3 projects initially, 1-2 easy ones
> (just to get the general feel for how things work) and a hard one.
> Right now I'd suggest something like m3-core, surefire( or scm) and
> maven-plugins, the last being the hard one ;)
>
> I herby volunteer to do the donkey-work, including some massive
> filter-branch operations on the current asf maven-plugins git clone.
>
> I think we should split maven-plugins, because I think the solution
> chosen is optimized for the wrong uses cases, and it only helps for
> setting up CI jobs. The rest of the community basically has no value
> in the current set-up.
>
> Which makes me think we should consider such a switch an opportunity
> to re-think some of our tooling
> around multi-module projects. What the 99% others want (who're not
> setting up a CI) is a checkout algorithm that builds the *vertical*
> stack for a given plugin, not the horizontal top-level stack for all
> the plugins (which is what we have currently). So if I checkout
> "maven-ear-plugin", I would basically want something like this:
> root-dir\
> maven-ear-plugin\
> maven-archiver\
> maven-filtering\
> plexus-archiver\
> plexus-utils
> .. maybe more.. (probably configurable somewhere)
>
> Now if the checkout would generate a synethetic parent pom with all
> these as modules, I could just load it all up in IDEA and be ready to
> go. I think something like this would have /real/ value to most of our
> users, whereas the current maven-plugins layout really only is
> valuable for whoever is configuring a CI to build maven-plugins.
>
> No matter what, I think there's very lfew practical use cases for
> having all the modules chunked together.
>
> Kristian
>
>
> 2012/9/4 Olivier Lamy <ol...@apache.org>:
>> 2012/9/4 Andrew Waterman <aw...@ecosur.mx>:
>>> The drools guys did a really nice move from Subversion a few years back.
>>>
>>> http://blog.athico.com/2010/12/drools-migrated-to-git.html
>>>
>>> One of the key things they did, was reorganize their poms and project structure.
>>>
>>> I'd be willing to help out. I think there could be a lot more to this move than just importing from subversion, but it depends on what you guys want to do.
>>
>> Yup I agree.
>> I use git on other oss projects (Apache: cloudstack and non Apache:
>> jenkins ...) and git svn for some asf projects.
>> Due to lack of support of sparse checkout in git, I (perso) don't want
>> we have to create a git repo per plugin etc...
>> IMHO That will be a pain to manage.
>>
>>>
>>> best wishes,
>>>
>>> Andrew
>>>
>>> On Sep 4, 2012, at 3:09 PM, "Jason Pyeron" <jp...@pdinc.us> wrote:
>>>
>>>>> -----Original Message-----
>>>>> From: Jason van Zyl
>>>>> Sent: Tuesday, September 04, 2012 15:55
>>>>>
>>>>> How's Git doing at Apache these days?
>>>>>
>>>>> Anyone interested in pursuing putting Maven in Git as the
>>>>> canonical SCM?
>>>>
>>>> Comments from the peanut gallery: It would make it very nice to contribute back.
>>>> Since I do not have a sandbox access I have thrown away fixes because there was
>>>> no efficient way to track them until they were accepted as patches. (same
>>>> problem in struts, commons, ...)
>>>>
>>>> We would be very happy here at PD Inc if that was done.
>>>>
>>>> -Jason Pyeron
>>>>
>>>> --
>>>> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>>>> - -
>>>> - Jason Pyeron PD Inc. http://www.pdinc.us -
>>>> - Principal Consultant 10 West 24th Street #100 -
>>>> - +1 (443) 269-1555 x333 Baltimore, Maryland 21218 -
>>>> - -
>>>> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>>>> This message is copyright PD Inc, subject to license 20080407P00.
>>>>
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>
>>
>>
>>
>> --
>> Olivier Lamy
>> Talend: http://coders.talend.com
>> http://twitter.com/olamy | http://linkedin.com/in/olamy
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder & CTO, Sonatype
Founder, Apache Maven
http://twitter.com/jvanzyl
---------------------------------------------------------
A man enjoys his work when he understands the whole and when he
is responsible for the quality of the whole
-- Christopher Alexander, A Pattern Language
Re: Git as the canonical SCM
Posted by Olivier Lamy <ol...@apache.org>.
2012/9/5 Kristian Rosenvold <kr...@gmail.com>:
> I think we should move to git; probably starting with a few
> repositories. I will not go into the argument as to why (it's been
> covered like a zillion times, link by Andrew covers a lot of it),
Yes we must avoid such buzz/troll to save our 'reading importants
emails' time :-) as we are sure git is a nice scm.
And this topic has been already enough discussed here it's time to
move forward on that !
I personally use only git (git svn for Apache).
And for sure using native git will save some of my cpu cycles and
network bandwidth :-) (git push or git fetch / rebase will be
certainly better than git svn dcommit or git svn rebase).
> other than to mention that the immense ease of moving around in
> history means that I never have to consider a patch "stale" since I
> can easily review it at the point in history it was created;
> additionally there's a much-improved chance I can move this to the top
> of history without being stale)
>
> Basically I've been meaning to start av vote suggesting that we:
>
> 1) Decide to move *all* maven projects to git, time frame subject to
> project/asf/infra capacity. We're in no immense hurry.
> 2) Kick off the effort by moving 2-3 projects initially, 1-2 easy ones
> (just to get the general feel for how things work) and a hard one.
> Right now I'd suggest something like m3-core, surefire( or scm) and
> maven-plugins, the last being the hard one ;)
ASF infra ask volunteers from TLP projects which want to use git to
help on infra tasks related to git admin.
Perso I can but as I won't have enough cycles I'd like to see an other
volunteer. Kristian ?
IMHO we must start with maven-3 to improve participation from others
as it looks to be the goal and that will do more marketing/buzz than
moving scm or wagon :-).
I can start the vote (maybe a vote with a majority of +1 from committers)
>
> I herby volunteer to do the donkey-work, including some massive
> filter-branch operations on the current asf maven-plugins git clone.
Cool !
>
> I think we should split maven-plugins, because I think the solution
> chosen is optimized for the wrong uses cases, and it only helps for
> setting up CI jobs. The rest of the community basically has no value
> in the current set-up.
Yup but that's more easy to maintain than a ton of jenkins jobs
>
> Which makes me think we should consider such a switch an opportunity
> to re-think some of our tooling
> around multi-module projects. What the 99% others want (who're not
> setting up a CI) is a checkout algorithm that builds the *vertical*
> stack for a given plugin, not the horizontal top-level stack for all
> the plugins (which is what we have currently). So if I checkout
> "maven-ear-plugin", I would basically want something like this:
> root-dir\
> maven-ear-plugin\
> maven-archiver\
> maven-filtering\
> plexus-archiver\
> plexus-utils
> .. maybe more.. (probably configurable somewhere)
>
> Now if the checkout would generate a synethetic parent pom with all
> these as modules, I could just load it all up in IDEA and be ready to
> go. I think something like this would have /real/ value to most of our
> users, whereas the current maven-plugins layout really only is
> valuable for whoever is configuring a CI to build maven-plugins.
That's a good idea !!
What about a maven plugin for that ? :-)
checkout/clone your project then mvn sources:checkout-dependencies (or
clone-dependencies :-) ).
The plugin could have a look at dependencies scm section and if exists
checkout/clone the sources locally (we have all the necessary
components for that)
>
> No matter what, I think there's very lfew practical use cases for
> having all the modules chunked together.
>
> Kristian
>
>
> 2012/9/4 Olivier Lamy <ol...@apache.org>:
>> 2012/9/4 Andrew Waterman <aw...@ecosur.mx>:
>>> The drools guys did a really nice move from Subversion a few years back.
>>>
>>> http://blog.athico.com/2010/12/drools-migrated-to-git.html
>>>
>>> One of the key things they did, was reorganize their poms and project structure.
>>>
>>> I'd be willing to help out. I think there could be a lot more to this move than just importing from subversion, but it depends on what you guys want to do.
>>
>> Yup I agree.
>> I use git on other oss projects (Apache: cloudstack and non Apache:
>> jenkins ...) and git svn for some asf projects.
>> Due to lack of support of sparse checkout in git, I (perso) don't want
>> we have to create a git repo per plugin etc...
>> IMHO That will be a pain to manage.
>>
>>>
>>> best wishes,
>>>
>>> Andrew
>>>
>>> On Sep 4, 2012, at 3:09 PM, "Jason Pyeron" <jp...@pdinc.us> wrote:
>>>
>>>>> -----Original Message-----
>>>>> From: Jason van Zyl
>>>>> Sent: Tuesday, September 04, 2012 15:55
>>>>>
>>>>> How's Git doing at Apache these days?
>>>>>
>>>>> Anyone interested in pursuing putting Maven in Git as the
>>>>> canonical SCM?
>>>>
>>>> Comments from the peanut gallery: It would make it very nice to contribute back.
>>>> Since I do not have a sandbox access I have thrown away fixes because there was
>>>> no efficient way to track them until they were accepted as patches. (same
>>>> problem in struts, commons, ...)
>>>>
>>>> We would be very happy here at PD Inc if that was done.
>>>>
>>>> -Jason Pyeron
>>>>
>>>> --
>>>> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>>>> - -
>>>> - Jason Pyeron PD Inc. http://www.pdinc.us -
>>>> - Principal Consultant 10 West 24th Street #100 -
>>>> - +1 (443) 269-1555 x333 Baltimore, Maryland 21218 -
>>>> - -
>>>> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>>>> This message is copyright PD Inc, subject to license 20080407P00.
>>>>
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>
>>
>>
>>
>> --
>> Olivier Lamy
>> Talend: http://coders.talend.com
>> http://twitter.com/olamy | http://linkedin.com/in/olamy
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
--
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Git as the canonical SCM
Posted by Tamás Cservenák <ta...@cservenak.net>.
+1000
and don't forget one of the simplest: maven-indexer
(my guts always tremble when I need to dcommit there, due to stupid eu/us
git-svn problems....) :D
Thanks,
~t~
On Wed, Sep 5, 2012 at 11:41 AM, Arnaud Héritier <ah...@gmail.com>wrote:
> +1 to do it step by step
> The conversion is "easy" for projects having already a dedicated
> trunk/tags/branches entry in SVN
> It will be less funny for plugins but possible.
> I'm also in favor to split per project/lifecycle even if it is creating a
> lot of repositories
> The problem to loose the plugins reactor is for me a problem only for CI
> and it may be the opportunity for us to think to add the feature of modules
> described per GAV and automatically checked out from the SCM :-)
> For the ability for a developer to clone all repo (an operation we are
> doing only once) we may have a shell script or something like that if we
> don't have something better from infra side. (or we clone their copies from
> github and its easy with few lines of ruby or something like that)
>
> Cheers,
>
> On Wed, Sep 5, 2012 at 9:31 AM, Kristian Rosenvold <
> kristian.rosenvold@gmail.com> wrote:
>
> > I think we should move to git; probably starting with a few
> > repositories. I will not go into the argument as to why (it's been
> > covered like a zillion times, link by Andrew covers a lot of it),
> > other than to mention that the immense ease of moving around in
> > history means that I never have to consider a patch "stale" since I
> > can easily review it at the point in history it was created;
> > additionally there's a much-improved chance I can move this to the top
> > of history without being stale)
> >
> > Basically I've been meaning to start av vote suggesting that we:
> >
> > 1) Decide to move *all* maven projects to git, time frame subject to
> > project/asf/infra capacity. We're in no immense hurry.
> > 2) Kick off the effort by moving 2-3 projects initially, 1-2 easy ones
> > (just to get the general feel for how things work) and a hard one.
> > Right now I'd suggest something like m3-core, surefire( or scm) and
> > maven-plugins, the last being the hard one ;)
> >
> > I herby volunteer to do the donkey-work, including some massive
> > filter-branch operations on the current asf maven-plugins git clone.
> >
> > I think we should split maven-plugins, because I think the solution
> > chosen is optimized for the wrong uses cases, and it only helps for
> > setting up CI jobs. The rest of the community basically has no value
> > in the current set-up.
> >
> > Which makes me think we should consider such a switch an opportunity
> > to re-think some of our tooling
> > around multi-module projects. What the 99% others want (who're not
> > setting up a CI) is a checkout algorithm that builds the *vertical*
> > stack for a given plugin, not the horizontal top-level stack for all
> > the plugins (which is what we have currently). So if I checkout
> > "maven-ear-plugin", I would basically want something like this:
> > root-dir\
> > maven-ear-plugin\
> > maven-archiver\
> > maven-filtering\
> > plexus-archiver\
> > plexus-utils
> > .. maybe more.. (probably configurable somewhere)
> >
> > Now if the checkout would generate a synethetic parent pom with all
> > these as modules, I could just load it all up in IDEA and be ready to
> > go. I think something like this would have /real/ value to most of our
> > users, whereas the current maven-plugins layout really only is
> > valuable for whoever is configuring a CI to build maven-plugins.
> >
> > No matter what, I think there's very lfew practical use cases for
> > having all the modules chunked together.
> >
> > Kristian
> >
> >
> > 2012/9/4 Olivier Lamy <ol...@apache.org>:
> > > 2012/9/4 Andrew Waterman <aw...@ecosur.mx>:
> > >> The drools guys did a really nice move from Subversion a few years
> back.
> > >>
> > >> http://blog.athico.com/2010/12/drools-migrated-to-git.html
> > >>
> > >> One of the key things they did, was reorganize their poms and project
> > structure.
> > >>
> > >> I'd be willing to help out. I think there could be a lot more to this
> > move than just importing from subversion, but it depends on what you guys
> > want to do.
> > >
> > > Yup I agree.
> > > I use git on other oss projects (Apache: cloudstack and non Apache:
> > > jenkins ...) and git svn for some asf projects.
> > > Due to lack of support of sparse checkout in git, I (perso) don't want
> > > we have to create a git repo per plugin etc...
> > > IMHO That will be a pain to manage.
> > >
> > >>
> > >> best wishes,
> > >>
> > >> Andrew
> > >>
> > >> On Sep 4, 2012, at 3:09 PM, "Jason Pyeron" <jp...@pdinc.us> wrote:
> > >>
> > >>>> -----Original Message-----
> > >>>> From: Jason van Zyl
> > >>>> Sent: Tuesday, September 04, 2012 15:55
> > >>>>
> > >>>> How's Git doing at Apache these days?
> > >>>>
> > >>>> Anyone interested in pursuing putting Maven in Git as the
> > >>>> canonical SCM?
> > >>>
> > >>> Comments from the peanut gallery: It would make it very nice to
> > contribute back.
> > >>> Since I do not have a sandbox access I have thrown away fixes because
> > there was
> > >>> no efficient way to track them until they were accepted as patches.
> > (same
> > >>> problem in struts, commons, ...)
> > >>>
> > >>> We would be very happy here at PD Inc if that was done.
> > >>>
> > >>> -Jason Pyeron
> > >>>
> > >>> --
> > >>> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> > >>> - -
> > >>> - Jason Pyeron PD Inc. http://www.pdinc.us -
> > >>> - Principal Consultant 10 West 24th Street #100 -
> > >>> - +1 (443) 269-1555 x333 Baltimore, Maryland 21218 -
> > >>> - -
> > >>> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> > >>> This message is copyright PD Inc, subject to license 20080407P00.
> > >>>
> > >>>
> > >>>
> > >>>
> > >>> ---------------------------------------------------------------------
> > >>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > >>> For additional commands, e-mail: dev-help@maven.apache.org
> > >>>
> > >>
> > >
> > >
> > >
> > > --
> > > Olivier Lamy
> > > Talend: http://coders.talend.com
> > > http://twitter.com/olamy | http://linkedin.com/in/olamy
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
>
> --
> -----
> Arnaud Héritier
> 06-89-76-64-24
> http://aheritier.net
> Mail/GTalk: aheritier@gmail.com
> Twitter/Skype : aheritier
>
Re: Git as the canonical SCM
Posted by Arnaud Héritier <ah...@gmail.com>.
+1 to do it step by step
The conversion is "easy" for projects having already a dedicated
trunk/tags/branches entry in SVN
It will be less funny for plugins but possible.
I'm also in favor to split per project/lifecycle even if it is creating a
lot of repositories
The problem to loose the plugins reactor is for me a problem only for CI
and it may be the opportunity for us to think to add the feature of modules
described per GAV and automatically checked out from the SCM :-)
For the ability for a developer to clone all repo (an operation we are
doing only once) we may have a shell script or something like that if we
don't have something better from infra side. (or we clone their copies from
github and its easy with few lines of ruby or something like that)
Cheers,
On Wed, Sep 5, 2012 at 9:31 AM, Kristian Rosenvold <
kristian.rosenvold@gmail.com> wrote:
> I think we should move to git; probably starting with a few
> repositories. I will not go into the argument as to why (it's been
> covered like a zillion times, link by Andrew covers a lot of it),
> other than to mention that the immense ease of moving around in
> history means that I never have to consider a patch "stale" since I
> can easily review it at the point in history it was created;
> additionally there's a much-improved chance I can move this to the top
> of history without being stale)
>
> Basically I've been meaning to start av vote suggesting that we:
>
> 1) Decide to move *all* maven projects to git, time frame subject to
> project/asf/infra capacity. We're in no immense hurry.
> 2) Kick off the effort by moving 2-3 projects initially, 1-2 easy ones
> (just to get the general feel for how things work) and a hard one.
> Right now I'd suggest something like m3-core, surefire( or scm) and
> maven-plugins, the last being the hard one ;)
>
> I herby volunteer to do the donkey-work, including some massive
> filter-branch operations on the current asf maven-plugins git clone.
>
> I think we should split maven-plugins, because I think the solution
> chosen is optimized for the wrong uses cases, and it only helps for
> setting up CI jobs. The rest of the community basically has no value
> in the current set-up.
>
> Which makes me think we should consider such a switch an opportunity
> to re-think some of our tooling
> around multi-module projects. What the 99% others want (who're not
> setting up a CI) is a checkout algorithm that builds the *vertical*
> stack for a given plugin, not the horizontal top-level stack for all
> the plugins (which is what we have currently). So if I checkout
> "maven-ear-plugin", I would basically want something like this:
> root-dir\
> maven-ear-plugin\
> maven-archiver\
> maven-filtering\
> plexus-archiver\
> plexus-utils
> .. maybe more.. (probably configurable somewhere)
>
> Now if the checkout would generate a synethetic parent pom with all
> these as modules, I could just load it all up in IDEA and be ready to
> go. I think something like this would have /real/ value to most of our
> users, whereas the current maven-plugins layout really only is
> valuable for whoever is configuring a CI to build maven-plugins.
>
> No matter what, I think there's very lfew practical use cases for
> having all the modules chunked together.
>
> Kristian
>
>
> 2012/9/4 Olivier Lamy <ol...@apache.org>:
> > 2012/9/4 Andrew Waterman <aw...@ecosur.mx>:
> >> The drools guys did a really nice move from Subversion a few years back.
> >>
> >> http://blog.athico.com/2010/12/drools-migrated-to-git.html
> >>
> >> One of the key things they did, was reorganize their poms and project
> structure.
> >>
> >> I'd be willing to help out. I think there could be a lot more to this
> move than just importing from subversion, but it depends on what you guys
> want to do.
> >
> > Yup I agree.
> > I use git on other oss projects (Apache: cloudstack and non Apache:
> > jenkins ...) and git svn for some asf projects.
> > Due to lack of support of sparse checkout in git, I (perso) don't want
> > we have to create a git repo per plugin etc...
> > IMHO That will be a pain to manage.
> >
> >>
> >> best wishes,
> >>
> >> Andrew
> >>
> >> On Sep 4, 2012, at 3:09 PM, "Jason Pyeron" <jp...@pdinc.us> wrote:
> >>
> >>>> -----Original Message-----
> >>>> From: Jason van Zyl
> >>>> Sent: Tuesday, September 04, 2012 15:55
> >>>>
> >>>> How's Git doing at Apache these days?
> >>>>
> >>>> Anyone interested in pursuing putting Maven in Git as the
> >>>> canonical SCM?
> >>>
> >>> Comments from the peanut gallery: It would make it very nice to
> contribute back.
> >>> Since I do not have a sandbox access I have thrown away fixes because
> there was
> >>> no efficient way to track them until they were accepted as patches.
> (same
> >>> problem in struts, commons, ...)
> >>>
> >>> We would be very happy here at PD Inc if that was done.
> >>>
> >>> -Jason Pyeron
> >>>
> >>> --
> >>> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> >>> - -
> >>> - Jason Pyeron PD Inc. http://www.pdinc.us -
> >>> - Principal Consultant 10 West 24th Street #100 -
> >>> - +1 (443) 269-1555 x333 Baltimore, Maryland 21218 -
> >>> - -
> >>> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> >>> This message is copyright PD Inc, subject to license 20080407P00.
> >>>
> >>>
> >>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>
> >>
> >
> >
> >
> > --
> > Olivier Lamy
> > Talend: http://coders.talend.com
> > http://twitter.com/olamy | http://linkedin.com/in/olamy
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
--
-----
Arnaud Héritier
06-89-76-64-24
http://aheritier.net
Mail/GTalk: aheritier@gmail.com
Twitter/Skype : aheritier
Re: Git as the canonical SCM
Posted by Barrie Treloar <ba...@gmail.com>.
On Wed, Sep 5, 2012 at 5:01 PM, Kristian Rosenvold
<kr...@gmail.com> wrote:
[del]
> Which makes me think we should consider such a switch an opportunity
> to re-think some of our tooling
> around multi-module projects. What the 99% others want (who're not
> setting up a CI) is a checkout algorithm that builds the *vertical*
> stack for a given plugin, not the horizontal top-level stack for all
> the plugins (which is what we have currently). So if I checkout
> "maven-ear-plugin", I would basically want something like this:
> root-dir\
> maven-ear-plugin\
> maven-archiver\
> maven-filtering\
> plexus-archiver\
> plexus-utils
> .. maybe more.. (probably configurable somewhere)
I've lost count of the times I've been bug hunting starting at the
plugin where the problem occurs and had to pull in dependencies until
I have found the problem.
Even if the repository doesn't allow this, tooling to help checkout as
you describe would be great.
Especially when things live in shared, plexus, plugins etc its a
manual PITA looking at poms for scm sections and then checking them
out.
At least a re-think of the structure would help in
understanding/explaining why things live where.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Git as the canonical SCM
Posted by Mark Struberg <st...@yahoo.de>.
Now apply this to maven-scm if you like to have a test object.
This sometimes gets built in one go, sometimes as single modules, ...
LieGrue,
strub
----- Original Message -----
> From: Kristian Rosenvold <kr...@gmail.com>
> To: Maven Developers List <de...@maven.apache.org>
> Cc:
> Sent: Wednesday, September 5, 2012 9:31 AM
> Subject: Re: Git as the canonical SCM
>
> I think we should move to git; probably starting with a few
> repositories. I will not go into the argument as to why (it's been
> covered like a zillion times, link by Andrew covers a lot of it),
> other than to mention that the immense ease of moving around in
> history means that I never have to consider a patch "stale" since I
> can easily review it at the point in history it was created;
> additionally there's a much-improved chance I can move this to the top
> of history without being stale)
>
> Basically I've been meaning to start av vote suggesting that we:
>
> 1) Decide to move *all* maven projects to git, time frame subject to
> project/asf/infra capacity. We're in no immense hurry.
> 2) Kick off the effort by moving 2-3 projects initially, 1-2 easy ones
> (just to get the general feel for how things work) and a hard one.
> Right now I'd suggest something like m3-core, surefire( or scm) and
> maven-plugins, the last being the hard one ;)
>
> I herby volunteer to do the donkey-work, including some massive
> filter-branch operations on the current asf maven-plugins git clone.
>
> I think we should split maven-plugins, because I think the solution
> chosen is optimized for the wrong uses cases, and it only helps for
> setting up CI jobs. The rest of the community basically has no value
> in the current set-up.
>
> Which makes me think we should consider such a switch an opportunity
> to re-think some of our tooling
> around multi-module projects. What the 99% others want (who're not
> setting up a CI) is a checkout algorithm that builds the *vertical*
> stack for a given plugin, not the horizontal top-level stack for all
> the plugins (which is what we have currently). So if I checkout
> "maven-ear-plugin", I would basically want something like this:
> root-dir\
> maven-ear-plugin\
> maven-archiver\
> maven-filtering\
> plexus-archiver\
> plexus-utils
> .. maybe more.. (probably configurable somewhere)
>
> Now if the checkout would generate a synethetic parent pom with all
> these as modules, I could just load it all up in IDEA and be ready to
> go. I think something like this would have /real/ value to most of our
> users, whereas the current maven-plugins layout really only is
> valuable for whoever is configuring a CI to build maven-plugins.
>
> No matter what, I think there's very lfew practical use cases for
> having all the modules chunked together.
>
> Kristian
>
>
> 2012/9/4 Olivier Lamy <ol...@apache.org>:
>> 2012/9/4 Andrew Waterman <aw...@ecosur.mx>:
>>> The drools guys did a really nice move from Subversion a few years
> back.
>>>
>>> http://blog.athico.com/2010/12/drools-migrated-to-git.html
>>>
>>> One of the key things they did, was reorganize their poms and project
> structure.
>>>
>>> I'd be willing to help out. I think there could be a lot more to
> this move than just importing from subversion, but it depends on what you guys
> want to do.
>>
>> Yup I agree.
>> I use git on other oss projects (Apache: cloudstack and non Apache:
>> jenkins ...) and git svn for some asf projects.
>> Due to lack of support of sparse checkout in git, I (perso) don't want
>> we have to create a git repo per plugin etc...
>> IMHO That will be a pain to manage.
>>
>>>
>>> best wishes,
>>>
>>> Andrew
>>>
>>> On Sep 4, 2012, at 3:09 PM, "Jason Pyeron"
> <jp...@pdinc.us> wrote:
>>>
>>>>> -----Original Message-----
>>>>> From: Jason van Zyl
>>>>> Sent: Tuesday, September 04, 2012 15:55
>>>>>
>>>>> How's Git doing at Apache these days?
>>>>>
>>>>> Anyone interested in pursuing putting Maven in Git as the
>>>>> canonical SCM?
>>>>
>>>> Comments from the peanut gallery: It would make it very nice to
> contribute back.
>>>> Since I do not have a sandbox access I have thrown away fixes
> because there was
>>>> no efficient way to track them until they were accepted as patches.
> (same
>>>> problem in struts, commons, ...)
>>>>
>>>> We would be very happy here at PD Inc if that was done.
>>>>
>>>> -Jason Pyeron
>>>>
>>>> --
>>>> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>>>> - -
>>>> - Jason Pyeron PD Inc. http://www.pdinc.us -
>>>> - Principal Consultant 10 West 24th Street #100 -
>>>> - +1 (443) 269-1555 x333 Baltimore, Maryland 21218 -
>>>> - -
>>>> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>>>> This message is copyright PD Inc, subject to license 20080407P00.
>>>>
>>>>
>>>>
>>>>
>>>>
> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>
>>
>>
>>
>> --
>> Olivier Lamy
>> Talend: http://coders.talend.com
>> http://twitter.com/olamy | http://linkedin.com/in/olamy
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Git as the canonical SCM
Posted by Kristian Rosenvold <kr...@gmail.com>.
I think we should move to git; probably starting with a few
repositories. I will not go into the argument as to why (it's been
covered like a zillion times, link by Andrew covers a lot of it),
other than to mention that the immense ease of moving around in
history means that I never have to consider a patch "stale" since I
can easily review it at the point in history it was created;
additionally there's a much-improved chance I can move this to the top
of history without being stale)
Basically I've been meaning to start av vote suggesting that we:
1) Decide to move *all* maven projects to git, time frame subject to
project/asf/infra capacity. We're in no immense hurry.
2) Kick off the effort by moving 2-3 projects initially, 1-2 easy ones
(just to get the general feel for how things work) and a hard one.
Right now I'd suggest something like m3-core, surefire( or scm) and
maven-plugins, the last being the hard one ;)
I herby volunteer to do the donkey-work, including some massive
filter-branch operations on the current asf maven-plugins git clone.
I think we should split maven-plugins, because I think the solution
chosen is optimized for the wrong uses cases, and it only helps for
setting up CI jobs. The rest of the community basically has no value
in the current set-up.
Which makes me think we should consider such a switch an opportunity
to re-think some of our tooling
around multi-module projects. What the 99% others want (who're not
setting up a CI) is a checkout algorithm that builds the *vertical*
stack for a given plugin, not the horizontal top-level stack for all
the plugins (which is what we have currently). So if I checkout
"maven-ear-plugin", I would basically want something like this:
root-dir\
maven-ear-plugin\
maven-archiver\
maven-filtering\
plexus-archiver\
plexus-utils
.. maybe more.. (probably configurable somewhere)
Now if the checkout would generate a synethetic parent pom with all
these as modules, I could just load it all up in IDEA and be ready to
go. I think something like this would have /real/ value to most of our
users, whereas the current maven-plugins layout really only is
valuable for whoever is configuring a CI to build maven-plugins.
No matter what, I think there's very lfew practical use cases for
having all the modules chunked together.
Kristian
2012/9/4 Olivier Lamy <ol...@apache.org>:
> 2012/9/4 Andrew Waterman <aw...@ecosur.mx>:
>> The drools guys did a really nice move from Subversion a few years back.
>>
>> http://blog.athico.com/2010/12/drools-migrated-to-git.html
>>
>> One of the key things they did, was reorganize their poms and project structure.
>>
>> I'd be willing to help out. I think there could be a lot more to this move than just importing from subversion, but it depends on what you guys want to do.
>
> Yup I agree.
> I use git on other oss projects (Apache: cloudstack and non Apache:
> jenkins ...) and git svn for some asf projects.
> Due to lack of support of sparse checkout in git, I (perso) don't want
> we have to create a git repo per plugin etc...
> IMHO That will be a pain to manage.
>
>>
>> best wishes,
>>
>> Andrew
>>
>> On Sep 4, 2012, at 3:09 PM, "Jason Pyeron" <jp...@pdinc.us> wrote:
>>
>>>> -----Original Message-----
>>>> From: Jason van Zyl
>>>> Sent: Tuesday, September 04, 2012 15:55
>>>>
>>>> How's Git doing at Apache these days?
>>>>
>>>> Anyone interested in pursuing putting Maven in Git as the
>>>> canonical SCM?
>>>
>>> Comments from the peanut gallery: It would make it very nice to contribute back.
>>> Since I do not have a sandbox access I have thrown away fixes because there was
>>> no efficient way to track them until they were accepted as patches. (same
>>> problem in struts, commons, ...)
>>>
>>> We would be very happy here at PD Inc if that was done.
>>>
>>> -Jason Pyeron
>>>
>>> --
>>> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>>> - -
>>> - Jason Pyeron PD Inc. http://www.pdinc.us -
>>> - Principal Consultant 10 West 24th Street #100 -
>>> - +1 (443) 269-1555 x333 Baltimore, Maryland 21218 -
>>> - -
>>> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>>> This message is copyright PD Inc, subject to license 20080407P00.
>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>
>
>
>
> --
> Olivier Lamy
> Talend: http://coders.talend.com
> http://twitter.com/olamy | http://linkedin.com/in/olamy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Git as the canonical SCM
Posted by Olivier Lamy <ol...@apache.org>.
2012/9/4 Andrew Waterman <aw...@ecosur.mx>:
> The drools guys did a really nice move from Subversion a few years back.
>
> http://blog.athico.com/2010/12/drools-migrated-to-git.html
>
> One of the key things they did, was reorganize their poms and project structure.
>
> I'd be willing to help out. I think there could be a lot more to this move than just importing from subversion, but it depends on what you guys want to do.
Yup I agree.
I use git on other oss projects (Apache: cloudstack and non Apache:
jenkins ...) and git svn for some asf projects.
Due to lack of support of sparse checkout in git, I (perso) don't want
we have to create a git repo per plugin etc...
IMHO That will be a pain to manage.
>
> best wishes,
>
> Andrew
>
> On Sep 4, 2012, at 3:09 PM, "Jason Pyeron" <jp...@pdinc.us> wrote:
>
>>> -----Original Message-----
>>> From: Jason van Zyl
>>> Sent: Tuesday, September 04, 2012 15:55
>>>
>>> How's Git doing at Apache these days?
>>>
>>> Anyone interested in pursuing putting Maven in Git as the
>>> canonical SCM?
>>
>> Comments from the peanut gallery: It would make it very nice to contribute back.
>> Since I do not have a sandbox access I have thrown away fixes because there was
>> no efficient way to track them until they were accepted as patches. (same
>> problem in struts, commons, ...)
>>
>> We would be very happy here at PD Inc if that was done.
>>
>> -Jason Pyeron
>>
>> --
>> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>> - -
>> - Jason Pyeron PD Inc. http://www.pdinc.us -
>> - Principal Consultant 10 West 24th Street #100 -
>> - +1 (443) 269-1555 x333 Baltimore, Maryland 21218 -
>> - -
>> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>> This message is copyright PD Inc, subject to license 20080407P00.
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
--
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Git as the canonical SCM
Posted by Jesse McConnell <je...@gmail.com>.
it is possible to have them all in one git repo and still release
separately, we do it in a toolchain repository in jetty and use maven
release plugin for it as well
so its not _required_ that you split it all up by choosing git
jesse
--
jesse mcconnell
jesse.mcconnell@gmail.com
On Tue, Sep 4, 2012 at 4:46 PM, Benson Margulies <bi...@gmail.com> wrote:
> On Tue, Sep 4, 2012 at 5:29 PM, Mark Struberg <st...@yahoo.de> wrote:
>> just take as example that you like to checkout all maven core plugins in one go because you like to do some refactoring/checks/upgrade.
>
> I see. So the fact that we have a single trunk in svn for all the
> plugins is the thing that isn't convenient in git.
>
>> That would require you to go into each plugin project and get the stuff from there. And where would you put the aggregator pom for CI and development builds?
>>
>> Same applies to all other projects which are kind of 'aggregator' like maven-core, shared, etc
>>
>>
>> LieGrue,
>> strub
>>
>>
>>
>> ----- Original Message -----
>>> From: Benson Margulies <bi...@gmail.com>
>>> To: Maven Developers List <de...@maven.apache.org>; Mark Struberg <st...@yahoo.de>
>>> Cc:
>>> Sent: Tuesday, September 4, 2012 11:18 PM
>>> Subject: Re: Git as the canonical SCM
>>>
>>> Mark, I disagree. Any group of modules that is released together can
>>> just have a git repo. What case do you have in mind where we'd need to
>>> fight with the git submodule madness?
>>>
>>> For others: if a project wants to move to git, the project must
>>> provide a <del>sacrificial victim</del> volunteer to help with git
>>> infrastructure.
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Git as the canonical SCM
Posted by Benson Margulies <bi...@gmail.com>.
On Tue, Sep 4, 2012 at 5:29 PM, Mark Struberg <st...@yahoo.de> wrote:
> just take as example that you like to checkout all maven core plugins in one go because you like to do some refactoring/checks/upgrade.
I see. So the fact that we have a single trunk in svn for all the
plugins is the thing that isn't convenient in git.
> That would require you to go into each plugin project and get the stuff from there. And where would you put the aggregator pom for CI and development builds?
>
> Same applies to all other projects which are kind of 'aggregator' like maven-core, shared, etc
>
>
> LieGrue,
> strub
>
>
>
> ----- Original Message -----
>> From: Benson Margulies <bi...@gmail.com>
>> To: Maven Developers List <de...@maven.apache.org>; Mark Struberg <st...@yahoo.de>
>> Cc:
>> Sent: Tuesday, September 4, 2012 11:18 PM
>> Subject: Re: Git as the canonical SCM
>>
>> Mark, I disagree. Any group of modules that is released together can
>> just have a git repo. What case do you have in mind where we'd need to
>> fight with the git submodule madness?
>>
>> For others: if a project wants to move to git, the project must
>> provide a <del>sacrificial victim</del> volunteer to help with git
>> infrastructure.
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Git as the canonical SCM
Posted by Hilco Wijbenga <hi...@gmail.com>.
On 4 September 2012 14:29, Mark Struberg <st...@yahoo.de> wrote:
> just take as example that you like to checkout all maven core plugins in one go because you like to do some refactoring/checks/upgrade.
> That would require you to go into each plugin project and get the stuff from there. And where would you put the aggregator pom for CI and development builds?
>
> Same applies to all other projects which are kind of 'aggregator' like maven-core, shared, etc
You might want to have a look at git subtree. While it's currently in
"contrib", it *is* distributed with Git (since 1.7.11).
Having said that, nothing is stopping you from simply using a single
Git repository. :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Git as the canonical SCM
Posted by Mark Struberg <st...@yahoo.de>.
just take as example that you like to checkout all maven core plugins in one go because you like to do some refactoring/checks/upgrade.
That would require you to go into each plugin project and get the stuff from there. And where would you put the aggregator pom for CI and development builds?
Same applies to all other projects which are kind of 'aggregator' like maven-core, shared, etc
LieGrue,
strub
----- Original Message -----
> From: Benson Margulies <bi...@gmail.com>
> To: Maven Developers List <de...@maven.apache.org>; Mark Struberg <st...@yahoo.de>
> Cc:
> Sent: Tuesday, September 4, 2012 11:18 PM
> Subject: Re: Git as the canonical SCM
>
> Mark, I disagree. Any group of modules that is released together can
> just have a git repo. What case do you have in mind where we'd need to
> fight with the git submodule madness?
>
> For others: if a project wants to move to git, the project must
> provide a <del>sacrificial victim</del> volunteer to help with git
> infrastructure.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Git as the canonical SCM
Posted by Benson Margulies <bi...@gmail.com>.
Mark, I disagree. Any group of modules that is released together can
just have a git repo. What case do you have in mind where we'd need to
fight with the git submodule madness?
For others: if a project wants to move to git, the project must
provide a <del>sacrificial victim</del> volunteer to help with git
infrastructure.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Git as the canonical SCM
Posted by Mark Struberg <st...@yahoo.de>.
And the Seam guys and a few others got pretty much stuck because the granularity level needs to be up front if you move to GIT.
GIT is cool, but it is not as modular as SVN. git-submodules are still a farce and there is nothing else which allows modularisation.
Don't get me wrong, I really like GIT (otherwise I would not have written the maven SCM provider for it) and it really fits pretty good for some kind of projects (we use it over at Apache DeltaSpike for example). But I think it would not be a good fit for Maven as it doesn't support modularity as well as SVN does.
LieGrue,
strub
----- Original Message -----
> From: Andrew Waterman <aw...@ecosur.mx>
> To: Maven Developers List <de...@maven.apache.org>
> Cc:
> Sent: Tuesday, September 4, 2012 10:17 PM
> Subject: Re: Git as the canonical SCM
>
>T he drools guys did a really nice move from Subversion a few years back.
>
> http://blog.athico.com/2010/12/drools-migrated-to-git.html
>
> One of the key things they did, was reorganize their poms and project structure.
>
> I'd be willing to help out. I think there could be a lot more to this move
> than just importing from subversion, but it depends on what you guys want to do.
>
> best wishes,
>
> Andrew
>
> On Sep 4, 2012, at 3:09 PM, "Jason Pyeron" <jp...@pdinc.us>
> wrote:
>
>>> -----Original Message-----
>>> From: Jason van Zyl
>>> Sent: Tuesday, September 04, 2012 15:55
>>>
>>> How's Git doing at Apache these days?
>>>
>>> Anyone interested in pursuing putting Maven in Git as the
>>> canonical SCM?
>>
>> Comments from the peanut gallery: It would make it very nice to contribute
> back.
>> Since I do not have a sandbox access I have thrown away fixes because there
> was
>> no efficient way to track them until they were accepted as patches. (same
>> problem in struts, commons, ...)
>>
>> We would be very happy here at PD Inc if that was done.
>>
>> -Jason Pyeron
>>
>> --
>> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>> - -
>> - Jason Pyeron PD Inc. http://www.pdinc.us -
>> - Principal Consultant 10 West 24th Street #100 -
>> - +1 (443) 269-1555 x333 Baltimore, Maryland 21218 -
>> - -
>> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>> This message is copyright PD Inc, subject to license 20080407P00.
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Git as the canonical SCM
Posted by Andrew Waterman <aw...@ecosur.mx>.
The drools guys did a really nice move from Subversion a few years back.
http://blog.athico.com/2010/12/drools-migrated-to-git.html
One of the key things they did, was reorganize their poms and project structure.
I'd be willing to help out. I think there could be a lot more to this move than just importing from subversion, but it depends on what you guys want to do.
best wishes,
Andrew
On Sep 4, 2012, at 3:09 PM, "Jason Pyeron" <jp...@pdinc.us> wrote:
>> -----Original Message-----
>> From: Jason van Zyl
>> Sent: Tuesday, September 04, 2012 15:55
>>
>> How's Git doing at Apache these days?
>>
>> Anyone interested in pursuing putting Maven in Git as the
>> canonical SCM?
>
> Comments from the peanut gallery: It would make it very nice to contribute back.
> Since I do not have a sandbox access I have thrown away fixes because there was
> no efficient way to track them until they were accepted as patches. (same
> problem in struts, commons, ...)
>
> We would be very happy here at PD Inc if that was done.
>
> -Jason Pyeron
>
> --
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> - -
> - Jason Pyeron PD Inc. http://www.pdinc.us -
> - Principal Consultant 10 West 24th Street #100 -
> - +1 (443) 269-1555 x333 Baltimore, Maryland 21218 -
> - -
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> This message is copyright PD Inc, subject to license 20080407P00.
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
RE: Git as the canonical SCM
Posted by Jason Pyeron <jp...@pdinc.us>.
> -----Original Message-----
> From: Jason van Zyl
> Sent: Tuesday, September 04, 2012 15:55
>
> How's Git doing at Apache these days?
>
> Anyone interested in pursuing putting Maven in Git as the
> canonical SCM?
Comments from the peanut gallery: It would make it very nice to contribute back.
Since I do not have a sandbox access I have thrown away fixes because there was
no efficient way to track them until they were accepted as patches. (same
problem in struts, commons, ...)
We would be very happy here at PD Inc if that was done.
-Jason Pyeron
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
- -
- Jason Pyeron PD Inc. http://www.pdinc.us -
- Principal Consultant 10 West 24th Street #100 -
- +1 (443) 269-1555 x333 Baltimore, Maryland 21218 -
- -
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
This message is copyright PD Inc, subject to license 20080407P00.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org