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
herve.bout...@free.fr:
no problem for me on this one
if someone creates a new git repository, it would be nice
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
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
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.
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
dennisl.apa...@gmail.comwrote:
Hi Jason
While I'm finally starting to see the potential with a DVCS like git,
there are a couple of
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
On Feb 20, 2014, at 1:07 PM, Dennis Lundberg dennisl.apa...@gmail.com 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
On Thu, Feb 20, 2014 at 4:27 PM, Jason van Zyl ja...@takari.io wrote:
On Feb 20, 2014, at 1:07 PM, Dennis Lundberg dennisl.apa...@gmail.com 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,
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
On Thu, Feb 20, 2014 at 10:27 PM, Jason van Zyl ja...@takari.io wrote:
On Feb 20, 2014, at 1:07 PM, Dennis Lundberg dennisl.apa...@gmail.com 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
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
That is easily worked around tho by adding a dependency 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
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
+extension
+groupIdorg.apache.maven.wagon/groupId
+artifactIdwagon-ssh-external/artifactId
+version${extension.version.wagon}/version
+/extension
It was SSH settings that were not being respected. Things like ports and
ssh
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 m...@talios.com følgende:
A really good podcast on the subject of migration a large project, and
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:
duplicate the path structure the
same at home.
Fred.
On Fri, Feb 14, 2014 at 7:33 PM, Hervé BOUTEMY herve.bout...@free.frwrote:
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
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
,
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 vendredi 14 février 2014 17:10:07 Mark Derricutt a écrit
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 herve.bout...@free.fr:
found the doc: seems interesting
any live example to show?
or a demo on skins, for example, ie not much submodules, so
,
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 vendredi 14 février 2014 17:10:07 Mark Derricutt a écrit
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 herve.bout...@free.frwrote:
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
: 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
.
On Fri, Feb 14, 2014 at 7:33 PM, Hervé BOUTEMY herve.bout...@free.fr
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 then any tests from people wanting the
great
structure
the
same at home.
Fred.
On Fri, Feb 14, 2014 at 7:33 PM, Hervé BOUTEMY
herve.bout...@free.fr
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
, 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 vendredi 14 février 2014 17:10:07 Mark Derricutt a écrit :
Jenkins could build from a super
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
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]
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 ja...@tesla.io wrote:
Can we start the process of converting everything to Git. I don't really see
any
Le jeudi 13 février 2014 08:27:14 Jason van Zyl a écrit :
On Feb 13, 2014, at 1:36 AM, Hervé BOUTEMY herve.bout...@free.fr 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
On 13 February 2014 17:28, Hervé BOUTEMY herve.bout...@free.fr 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 herve.bout...@free.fr
wrote:
the only show stopper I know is for svn trunk which contains a lot of
components
On Feb 13, 2014, at 12:28 PM, Hervé BOUTEMY herve.bout...@free.fr 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 herve.bout...@free.fr wrote:
the only show stopper I know is for svn trunk which contains a lot of
components
so -1
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
On 13 February 2014 23:57, Jason van Zyl ja...@takari.io 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
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
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
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
Le jeudi 13 février 2014 14:29:12 Jason van Zyl a écrit :
On Feb 13, 2014, at 12:28 PM, Hervé BOUTEMY herve.bout...@free.fr 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 herve.bout...@free.fr wrote:
the only show stopper I know
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 vendredi 14
the
same at home.
Fred.
On Fri, Feb 14, 2014 at 7:33 PM, Hervé BOUTEMY herve.bout...@free.frwrote:
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
+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.
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
I like you more and more! :-)
On Thu, Feb 13, 2014 at 4:37 PM, Jason van Zyl ja...@tesla.io 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
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
That's only because you haven't met me in person.
On Feb 12, 2014, at 10:38 PM, Fred Cooke fred.co...@gmail.com wrote:
I like you more and more! :-)
On Thu, Feb 13, 2014 at 4:37 PM, Jason van Zyl ja...@tesla.io wrote:
Can we start the process of converting everything to Git. I don't
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 m...@talios.com wrote:
Do you envisage one master git repo, or multiple repositories for each
moveable piece?
Full
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
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?
48 matches
Mail list logo
