> On Oct 27, 2015, at 18:06, Simon Chemouil wrote:
>
> Richard S. Hall a écrit le 27/10/2015 21:22 :
>> Simon,
>>
>> You do realize that in Subversion you can just checkout a given
>> subproject, create a patch against it, then delete it, right?
>
> I do. Well I don't want to sound like a fan
Richard S. Hall a écrit le 27/10/2015 21:22 :
> Simon,
>
> You do realize that in Subversion you can just checkout a given
> subproject, create a patch against it, then delete it, right?
I do. Well I don't want to sound like a fanboy, but Git allows to deal
with multiple remotes (e.g when mainta
Simon,
You do realize that in Subversion you can just checkout a given
subproject, create a patch against it, then delete it, right?
-> richard
On 10/27/15 15:52 , Simon Chemouil wrote:
Benson Margulies wrote:
There was some discussion a while back about git, which I recall
(perhaps inaccur
Benson Margulies wrote:
> There was some discussion a while back about git, which I recall
> (perhaps inaccurately) as vaguely positive. It's a lot easier if each
> releasable thing gets its own git repo.
Hi,
At this point it looks like the switch is going to happen, and there has
been this argum
On Tue, Oct 27, 2015 at 3:00 PM, David Jencks wrote:
> I suspect it’s obvious already, but I’m in favor of moving to a single git
> repo and stopping there unless and until we find it quite inconvenient.
>
> A million thanks Benson for doing the work.
I won't say 'you're welcome' until I've done
I suspect it’s obvious already, but I’m in favor of moving to a single git repo
and stopping there unless and until we find it quite inconvenient.
A million thanks Benson for doing the work.
thanks
david jencks
> On Oct 27, 2015, at 10:07 AM, Benson Margulies wrote:
>
> On Tue, Oct 27, 2015 a
[
https://issues.apache.org/jira/browse/FELIX-5069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14976860#comment-14976860
]
Benson Margulies commented on FELIX-5069:
-
https://github.com/bndtools/bnd/issues/
On Tue, Oct 27, 2015 at 10:02 AM, Carsten Ziegeler wrote:
> Am 27.10.15 um 14:52 schrieb Benson Margulies:
>> On Tue, Oct 27, 2015 at 9:51 AM, Carsten Ziegeler
>> wrote:
>>> Am 27.10.15 um 14:28 schrieb Benson Margulies:
As a volunteer of record, I have a preference at this point for
f
Am 27.10.15 um 14:52 schrieb Benson Margulies:
> On Tue, Oct 27, 2015 at 9:51 AM, Carsten Ziegeler
> wrote:
>> Am 27.10.15 um 14:28 schrieb Benson Margulies:
>>> As a volunteer of record, I have a preference at this point for
>>> flipping the entire repo. It's not zero work; all the elements
>>>
On Tue, Oct 27, 2015 at 9:51 AM, Carsten Ziegeler wrote:
> Am 27.10.15 um 14:28 schrieb Benson Margulies:
>> As a volunteer of record, I have a preference at this point for
>> flipping the entire repo. It's not zero work; all the elements
>> have to be edited, and release plugin config adjusted,
Am 27.10.15 um 14:28 schrieb Benson Margulies:
> As a volunteer of record, I have a preference at this point for
> flipping the entire repo. It's not zero work; all the elements
> have to be edited, and release plugin config adjusted, for the maven
> plugins. But that's very straightforward. Once
As a volunteer of record, I have a preference at this point for
flipping the entire repo. It's not zero work; all the elements
have to be edited, and release plugin config adjusted, for the maven
plugins. But that's very straightforward. Once we get this much done,
we can then start to move things
On 27/10/15 13:45, Carsten Ziegeler wrote:
Looking at this thread, there seems to be no one really against moving
to git.
When it comes to moving, we have three options:
a) create a single git repo
I'd start here.
It's the simplest and lowest risk thing to do, doesn't break your
parent-pom
I fully agree.
Christian
On 27.10.2015 13:15, Richard S. Hall wrote:
I have no idea how it impacts anything, but keep in mind that
framework releases regularly (and generally) include more than one
subproject. I don't know how it complicates anything, just wanting to
point it out. In other wo
Looking at this thread, there seems to be no one really against moving
to git.
When it comes to moving, we have three options:
a) create a single git repo
b) create git repos by functional modules
c) create a git repo for every artifact
Depending on which variant we pick, the more work it is to
http://blogs.atlassian.com/2013/05/alternatives-to-git-submodule-git-subtree/
A decent replacement for gitslave that is currently maintained and
hosted in contrib in git itself.
On 2015-10-27 03:27, Carsten Ziegeler wrote:
> Am 26.10.15 um 21:17 schrieb Oliver Lietz:
>
>> gitslave is no l
I have no idea how it impacts anything, but keep in mind that framework
releases regularly (and generally) include more than one subproject. I
don't know how it complicates anything, just wanting to point it out. In
other words, it would be nice if those pushing this make sure they work
out all
On Tuesday 27 October 2015 11:26:37 Carsten Ziegeler wrote:
> Am 27.10.15 um 11:12 schrieb Benson Margulies:
> > My recommendation at this point in the discussion is to convert the
> > repo _en bloc_, then split out very independent things (if any), and
> > only then contemplate add-ons.
>
> I thi
And it takes .3 secs to switch your workspace between your two branches/tags …
Don’t forget that a lot of things that are heavy in SVN are feather weight in
Git.
Kind regards,
Peter Kriens
> On 26 okt. 2015, at 10:03, Carsten Ziegeler wrote:
>
> Am 25.10.15 um 17:12 schrieb David
What do you think about releasing more coarse grained on kind of a
subproject level (like e.g DependencyManager)?
I think it makes git much easier to use as then you can have one git
repo per subproject and releases are simple
to manage.
As subprojects are quite loosely coupled to each other yo
I see.
I asked the git conversion question a few years ago of Felix (the guy).
Back then it was a big no-no. I do hope things have changed now for the
project.
I'm a big fan of Git and have done a major Git conversion for a large
site some 6 years ago, and can tell you from experience that Gi
For Ferry,
The workflow to apply github pull requests with git svn is complex and
error prone. More and more, contributions from the outside come in as
pull requests.
What's 'broken', and I choose that term with some trepidation, is that
some of us really prefer some git workflow (task branches,
[
https://issues.apache.org/jira/browse/FELIX-5069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14976195#comment-14976195
]
Benson Margulies commented on FELIX-5069:
-
There is no test dependency involved in
Am 27.10.15 um 11:12 schrieb Benson Margulies:
> My recommendation at this point in the discussion is to convert the
> repo _en bloc_, then split out very independent things (if any), and
> only then contemplate add-ons.
>
I think we should split up from the beginning. We can split up by
functiona
Side-line for me too.
How about just using 'git svn ...'
Work locally in git, store in svn.
What's the big deal?
If there are blocking process issues _then_ you switch, right?
On 27/10/15 11:16, Achim Nierbeck wrote:
Just looking from the side-line of this ...
... but all of this sounds mor
[
https://issues.apache.org/jira/browse/FELIX-4985?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carsten Ziegeler resolved FELIX-4985.
-
Resolution: Duplicate
> Build loop in maven-bundle-plugin
> --
[
https://issues.apache.org/jira/browse/FELIX-5017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carsten Ziegeler resolved FELIX-5017.
-
Resolution: Duplicate
This has been fixed for the 3.0 release
> Maven bundle plugin incom
[
https://issues.apache.org/jira/browse/FELIX-5069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14976154#comment-14976154
]
Carsten Ziegeler commented on FELIX-5069:
-
[~bmargulies] Could this be a duplicate
Just looking from the side-line of this ...
... but all of this sounds more like a lot of pain compared to the gain.
SVN isn't that bad after all, so why fix something that isn't really broken?
Right now I don't see much of a benefit to this, but as I'm not part of any
decision makers here,
take t
[
https://issues.apache.org/jira/browse/FELIX-4834?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carsten Ziegeler resolved FELIX-4834.
-
Resolution: Fixed
The reported problem has been fixed, therefore resolving
> Maven bundle
My recommendation at this point in the discussion is to convert the
repo _en bloc_, then split out very independent things (if any), and
only then contemplate add-ons.
[
https://issues.apache.org/jira/browse/FELIX-5062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14976030#comment-14976030
]
Julian Sedding commented on FELIX-5062:
---
Thanks for the quick fix!
> maven-bundle-p
Am 26.10.15 um 21:17 schrieb Oliver Lietz:
>
> gitslave is no longer maintained, I suggest to look at Google repo[0] at
> least.
>
As a user of gitslave for some time I can only second this. Apart from
not being maintained for several years, I had a lot of problems with it.
I know that it works
[
https://issues.apache.org/jira/browse/FELIX-5073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carsten Ziegeler updated FELIX-5073:
Assignee: Benson Margulies
> Option to create dependency-reduced-pom exists
> --
[
https://issues.apache.org/jira/browse/FELIX-5070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carsten Ziegeler updated FELIX-5070:
Assignee: Benson Margulies
> Simple syntax for specifying embedded dependencies has broken
>
[
https://issues.apache.org/jira/browse/FELIX-5062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carsten Ziegeler reassigned FELIX-5062:
---
Assignee: Carsten Ziegeler
> maven-bundle-plugin includes tests dependencies in packa
[
https://issues.apache.org/jira/browse/FELIX-5062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carsten Ziegeler resolved FELIX-5062.
-
Resolution: Fixed
Thanks for your test case, Julian. I've added it to the test base.
I've
37 matches
Mail list logo
