Personally I don't have the need, but if we want to move projects to Git,
this is probably one of the easy ones.
Robert
Op Wed, 12 Mar 2014 03:03:21 +0100 schreef Hervé BOUTEMY
:
no problem for me on this one
if someone creates a new git repository, it would be nice to create a
Maven
no problem for me on this one
if someone creates a new git repository, it would be nice to create a Maven
root git repository with submodules definition to every actual git module
Regards,
Hervé
Le mardi 11 mars 2014 16:34:26 Baptiste Mathus a écrit :
> Hi all,
>
> Wondering, wouldn't maven-r
Hi all,
Wondering, wouldn't maven-release be a good next candidate for a Git
migration?
I'm currently working locally with the maven-release github mirror, but
just had to checkout svn trunk to have a look at MRELEASE-431's robert's
current proposal (yes, I could've also git svn'ed it).
Cheers
+
+org.apache.maven.wagon
+wagon-ssh-external
+${extension.version.wagon}
+
It was SSH settings that were not being respected. Things like ports and
ssh hosts vs DNS lookups, etc.
There were other issues with multi-module-par
Yep. I release projects every day with git and m-r-p. The only issues I
know of are if you are wanting to release a portion of the repository or a
reactor that does not start at the root of the repository... but I don't do
that and I think it is a stupid thing to do anyway, so not a problem for me
That is easily worked around tho by adding a setting for
the newer -scm- modules.
mark
On 21 Feb 2014, at 10:29, Benson Margulies wrote:
The M-R-P has a giant bug such that the current version of it and the
current version of git do not work together. I think the bug is
particularly severe f
On 21 Feb 2014, at 10:27, Jason van Zyl wrote:
I only release core and that works fine which begs the question: do we
want to normalize our repository structure to simplify the tooling
requirements. What exactly doesn't work? Trying to release a single
thing out of a repository containing many
On Thu, Feb 20, 2014 at 10:27 PM, Jason van Zyl wrote:
>
> On Feb 20, 2014, at 1:07 PM, Dennis Lundberg wrote:
>
>> Hi Jason
>>
>> While I'm finally starting to see the potential with a DVCS like git,
>> there are a couple of things that stands in the way of migrating, for
>> example plugins, to
The entire SCM interface is very SVN-centric IMO. I raised a number of git
related m-rel-p issues some time ago, but have been busy moving countries
and more in the mean time. I doubt there has been progress on them, though.
One pretty much required a core change to Maven (perhaps something for
4.0
On Thu, Feb 20, 2014 at 4:27 PM, Jason van Zyl wrote:
>
> On Feb 20, 2014, at 1:07 PM, Dennis Lundberg wrote:
>
>> Hi Jason
>>
>> While I'm finally starting to see the potential with a DVCS like git,
>> there are a couple of things that stands in the way of migrating, for
>> example plugins, to g
On Feb 20, 2014, at 1:07 PM, Dennis Lundberg wrote:
> Hi Jason
>
> While I'm finally starting to see the potential with a DVCS like git,
> there are a couple of things that stands in the way of migrating, for
> example plugins, to git:
>
> 1. Judging by our resident git gurus, it will require
Maven Core is in git and has been for quite some time now... or you mean
some other Mave Core?
https://git-wip-us.apache.org/repos/asf?p=maven.git
--
Regards,
Igor
On 2/20/2014, 16:12, Paul Benedict wrote:
Would it be a good test to first try migrating individual plugin projects
to GIT before
Would it be a good test to first try migrating individual plugin projects
to GIT before attempting Maven Core?
On Thu, Feb 20, 2014 at 3:07 PM, Dennis Lundberg
wrote:
> Hi Jason
>
> While I'm finally starting to see the potential with a DVCS like git,
> there are a couple of things that stands i
Hi Jason
While I'm finally starting to see the potential with a DVCS like git,
there are a couple of things that stands in the way of migrating, for
example plugins, to git:
1. Judging by our resident git gurus, it will require quite some
effort to prepare for and execute the actual migration. Do
Linking to podcasts and articles is intertresting, especially for those who
haven't done it before.
What this needs i a volunteer to do the task.
K
16. feb. 2014 04:07 skrev "Mark Derricutt" følgende:
> A really good podcast on the subject of migration a large project, and
> large team from
A really good podcast on the subject of migration a large project, and
large team from subversion to git can be heard at:
http://episodes.gitminutes.com/2013/08/gitminutes-20-mick-wever-on-migrating.html
Also:
http://episodes.gitminutes.com/2013/12/gitminutes-26-campbell-barton-on-trick
AIUI, SVN is still required by Infra because of svnpubsub:
- for the dist repo (that is not a big deal)
- for websites (might cause some grief)
On 13 February 2014 03:37, Jason van Zyl wrote:
> Can we start the process of converting everything to Git. I don't really see
> any benefit in using S
MRELEASE-862, which should fix MRELEASE-812 (both fixed for next release)
However, rumors go this fixes the Git Issue(s), but also that it doesn't.
No good feedback, so I'm not sure if this will be the N-th release in a
row with bad Git support.
Robert
[1] https://jira.codehaus.org/browse/MR
With myrepos one (or a team) can list many VCS repos in a config file and do
batch operations on all of the repos or selectively clone (checkout) repos.
http://myrepos.branchable.com
myrepos is written in perl and packaged in Debian:
http://packages.qa.debian.org/m/myrepos.html
Regards, Thomas
n duplicate the path structure
> the
> >> same at home.
> >>
> >> Fred.
> >>
> >> On Fri, Feb 14, 2014 at 7:33 PM, Hervé BOUTEMY >wrote:
> >>> I'm not a git expert: if there are solutions, yes, they have to be
> found,
> >&g
; >
> > > > Unsure if this addresses your concerns or not, but it's certainly
> neat
> > > and
> > > > tidy at the server end, and the user can duplicate the path structure
> > the
> > > > same at home.
> > > &
gt;>
> >> Unsure if this addresses your concerns or not, but it's certainly neat
> and
> >> tidy at the server end, and the user can duplicate the path structure
> the
> >> same at home.
> >>
> >> Fred.
> >>
> >> On Fri, F
me for this.
> > > >
> > > > baseurl/org/apache/mvn/core/componentA.git
> > > >
> > > > etc.
> > > >
> > > > Unsure if this addresses your concerns or not, but it's certainly
> neat
> > > and
> > > &
t; Unsure if this addresses your concerns or not, but it's certainly neat and
>> tidy at the server end, and the user can duplicate the path structure the
>> same at home.
>>
>> Fred.
>>
>> On Fri, Feb 14, 2014 at 7:33 PM, Hervé BOUTEMY wrote:
>>>
e server end, and the user can duplicate the path structure
> the
> > > same at home.
> > >
> > > Fred.
> > >
> > > On Fri, Feb 14, 2014 at 7:33 PM, Hervé BOUTEMY > >wrote:
> > > > I'm not a git expert: if there are solutions
git clone --recursive
https://github.com/Batmat/asciidoctor-maven-plugin-issue-494-html5-backend-not-working?
2014-02-14 9:21 GMT+01:00 Hervé BOUTEMY :
> found the doc: seems interesting
>
> any live example to show?
> or a demo on skins, for example, ie not much submodules, so it seems a good
>
> > On Fri, Feb 14, 2014 at 7:33 PM, Hervé BOUTEMY >wrote:
> > > I'm not a git expert: if there are solutions, yes, they have to be
> found,
> > > explained, tested, before we launch "convert everything to git"
> > >
> > > thank you for an
found the doc: seems interesting
any live example to show?
or a demo on skins, for example, ie not much submodules, so it seems a good
cancidate for tests
Regards,
Hervé
Le vendredi 14 février 2014 08:46:32 Baptiste Mathus a écrit :
> +1 on the submodule solution. We started using it some mont
> tidy at the server end, and the user can duplicate the path structure the
> same at home.
>
> Fred.
>
> On Fri, Feb 14, 2014 at 7:33 PM, Hervé BOUTEMY wrote:
> > I'm not a git expert: if there are solutions, yes, they have to be found,
> > explained, tested, be
+1 on the submodule solution. We started using it some months ago since the
branch option came out.
As a simplistic analogy, you can see it as svn: externals equivalent.
It helps developers (and ci configuration) to retrieve many related
projects in only one clone command.
My 2 cents
Le 14 févr.
structure the
same at home.
Fred.
On Fri, Feb 14, 2014 at 7:33 PM, Hervé BOUTEMY wrote:
> I'm not a git expert: if there are solutions, yes, they have to be found,
> explained, tested, before we launch "convert everything to git"
>
> thank you for any good idea and t
I'm not a git expert: if there are solutions, yes, they have to be found,
explained, tested, before we launch "convert everything to git"
thank you for any good idea and then any tests from people wanting the great
migration to happen (without wreaking havoc)
Regards,
Hervé
Le jeudi 13 février 2014 14:29:12 Jason van Zyl a écrit :
> On Feb 13, 2014, at 12:28 PM, Hervé BOUTEMY wrote:
> > Le jeudi 13 février 2014 08:27:14 Jason van Zyl a écrit :
> >> On Feb 13, 2014, at 1:36 AM, Hervé BOUTEMY wrote:
> >>> the only show stopper I know is for svn trunk which contains a
On 14 Feb 2014, at 2:27, Jason van Zyl wrote:
Why wouldn't you put something with its own release cycle in its own
repository?
Actually, whilst we're on the subject - can we get a
maven-release-plugin out which locks in a newer version of the *-scm-*
dependencies as currently, m-r-p BREAKS o
Jenkins could build from a super-repo that uses git submodule.
Since a quite a few versions ago, git-submodules can now follow a branch
rather than a fixed SHA1.
So you could build/test monolithically, branch/commit individually.
Compromise maybe?
On 14 Feb 2014, at 6:28, Hervé BOUTEMY wrot
On 14 Feb 2014, at 2:27, Jason van Zyl wrote:
Why wouldn't you put something with its own release cycle in its own
repository?
maven-release-plugin and git's branching/tagging really kinda make that
hard to avoid.
Unless we move EVERYTHING to generations :)
Mark
--
On 13 February 2014 23:57, Jason van Zyl wrote:
[del]
> The biggest win for me is working on branches. Working with branches in SVN
> is horrible, only worse in p4 which is saying a lot. The ability to easily
> create branches, squash commits, incrementally improve them without fear. I
> consta
Great posts, Jason! There are so many reasons to dump SVN, but controlled
branch sharing and personal work flow are big ones for me, too. I have a
dozen or more local branches of my project, too, and like you, I rebase
against what I publish until they're ready, then publish them, and rebase
the ot
On Feb 13, 2014, at 12:28 PM, Hervé BOUTEMY wrote:
> Le jeudi 13 février 2014 08:27:14 Jason van Zyl a écrit :
>> On Feb 13, 2014, at 1:36 AM, Hervé BOUTEMY wrote:
>>> the only show stopper I know is for svn trunk which contains a lot of
>>> components
>>>
>>> so -1 for plugins, shared, skins,
On 13 February 2014 17:28, Hervé BOUTEMY wrote:
> Le jeudi 13 février 2014 08:27:14 Jason van Zyl a écrit :
> > On Feb 13, 2014, at 1:36 AM, Hervé BOUTEMY
> wrote:
> > > the only show stopper I know is for svn trunk which contains a lot of
> > > components
> > >
> > > so -1 for plugins, shared,
Le jeudi 13 février 2014 08:27:14 Jason van Zyl a écrit :
> On Feb 13, 2014, at 1:36 AM, Hervé BOUTEMY wrote:
> > the only show stopper I know is for svn trunk which contains a lot of
> > components
> >
> > so -1 for plugins, shared, skins, resources
>
> Why wouldn't you put something with its o
On Feb 13, 2014, at 1:36 AM, Hervé BOUTEMY wrote:
> the only show stopper I know is for svn trunk which contains a lot of
> components
>
> so -1 for plugins, shared, skins, resources
>
Why wouldn't you put something with its own release cycle in its own
repository?
> but no problem for me
the only show stopper I know is for svn trunk which contains a lot of
components
so -1 for plugins, shared, skins, resources
but no problem for me for other release roots containing only one component
[1]
notice I don't see much gain: did we get much patches for components already
in git? did
The SVN repo should probably be retained anyway, just in RO format, and
with a new URL that indicates it shouldn't be used. You can try to retain
all history, but it's never quite in the same form, really. Perhaps no one
cares, though?
+1 for decompose into individual repos.
Fred.
PS, perhaps on
Probably a little more decompose like a repository for each plugin and shared
component. No reason all history can't be retained.
On Feb 12, 2014, at 11:03 PM, Mark Derricutt wrote:
> Do you envisage one master git repo, or multiple repositories for each
> moveable piece?
>
> Full history ret
That's only because you haven't met me in person.
On Feb 12, 2014, at 10:38 PM, Fred Cooke wrote:
> I like you more and more! :-)
>
>
> On Thu, Feb 13, 2014 at 4:37 PM, Jason van Zyl wrote:
>
>> Can we start the process of converting everything to Git. I don't really
>> see any benefit in us
Do you envisage one master git repo, or multiple repositories for each
moveable piece?
Full history retainment?
On 13 Feb 2014, at 16:37, Jason van Zyl wrote:
Can we start the process of converting everything to Git. I don't
really see any benefit in using Subversion any longer.
If so then
I like you more and more! :-)
On Thu, Feb 13, 2014 at 4:37 PM, Jason van Zyl wrote:
> Can we start the process of converting everything to Git. I don't really
> see any benefit in using Subversion any longer.
>
> If so then we should just get together for a day and convert them and then
> get i
Can we start the process of converting everything to Git. I don't really see
any benefit in using Subversion any longer.
If so then we should just get together for a day and convert them and then get
infra to use what we converted to do the flip.
Jason (who would be happy to never execute svn a
49 matches
Mail list logo
