>>>>> Karl Pauls :
> I finished the migration to git. Following the outline from last week,
> we now have two git repositories namely:
It's a bit late to come to the party, but did you binary-strip the
converted git repository after converting and before starting to use it?
from svn to git as a
> pre-requisite, but if someone is doing that, great.
I grant you that, it is more something that I *think* should happen
first if we have time to work on things. If that is the only thing
missing I'm not going to insist on it.
For sure we need to update it with the current g
Thanks, finally an answer about the process - which you ignored last week :)
I personally don't see why we need to move the site from svn to git as a
pre-requisite, but if someone is doing that, great.
Now, in general I agree, but I feel it a little bit strange that you
allow a new git
gt; >
> > Wait, I am objecting :-).
> >
> > In the first place, while I realize there are benefits to having a git
> > project matching a subproject (and yes, I would like to move framework
> > at one point), most I can think of correspond with active development
&g
together.
Let me prepare something ;)
Thanks again,
Regards
JB
> Le 2 mars 2020 à 07:52, Karl Pauls a écrit :
>
> Wait, I am objecting :-).
>
> In the first place, while I realize there are benefits to having a git
> project matching a subproject (and yes, I would like to move
Wait, I am objecting :-).
In the first place, while I realize there are benefits to having a git
project matching a subproject (and yes, I would like to move framework
at one point), most I can think of correspond with active development
or at a minimum, need work beyond just creating the repo
OK, I will start with these repos.
I keep you posted.
Regards
JB
> Le 1 mars 2020 à 14:26, Carsten Ziegeler a écrit :
>
> I think moving to a separate git makes sense for active (in some sense)
> projects. So, yes, I guess it makes sense for the three you mentioned, too.
>
&g
I think moving to a separate git makes sense for active (in some sense)
projects. So, yes, I guess it makes sense for the three you mentioned, too.
+1
Carsten
On 01.03.2020 12:41, Jean-Baptiste Onofre wrote:
+1 for that.
Do you want me to tackle other modules (I’m thinking about fileinstall
ion and
> http implementation into separate git project each (only one for all http sub
> projects).
>
> If no one objects, I'll go ahead in the next days.
>
> Thanks
> Carsten
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org
Hi,
I would like to move the SCR implementation, Configadmin implementation
and http implementation into separate git project each (only one for all
http sub projects).
If no one objects, I'll go ahead in the next days.
Thanks
Carsten
--
Carsten Ziegeler
Adobe Research Switzerland
cziege
Carsten Ziegeler
wrote:
Thanks for all the work and your patience Karl! :)
How do we want to handle splitting out projects into separate git
repositories? Is a volunteer and a notice via mail enough or do we
need
to do a vote?
I'm checking out code using the ssh urls from github, so in order
use (aries-* for example).
> > >
> > > - Ray
> > >
> > > On Fri, Feb 28, 2020 at 1:46 AM Carsten Ziegeler >
> > > wrote:
> > >
> > >> Thanks for all the work and your patience Karl! :)
> > >>
> > >> How do we want to h
xample).
> >
> > - Ray
> >
> > On Fri, Feb 28, 2020 at 1:46 AM Carsten Ziegeler
> > wrote:
> >
> >> Thanks for all the work and your patience Karl! :)
> >>
> >> How do we want to handle splitting out projects into separate git
>
already use (aries-* for example).
- Ray
On Fri, Feb 28, 2020 at 1:46 AM Carsten Ziegeler
wrote:
Thanks for all the work and your patience Karl! :)
How do we want to handle splitting out projects into separate git
repositories? Is a volunteer and a notice via mail enough or do we need
to do
arl! :)
>
> How do we want to handle splitting out projects into separate git
> repositories? Is a volunteer and a notice via mail enough or do we need
> to do a vote?
>
> I'm checking out code using the ssh urls from github, so in order to do
> a mvn release I needed to
Thanks for all the work and your patience Karl! :)
How do we want to handle splitting out projects into separate git
repositories? Is a volunteer and a notice via mail enough or do we need
to do a vote?
I'm checking out code using the ssh urls from github, so in order to do
a mvn release I
Hi Karl,
Thanks for the update and done that.
I confirm that I received the gitbox notification that I have permission on the
repository.
Thanks again,
Regards
JB
> Le 28 févr. 2020 à 00:50, Karl Pauls a écrit :
>
> Hi,
>
> I finished the migration to git. Following the ou
Hi,
I finished the migration to git. Following the outline from last week,
we now have two git repositories namely:
Felix Dev - https://github.com/apache/felix-dev
Felix Atomos - https://github.com/apache/felix-atomos
Felix Dev has been migrated with history and I managed to get our
release
hink a unique repository is fine (for all part), at least as a first step.
>
> Do you need help about that ?
>
> Regards
> JB
>
>> Le 21 févr. 2020 à 17:27, Karl Pauls a écrit :
>>
>> Hi,
>>
>> I know i've been dragging my feet with regard to
Hi Karl
I think a unique repository is fine (for all part), at least as a first step.
Do you need help about that ?
Regards
JB
> Le 21 févr. 2020 à 17:27, Karl Pauls a écrit :
>
> Hi,
>
> I know i've been dragging my feet with regard to the migration to git.
> Unfortunat
angement if needed.
> >
> > thanks!
> > David Jencks
> >
> > > On Feb 21, 2020, at 8:27 AM, Karl Pauls wrote:
> > >
> > > Hi,
> > >
> > > I know i've been dragging my feet with regard to the migration to git.
> > > Unfort
gt;
> > Hi,
> >
> > I know i've been dragging my feet with regard to the migration to git.
> > Unfortunately, I didn't find the time until now.
> >
> > I would like to try to make some progress now and there are a couple
> > of points to consider namely,
>
+1
I think your plan will be a big improvement for now and allow for further
rearrangement if needed.
thanks!
David Jencks
> On Feb 21, 2020, at 8:27 AM, Karl Pauls wrote:
>
> Hi,
>
> I know i've been dragging my feet with regard to the migration to git.
> Unfortunat
Hi,
I know i've been dragging my feet with regard to the migration to git.
Unfortunately, I didn't find the time until now.
I would like to try to make some progress now and there are a couple
of points to consider namely,
- our website is currently based on svn and we are using the apache
cms
+1
Tom
On Fri, Feb 21, 2020 at 10:27 AM Karl Pauls wrote:
> Hi,
>
> I know i've been dragging my feet with regard to the migration to git.
> Unfortunately, I didn't find the time until now.
>
> I would like to try to make some progress now and there are a couple
> of poin
Time to call the vote on our move to git(box).
We had +1 from:
Rob Walker, Guillaume Nodet, Stefan Seifert, David Bosschaert, Pierre
De Rop, Jean-Baptiste Onofré, Raymond Auge, Thomas Watson, Richard S.
Hall, David Jencks, Jan Willem Janssen, Georg Henzler, Christian
Schneider, and Karl Pauls
+1
Christian
Am Di., 19. Nov. 2019 um 10:11 Uhr schrieb Karl Pauls :
> Following up on the discussion about moving Felix to git I'd like to
> call for a vote now.
>
> The idea is to ask Infra to move the current svn to gitbox
> (https://gitbox.apache.org) which will give us a t
+1
-Georg
On 2019-11-19 10:11, Karl Pauls wrote:
Following up on the discussion about moving Felix to git I'd like to
call for a vote now.
The idea is to ask Infra to move the current svn to gitbox
(https://gitbox.apache.org) which will give us a two-master setup of
git repositories, allowing
On 2019-11-19 10:11, Karl Pauls wrote:
Following up on the discussion about moving Felix to git I'd like to
call for a vote now.
The idea is to ask Infra to move the current svn to gitbox
(https://gitbox.apache.org) which will give us a two-master setup of
git repositories, allowing committers
+1
David Jencks
> On Nov 19, 2019, at 1:11 AM, Karl Pauls wrote:
>
> Following up on the discussion about moving Felix to git I'd like to
> call for a vote now.
>
> The idea is to ask Infra to move the current svn to gitbox
> (https://gitbox.apache.org) which will give
+1
On Tue, Nov 19, 2019, 04:11 Karl Pauls wrote:
> Following up on the discussion about moving Felix to git I'd like to
> call for a vote now.
>
> The idea is to ask Infra to move the current svn to gitbox
> (https://gitbox.apache.org) which will give us a two-master
+1
On Tue, Nov 19, 2019 at 3:11 AM Karl Pauls wrote:
> Following up on the discussion about moving Felix to git I'd like to
> call for a vote now.
>
> The idea is to ask Infra to move the current svn to gitbox
> (https://gitbox.apache.org) which will give us a two-master
+1
- Ray
On Tue, Nov 19, 2019, 05:26 Jean-Baptiste Onofré, wrote:
> +1
>
> Regards
> JB
>
> On 19/11/2019 10:11, Karl Pauls wrote:
> > Following up on the discussion about moving Felix to git I'd like to
> > call for a vote now.
> >
> > The id
+1
Regards
JB
On 19/11/2019 10:11, Karl Pauls wrote:
> Following up on the discussion about moving Felix to git I'd like to
> call for a vote now.
>
> The idea is to ask Infra to move the current svn to gitbox
> (https://gitbox.apache.org) which will give us a two-master
+1
regards
pierre
On Tue, Nov 19, 2019 at 10:27 AM David Bosschaert <
david.bosscha...@gmail.com> wrote:
> +1
>
> David
>
> On Tue, 19 Nov 2019 at 09:11, Karl Pauls wrote:
>
> > Following up on the discussion about moving Felix to git I'd like to
> > c
+1
David
On Tue, 19 Nov 2019 at 09:11, Karl Pauls wrote:
> Following up on the discussion about moving Felix to git I'd like to
> call for a vote now.
>
> The idea is to ask Infra to move the current svn to gitbox
> (https://gitbox.apache.org) which will give us a two-master
+1 (non-binding)
+1
Le mar. 19 nov. 2019 à 10:11, Karl Pauls a écrit :
> Following up on the discussion about moving Felix to git I'd like to
> call for a vote now.
>
> The idea is to ask Infra to move the current svn to gitbox
> (https://gitbox.apache.org) which will give us a two-master
+1
-Rob
-Original Message-
From: Karl Pauls
Sent: 19 November 2019 09:11
To: dev@felix.apache.org
Subject: [VOTE] Move Felix to git(box)
Following up on the discussion about moving Felix to git I'd like to call for a
vote now.
The idea is to ask Infra to move the current svn
Following up on the discussion about moving Felix to git I'd like to
call for a vote now.
The idea is to ask Infra to move the current svn to gitbox
(https://gitbox.apache.org) which will give us a two-master setup of
git repositories, allowing committers to utilize two different avenues
+1
On Sat, Nov 2, 2019 at 4:06 AM Christian Schneider
wrote:
> In the past we discussed a few times about moving felix to git.
>
> A while ago we did this step for Aries and it was simpler than anticipated.
> The problem in Aries were the remaining small bundles and subprojects
+1
Le sam. 2 nov. 2019 à 10:06, Christian Schneider
a écrit :
> In the past we discussed a few times about moving felix to git.
>
> A while ago we did this step for Aries and it was simpler than anticipated.
> The problem in Aries were the remaining small bundles and subprojects
pose we first move the whole repo and then extract projects if
> people
> > like this.
> > It is much easier to do the extraction based on a git project.
> >
> > Christian
> >
> > Am Sa., 2. Nov. 2019 um 13:21 Uhr schrieb Jean-Baptiste Onofré <
> > j...@nanthrax.net
I’m not exactly active currently, but +1
David Jencks
> On Nov 2, 2019, at 5:41 AM, Christian Schneider
> wrote:
>
> I propose we first move the whole repo and then extract projects if people
> like this.
> It is much easier to do the extraction based on a git project.
>
Thanks you for bringing this up again. I wanted to do this for a while now.
I'm for moving to git (as one project). Let us wait a little in case
somebody has strong objections but if not, I'll call a vote on it
soon.
regards,
Karl
On Sat, Nov 2, 2019 at 10:06 AM Christian Schneider
wrote
+1
-Georg
On 2019-11-02 13:41, Christian Schneider wrote:
I propose we first move the whole repo and then extract projects if
people
like this.
It is much easier to do the extraction based on a git project.
Christian
Am Sa., 2. Nov. 2019 um 13:21 Uhr schrieb Jean-Baptiste Onofré <
05.09.2019 um 07:19 schrieb Jean-Baptiste Onofré :
Hi,
I know that we can "force" sync on gitbox.apache.org when using git as
"master" repository.
As we are using svn backend, we have to ask to INFRA IMHO.
Regards
JB
On 05/09/2019 07:08, Carsten Ziegeler wrote:
It seems ou
like this.
> > It is much easier to do the extraction based on a git project.
> >
> > Christian
> >
> > Am Sa., 2. Nov. 2019 um 13:21 Uhr schrieb Jean-Baptiste Onofré <
> > j...@nanthrax.net>:
> >
> >> +1
> >>
> >> The question
It sounds like a plan ;)
+1
Regards
JB
On 02/11/2019 13:41, Christian Schneider wrote:
> I propose we first move the whole repo and then extract projects if people
> like this.
> It is much easier to do the extraction based on a git project.
>
> Christian
>
> Am Sa., 2. N
I propose we first move the whole repo and then extract projects if people
like this.
It is much easier to do the extraction based on a git project.
Christian
Am Sa., 2. Nov. 2019 um 13:21 Uhr schrieb Jean-Baptiste Onofré <
j...@nanthrax.net>:
> +1
>
> The question is: do we
+1
The question is: do we keep an unique repository for all felix projects
or we create one git repo per project.
I would prefer to have one dedicated git repo per project
(felix-framework, felix-configadmin, etc).
Regards
JB
On 02/11/2019 10:06, Christian Schneider wrote:
> In the past
I think it would be very nice to move Felix source code to git!
regards,
François
fpa...@apache.org
Le 02/11/2019 à 10:06, Christian Schneider a écrit :
> In the past we discussed a few times about moving felix to git.
>
> A while ago we did this step for Aries and it was sim
In the past we discussed a few times about moving felix to git.
A while ago we did this step for Aries and it was simpler than anticipated.
The problem in Aries were the remaining small bundles and subprojects that
were released by bundle. The larger sub projects were already moved out
Vielen Dank für Ihre Nachricht.
Ich bin ab dem 09.09.2019 wieder im per Mail erreichbar.
In dringenden Fällen wenden sie sich bitte an jschoet...@apollon.de
Mit freundlichen Grüssen
Sascha Homeier
P. +84 166 456-3331
shome...@apollon.de
apollon GmbH+Co. KG
Maximilianstr. 104
75172 Pforzheim
Vielen Dank für Ihre Nachricht.
Ich bin ab dem 09.09.2019 wieder im per Mail erreichbar.
In dringenden Fällen wenden sie sich bitte an jschoet...@apollon.de
Mit freundlichen Grüssen
Sascha Homeier
P. +84 166 456-3331
shome...@apollon.de
apollon GmbH+Co. KG
Maximilianstr. 104
75172 Pforzheim
Vielen Dank für Ihre Nachricht.
Ich bin ab dem 09.09.2019 wieder im per Mail erreichbar.
In dringenden Fällen wenden sie sich bitte an jschoet...@apollon.de
Mit freundlichen Grüssen
Sascha Homeier
P. +84 166 456-3331
shome...@apollon.de
apollon GmbH+Co. KG
Maximilianstr. 104
75172 Pforzheim
Hi, this is a known issue: https://status.apache.org/
Konrad
> Am 05.09.2019 um 07:19 schrieb Jean-Baptiste Onofré :
>
> Hi,
>
> I know that we can "force" sync on gitbox.apache.org when using git as
> "master" repository.
>
> As we are usi
Hi,
I know that we can "force" sync on gitbox.apache.org when using git as
"master" repository.
As we are using svn backend, we have to ask to INFRA IMHO.
Regards
JB
On 05/09/2019 07:08, Carsten Ziegeler wrote:
> It seems our github mirror is out of sync. Last commit is
[IF YOUR PROJECT DOES NOT HAVE GIT REPOSITORIES ON GIT-WIP-US PLEASE
DISREGARD THIS EMAIL; IT WAS MASS-MAILED TO ALL APACHE PROJECTS]
Hello Apache projects,
I am writing to you because you may have git repositories on the
git-wip-us server, which is slated to be decommissioned in the coming
FYI I've reported to infra that the git repo sync appears stopped, or the
link is broken:
https://issues.apache.org/jira/browse/INFRA-12720
--
*Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
(@rotty3000)
Senior Software Architect *Liferay, Inc.* <http://www.li
rote:
>>>
>>>
> https://cwiki.apache.org/confluence/display/~bimargul...@gmail.com/Felix+and+Git
>>>
>>> ?
>>
>> Seems like a good start, although is that editable by others?
>
> I don't know. Try? I don't have perms to make a page on the
> On Dec 1, 2015, at 17:50, Benson Margulies <bimargul...@gmail.com> wrote:
>
> https://cwiki.apache.org/confluence/display/~bimargul...@gmail.com/Felix+and+Git
>
> ?
Seems like a good start, although is that editable by others?
It seems like other technical iss
On Dec 1, 2015 6:43 PM, "Richard S. Hall" <he...@ungoverned.org> wrote:
>
>
> > On Dec 1, 2015, at 17:50, Benson Margulies <bimargul...@gmail.com>
wrote:
> >
> >
https://cwiki.apache.org/confluence/display/~bimargul...@gmail.com/Felix+and+Git
&
https://cwiki.apache.org/confluence/display/~bimargul...@gmail.com/Felix+and+Git
?
On Tue, Dec 1, 2015 at 1:56 PM, Richard S. Hall <he...@ungoverned.org> wrote:
> On 12/1/15 13:40 , Carsten Ziegeler wrote:
>>
>> Richard S. Hall wrote
>>>
>>> Well,
On Tue, Dec 1, 2015 at 7:50 PM, David Jencks <david.a.jen...@gmail.com> wrote:
> I also see no way to edit your page, and I have no idea who might be a
> confluence space administrator who could change permissions.
>
> I was going to add to the pro-single-git-repo the point
I also see no way to edit your page, and I have no idea who might be a
confluence space administrator who could change permissions.
I was going to add to the pro-single-git-repo the point that you can check out
exactly the parts you want using git sparse-checkout.
I don’t think the decision
gt; I also see no way to edit your page, and I have no idea who might be a
>> confluence space administrator who could change permissions.
>>
>> I was going to add to the pro-single-git-repo the point that you can check
>> out exactly the parts you want using git sparse-check
We at Pentaho made the migration to Git and GitHub from Subversion and
Perforce a few years ago now. At the time we decided to go with multiple
repositories (we're at around 100 right now). In retrospect this was a
large mistake.
Development often spans multiple repositories creating dependent
Hello Benson,
There is, at least, substantial apathy about git on the part of the
sub-communities that work on some of the sub-projects. In my view,
this apathy, including perhaps a bit of antipathy, sunk the discussion
of just converting as one big repo. As I see it, Felix is a bit
On Tue, Dec 1, 2015 at 11:43 AM, Marcel Offermans
<marcel.offerm...@luminis.nl> wrote:
> Hello Benson,
>
> There is, at least, substantial apathy about git on the part of the
> sub-communities that work on some of the sub-projects. In my view,
> this apathy, including perha
Marcel Offermans wrote
>
> Let me speak for myself here, I don’t see compelling arguments for moving to
> Git. What problem are we solving here? Why is moving to Git the right
> solution?
> That’s where my lack of enthusiasm comes from. Nobody has yet explained that
> to
On 12/1/15 12:57 , Carsten Ziegeler wrote:
Marcel Offermans wrote
Let me speak for myself here, I don’t see compelling arguments for moving to
Git. What problem are we solving here? Why is moving to Git the right solution?
That’s where my lack of enthusiasm comes from. Nobody has yet
with Marcel...all or nothing makes
more sense.
Hmm, ok fair point - however, the *all* is the problematic part where we
couldn't agree on last time (one git repo vs many git repos).
But isn't it then incumbent on those wanting such changes to convince us
one way or the other?
Personally, I'd rather just
sus to do that?
>
> I don't want to be a PITA, but would you care about writing a more
> detailed description of what that would mean? (git repo name, how it is
> set up) I'm actually not sure what it would need as a description but
> definitely a little bit more than just saying
Benson Margulies wrote
> I would like to peel the bundle plugin. Does any pmc member sympathize
> sufficiently to start a vote to test consensus to do that?
I don't want to be a PITA, but would you care about writing a more
detailed description of what that would mean? (git repo nam
Here's how I'd call the vote:
This is a vote to move the reference source of the maven-bundle-plugin to git.
To be specific,
- http://git.apache.org/ will list the repository as
'felix-maven-bundle-plugin.git' (because all repo names start with
their project name).
- all existing history
I apologize for losing track of this whole discussion. I don’t recall seeing a
convincing to me reason to have, at least initially, more than one git repo.
Wasn’t there even a new git feature that let you check out only part of a
project?
However many repos we decide on, I’m in favor of git
It sure seems as if there are no PMC members fond enough of the git
idea to call a vote. I'm treating this as a dead topic for now.
U ok.. let me see if I can belatedly recapture the brilliance..
I think it was simply the observation that if the end result was to have
many repos, couldn't each subproject just start pealing itself off into a
git repo as it sees fit?
Call it lazy migration if you will.
The side effects
iance..
>
> I think it was simply the observation that if the end result was to have
> many repos, couldn't each subproject just start pealing itself off into a
> git repo as it sees fit?
>
> Call it lazy migration if you will.
>
> The side effects are going to be limited to tho
Benson Margulies wrote
> It sure seems as if there are no PMC members fond enough of the git
> idea to call a vote. I'm treating this as a dead topic for now.
>
Looks like :(
I had a brief discussion two weeks ago with Ray, and he had an
interesting idea. @Ray do you want to br
David Jencks wrote
> I apologize for losing track of this whole discussion. I don’t recall seeing
> a convincing to me reason to have, at least initially, more than one git
> repo. Wasn’t there even a new git feature that let you check out only part
> of a project?
>
> How
David,
There is, at least, substantial apathy about git on the part of the
sub-communities that work on some of the sub-projects. In my view,
this apathy, including perhaps a bit of antipathy, sunk the discussion
of just converting as one big repo. As I see it, Felix is a bit of a
loose
Benson Margulies wrote
> Here's how I'd call the vote:
>
> This is a vote to move the reference source of the maven-bundle-plugin to git.
>
> To be specific,
>
> - http://git.apache.org/ will list the repository as
> 'felix-maven-bundle-plugin.git' (beca
On Tue, Dec 1, 2015 at 11:16 AM, Carsten Ziegeler <cziege...@apache.org> wrote:
> Benson Margulies wrote
>> Here's how I'd call the vote:
>>
>> This is a vote to move the reference source of the maven-bundle-plugin to
>> git.
>>
>> To be speci
+1
2015-11-02 13:24 GMT+01:00 Marcel Offermans <marcel.offerm...@luminis.nl>:
> I would be more comfortable if we first had someone volunteer to adapt all
> (Maven and Ant/Gradle based builds) to work with Git and otherwise ensure
> that all projects keep working. Then
omise is to have less repos than
> releasable items (possibly as few as one repo), I'd personally rather
> do that than not move to git at all.
>
> regards,
>
> benson
>
>
> On Sat, Oct 24, 2015 at 2:43 PM, Marcel Offermans
> <marcel.offerm...@luminis.nl> wrot
m...@luminis.nl>
>> wrote:
>>
>> > I would be more comfortable if we first had someone volunteer to adapt
>> all
>> > (Maven and Ant/Gradle based builds) to work with Git and otherwise ensure
>> > that all projects keep working. Then demonstrate all
gt; > (Maven and Ant/Gradle based builds) to work with Git and otherwise ensure
> > that all projects keep working. Then demonstrate all of that (with a copy
> > of our repository), and update our documentation to reflect the new
> > processes before we decide on making such a move.
I would be more comfortable if we first had someone volunteer to adapt all
(Maven and Ant/Gradle based builds) to work with Git and otherwise ensure that
all projects keep working. Then demonstrate all of that (with a copy of our
repository), and update our documentation to reflect the new
based builds) to work with Git and otherwise ensure
> that all projects keep working. Then demonstrate all of that (with a copy
> of our repository), and update our documentation to reflect the new
> processes before we decide on making such a move. I have a feeling this is
> going to be a lo
; > opinion there are imho good/valid arguments. I have the feeling that a
> > formal vote does not lead us anywhere.
> >
> > Maybe someone can clearly identify/list the benefits for everyone if we
> > move from svn to a single git repo - compared to using th
e conversion".
I don't see a clear consensus/agreement on any of the three. For each
opinion there are imho good/valid arguments. I have the feeling that a
formal vote does not lead us anywhere.
Maybe someone can clearly identify/list the benefits for everyone if we
move from svn to a single g
e does not lead us anywhere.
>
> Maybe someone can clearly identify/list the benefits for everyone if we
> move from svn to a single git repo - compared to using the already
> existing git proxy. I think this should give everyone a clear view of
> why the migration makes sense. And if there
nion there are imho good/valid arguments. I have the feeling that a
>> formal vote does not lead us anywhere.
>>
>> Maybe someone can clearly identify/list the benefits for everyone if we
>> move from svn to a single git repo - compared to using the already
>> exist
i'm for a move to git as well.
concerning the options listed by carsten:
"b) create git repos by functional modules" makes sense if all modules
belonging to a "function" are released together, this is not everywhere the
case currently. if we release them independently we vi
ng a switch because it’s also a lot of work and I don’t think
>> the benefits are huge. If it works, don’t fix it. :)
>
> +1 to that. Side-line for me too.
>
> SVN isn't that bad after all, and along with 'git svn' most of the
> benefits of git (quick local branching/fast
l, and along with 'git svn' most of the
benefits of git (quick local branching/fast commit history etc) can be
realized locally by developers.
Not that imp but for me at times the linear progressing svn revision
feels more useful to determine if a particular CL made it to a
particular released.
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
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
1 - 100 of 155 matches
Mail list logo
