+1 (non binding).
Willing to help. Git shows clear advantages over svn.
Le 5 sept. 2012 14:37, "Garvin LeClaire" a
écrit :
> +1 (non-binding)
>
> --
> Regards,
>
>
> Garvin LeClaire
> garvin.lecla...@gmail.com
>
>
> On Wed, Sep 5, 2012 at 8:33 AM, Anders Hammar wrote:
> > +1 (non-binding)
> >
>
2012/9/6 Chris Graham :
> 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
I think it would be a very pragmatic move to simply leave the
"maven-plugins" project unmigrated
until we have established documentation and tool support to a level
where we're happy with whatever solution we choose.
I think the only really disasterous version we could end up with is
the one which
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 benef
On Sep 5, 2012, at 10:08 PM, Kristian Rosenvold wrote:
> 2012/9/5 Romain Manni-Bucau :
>> 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
>
>
2012/9/5 Romain Manni-Bucau :
> 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
+0.5 if it makes devs or patchers lives easier
No time to help, and I'd like to see a clearer understanding of how we'll
convert non-t/b/t-layout repos before we end up with 50 repositories as others
have said.
BTW, if anyone is looking at doing that, I found the svn2git worked well for
filter
+1 I/we can volunteer.
> -Original Message-
> From: Stephane Nicoll [mailto:stephane.nic...@gmail.com]
> Sent: Wednesday, September 05, 2012 9:21
> To: Maven Developers List
> Subject: Re: [VOTE] Move Maven projects sources to git
>
> +0
>
> S.
>
> On Wed, Sep 5, 2012 at 1:04 PM, Olivi
I knew someone would misread that.
I was not referring to anyone on this list. People on this list are at the
pointy end of the stick, although we have a spread of abilities, most are
in the upper end of the scale. The reason for this is simple. It's because
to do it because we like it, a passion
Let me drag out the Jazz SCM VM to see that it still works.
-Chris
On Thu, Sep 6, 2012 at 3:50 AM, Mark Struberg wrote:
> +1
>
> LieGrue,
> strub
>
>
>
>
> - Original Message -
> > From: Olivier Lamy
> > To: Maven Developers List
> > Cc:
> > Sent: Wednesday, September 5, 2012 2:46 PM
+1
Hervé
Le lundi 3 septembre 2012 22:29:36 Olivier Lamy a écrit :
> Hi,
> I'd like to release Maven Install plugin 2.4
>
> We fixed 5 issues:
> https://jira.codehaus.org/secure/ReleaseNote.jspa?version=15112&styleName=Te
> xt&projectId=11136 Staging repository:
> https://repository.apache.org/c
If we applied the same logic back in 2004, we would still be on CVS.
Personally, I think Git affords us a lot of opportunity to streamline
the contribution process and a much cleaner way of working (patching,
rebasing, local branches, etc.)
I've switched to Git for all of the rest of what I do
+1 but have no time to volunteer at the moment.
On 9/5/12 6:04 AM, Olivier Lamy wrote:
Hi,
This vote is to decide moving our source tree currently located in one
svn repository to git (multiple git repositories).
First, we need to have at least 3 volunteers to help on Apache infra
for this move
On Wed, Sep 5, 2012 at 8:34 PM, Olivier Lamy wrote:
> [+1] Move to git scm
> [0] No interest
> [-1] don't move to git (please explain why)
+1 (binding)
No capacity for volunteering to help :(
-
To unsubscribe, e-mail: dev-unsub
Github user velo closed the pull request at:
https://github.com/apache/maven-enforcer/pull/3
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
"No-one is using cvs anymore."
That's a wrong assumption, sad but true.
I still know companies which haven't invested in moving forward to a new
versioning system, because CVS still works good enough.
Investments is not only about the hardware and the investigation,
preparation and execution
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 (c
2012/9/5 Mark Struberg :
> 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 maint
+1 non binding
In terms of learning more about git, there are a LOT of free resources
available including books and other documentation as well as things like
live office hours at github and so on.
GitHub is also open sourcing all their training material so there will be
more as well.. and lots o
+1
LieGrue,
strub
- Original Message -
> From: Olivier Lamy
> To: Maven Developers List
> Cc:
> Sent: Wednesday, September 5, 2012 2:46 PM
> Subject: [VOTE] Maven SCM 1.8
>
> Hi,
> I'd like to release Apache Maven Scm 1.8.
> We fixed 10 issues:
> http://jira.codehaus.org/secure/Rel
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.autorebas
+1
--
Regards,
Igor
On 12-09-05 7:04 AM, Olivier Lamy wrote:
Hi,
This vote is to decide moving our source tree currently located in one
svn repository to git (multiple git repositories).
First, we need to have at least 3 volunteers to help on Apache infra
for this move and more generally on git
2012/9/5 Kristian Rosenvold :
> We only move things we are satisfied with. But we don't vote on each
> item unless there turns out to be some real issues to solve.
> Most of the maven projects already have excellent git repositories at
> http://git.apache.org/,
Note: current ASF projects using git
We only move things we are satisfied with. But we don't vote on each
item unless there turns out to be some real issues to solve.
Most of the maven projects already have excellent git repositories at
http://git.apache.org/,
for these it's just a modified "scm" url and the flip of a switch or two.
Hi Folks,
First reminder, moving site and distribution to svnpubsub is mandatory
for the end of the year (the good is dist and sync are very very fast
opposite to the current rsync process)
As you remember, Hervé started some times ago a test site
http://maventest.apache.org which is a mix of cms a
I'm +0.5 on everything that currently has the trunk/tags/branches setup in SVN.
-1 on things that are not setup that way right now until more discussions and
agreement can be made on how that should be approached.
Really, I think we should just do Maven core and maybe one or two other simple
o
2012/9/5 Chris Graham :
> It's not a matter of thinking that git is like SVN at all.
>
> It's the exact opposite in fact; they are different, to the extent that it
> entails a whole new approach.
>
> We have a well resourced, well understood, well supported tool and mature
> practices with our cu
Chris,
Just whom amongst us are you labeling 'a few immature devs'?
Many of us here have been using both git and svn, extensively, for
years now, and have a preference for git based on plenty of practical
experience. While git is new-ish at the ASF, it's official, and a
growing list of projects a
+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 zilli
+0
S.
On Wed, Sep 5, 2012 at 1:04 PM, Olivier Lamy wrote:
> Hi,
> This vote is to decide moving our source tree currently located in one
> svn repository to git (multiple git repositories).
> First, we need to have at least 3 volunteers to help on Apache infra
> for this move and more generally
https://cwiki.apache.org/confluence/display/MAVEN/Scheme+for+managing+Maven+source+in+Git
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
fwiw, i suspect most of us that have voted simply prefer working with
git over svn
certainly anyone that has had to manage branching and merging with svn
vs git would understand...it is simply better with git.
sorry you had management push you to use Hg, but git is a solid
upgrade over svn at thi
It's not a matter of thinking that git is like SVN at all.
It's the exact opposite in fact; they are different, to the extent that it
entails a whole new approach.
We have a well resourced, well understood, well supported tool and mature
practices with our current SVN.
All I am saying is that
+1, cannot help unfortunatelely
Milos
On Wed, Sep 5, 2012 at 1:04 PM, Olivier Lamy wrote:
> Hi,
> This vote is to decide moving our source tree currently located in one
> svn repository to git (multiple git repositories).
> First, we need to have at least 3 volunteers to help on Apache infra
> f
+1 binding can help
On Wed, Sep 5, 2012 at 7:45 AM, Jesse McConnell
wrote:
> +1, git is far beyond being a 'fad'
>
>
>
> --
> jesse mcconnell
> jesse.mcconn...@gmail.com
>
>
> On Wed, Sep 5, 2012 at 6:41 AM, Arnaud Héritier wrote:
>> I think Olivier already replied to some points given few point
Hi,
I'd like to release Apache Maven Scm 1.8.
We fixed 10 issues:
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10527&version=18444
Staging repository:
https://repository.apache.org/content/repositories/maven-037/
Staging site: http://maven.apache.org/scm-1.8/
Vote open for 72H
[+1]
I think Chris ask more what will that change for our projects for
community point.
Perso I'm a bit curious to see if that will increase externals contributions.
I don't want to do that only to ease life of "private maven forkers".
But so this discussion must in a separate thread not in the vote thr
+1 (non-binding)
--
Regards,
Garvin LeClaire
garvin.lecla...@gmail.com
On Wed, Sep 5, 2012 at 8:33 AM, Anders Hammar wrote:
> +1 (non-binding)
>
> But I don't have the hard-core git knowledge to help out in the move.
> Would probably do more harm than good. :-)
>
> /Anders
> On Wed, Sep 5, 2
+1 (non-binding)
But I don't have the hard-core git knowledge to help out in the move.
Would probably do more harm than good. :-)
/Anders
On Wed, Sep 5, 2012 at 2:19 PM, Kristian Rosenvold
wrote:
> The hosting bit is defined in context of apache, there is not much we
> need to do in that respect
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 spars
The hosting bit is defined in context of apache, there is not much we
need to do in that respect. This dusussion has been on/off for quite a
few years, so I'm not entirely surprised if you haven't seen it all.
As for "fad", I'm old enough to believe that version control systems
have their "epochs"
+1, git is far beyond being a 'fad'
--
jesse mcconnell
jesse.mcconn...@gmail.com
On Wed, Sep 5, 2012 at 6:41 AM, Arnaud Héritier wrote:
> I think Olivier already replied to some points given few points where Git
> is really interesting : performances, branches management ..
> But yes there ar
I think Olivier already replied to some points given few points where Git
is really interesting : performances, branches management ..
But yes there are skills to learn, it's not easy and the error is to think
that Git is like SVN
But it may be an opportunity to learn ?
On Wed, Sep 5, 2012 at 1:38
+1
Il giorno 05/set/2012 13:04, "Olivier Lamy" ha scritto:
> Hi,
> This vote is to decide moving our source tree currently located in one
> svn repository to git (multiple git repositories).
> First, we need to have at least 3 volunteers to help on Apache infra
> for this move and more generally
-1 Non binding.
I have no desire to setup and learn new tools for no clearly apparent
advantages.
There appears to be multitude of ways that DSCM's can be configured. I'm
not sure if sufficient thought/discussion has been given to the way in
which it should/can be set up.
Where it is to be hosted?
On Wed, 5 Sep 2012 13:04:29 +0200
Olivier Lamy wrote:
+1, but can not be volunteer no time at all ATM.
Next month should be better to help you guys and do some code at last...
tony.
> Hi,
> This vote is to decide moving our source tree currently located in one
> svn repository to git (multiple
+1 and volunteer for infra help.
I'll find the opportunity to launch few more shells commands per day :-)
Arnaud
On Wed, Sep 5, 2012 at 1:25 PM, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:
> +1. Have no spare time ATM, so cannot volunteer even if I would love to
>
> On 5 September
+1. Have no spare time ATM, so cannot volunteer even if I would love to
On 5 September 2012 12:04, Olivier Lamy wrote:
> Hi,
> This vote is to decide moving our source tree currently located in one
> svn repository to git (multiple git repositories).
> First, we need to have at least 3 volunteer
+1 Will volunteer
Den 5. sep. 2012 kl. 13:04 skrev Olivier Lamy :
> Hi,
> This vote is to decide moving our source tree currently located in one
> svn repository to git (multiple git repositories).
> First, we need to have at least 3 volunteers to help on Apache infra
> for this move and more gen
+1 and volunteer for infra help.
2012/9/5 Olivier Lamy :
> Hi,
> This vote is to decide moving our source tree currently located in one
> svn repository to git (multiple git repositories).
> First, we need to have at least 3 volunteers to help on Apache infra
> for this move and more generally on
Hi,
This vote is to decide moving our source tree currently located in one
svn repository to git (multiple git repositories).
First, we need to have at least 3 volunteers to help on Apache infra
for this move and more generally on git Apache infrastructure. (if you
are volunteer you must say that w
> 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
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
> To: Maven Developers List
> Cc:
> Sent: Wednesday, September 5, 2012 9:31 AM
> Subje
+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 wrote:
> +1 to do it step by step
> The conversion is "easy" for projects ha
+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 r
2012/9/5 Kristian Rosenvold :
> 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
emai
2012/9/5 Anders Hammar :
>>> This would be for the RCs as well?
>> Sure I will update the procedure as well.
>
> Ok, I'm not sure I see the point. The RCs will never be released and
> the whole point of this storage is for released stuff, right? The only
> point would be to keep things in dev/ as a
>> This would be for the RCs as well?
> Sure I will update the procedure as well.
Ok, I'm not sure I see the point. The RCs will never be released and
the whole point of this storage is for released stuff, right? The only
point would be to keep things in dev/ as an archive. Not sure there's
much v
On Wed, Sep 5, 2012 at 5:01 PM, Kristian Rosenvold
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
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-sc
2012/9/5 Anders Hammar :
>> For voting period the candidate files can be committed to the correct
>> tree here https://dist.apache.org/repos/dist/dev/ (instead of scp to
>> people.a.o)
>
> This would be for the RCs as well?
Sure I will update the procedure as well.
But during vote time the candidat
> For voting period the candidate files can be committed to the correct
> tree here https://dist.apache.org/repos/dist/dev/ (instead of scp to
> people.a.o)
This would be for the RCs as well?
> Then once the vote has passed releasing is simple copy from
> https://dist.apache.org/repos/dist/dev/ t
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 conside
If you want to have a look at the new proposed tree, I have imported
the content here https://dist.apache.org/repos/dist/dev/maven/
2012/9/4 Olivier Lamy :
> Back on this.
> I wonder about changing a bit the distrib directory tree ?
>
> The goal is to ease release.
> For voting period the candidat
+1
2012/9/3 Olivier Lamy :
> Hi,
> I'd like to release Maven Install plugin 2.4
>
> We fixed 5 issues:
> https://jira.codehaus.org/secure/ReleaseNote.jspa?version=15112&styleName=Text&projectId=11136
> Staging repository:
> https://repository.apache.org/content/repositories/maven-031/
> Staging si
65 matches
Mail list logo
