[discuss] Vote to git it?

classic Classic list List threaded Threaded
34 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[discuss] Vote to git it?

garydgregory
Should we vote to move Commons to git one component at a time (as Math just
has), or just vote to move them all at once and be done with it and the
inevitable?

Gary

--
E-Mail: [hidden email] | [hidden email]
Java Persistence with Hibernate, Second Edition
<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Reply | Threaded
Open this post in threaded view
|

Re: [discuss] Vote to git it?

Emmanuel Bourg-3
Le 09/09/2014 15:10, Gary Gregory a écrit :
> Should we vote to move Commons to git one component at a time (as Math just
> has), or just vote to move them all at once and be done with it and the
> inevitable?

I'm fine with both solutions. Do we have a consensus to migrate the
components now?

Emmanuel Bourg


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [discuss] Vote to git it?

sebb-2-2
In reply to this post by garydgregory
On 9 September 2014 14:10, Gary Gregory <[hidden email]> wrote:
> Should we vote to move Commons to git one component at a time (as Math just
> has), or just vote to move them all at once and be done with it and the
> inevitable?

I think it is far too early to decide.
Math has yet to start using git in earnest.

Let's not try to run before we have even learnt to crawl.

> Gary
>
> --
> E-Mail: [hidden email] | [hidden email]
> Java Persistence with Hibernate, Second Edition
> <http://www.manning.com/bauer3/>
> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> Spring Batch in Action <http://www.manning.com/templier/>
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [discuss] Vote to git it?

garydgregory
On Tue, Sep 9, 2014 at 9:17 AM, sebb <[hidden email]> wrote:

> On 9 September 2014 14:10, Gary Gregory <[hidden email]> wrote:
> > Should we vote to move Commons to git one component at a time (as Math
> just
> > has), or just vote to move them all at once and be done with it and the
> > inevitable?
>
> I think it is far too early to decide.
> Math has yet to start using git in earnest.
>
> Let's not try to run before we have even learnt to crawl.
>

At Log4j 2, we've switched, and so far so good.

Gary


> > Gary
> >
> > --
> > E-Mail: [hidden email] | [hidden email]
> > Java Persistence with Hibernate, Second Edition
> > <http://www.manning.com/bauer3/>
> > JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> > Spring Batch in Action <http://www.manning.com/templier/>
> > Blog: http://garygregory.wordpress.com
> > Home: http://garygregory.com/
> > Tweet! http://twitter.com/GaryGregory
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
E-Mail: [hidden email] | [hidden email]
Java Persistence with Hibernate, Second Edition
<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Reply | Threaded
Open this post in threaded view
|

Re: [discuss] Vote to git it?

garydgregory
In reply to this post by Emmanuel Bourg-3
On Tue, Sep 9, 2014 at 9:17 AM, Emmanuel Bourg <[hidden email]> wrote:

> Le 09/09/2014 15:10, Gary Gregory a écrit :
> > Should we vote to move Commons to git one component at a time (as Math
> just
> > has), or just vote to move them all at once and be done with it and the
> > inevitable?
>
> I'm fine with both solutions. Do we have a consensus to migrate the
> components now?
>

I started this thread to get a feel for it. Some folks have a lot of
experience with git, some have none. Most of us here know Subversion 'by
default'. Understanding that and the comfort of folks of do not know git
and their willingness to get into a new VCS is what I am trying to
understand. I do not want to call a [vote] with out talking first.

Gary


> Emmanuel Bourg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
E-Mail: [hidden email] | [hidden email]
Java Persistence with Hibernate, Second Edition
<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Reply | Threaded
Open this post in threaded view
|

Re: [discuss] Vote to git it?

sebb-2-2
In reply to this post by garydgregory
On 9 September 2014 15:32, Gary Gregory <[hidden email]> wrote:

> On Tue, Sep 9, 2014 at 9:17 AM, sebb <[hidden email]> wrote:
>
>> On 9 September 2014 14:10, Gary Gregory <[hidden email]> wrote:
>> > Should we vote to move Commons to git one component at a time (as Math
>> just
>> > has), or just vote to move them all at once and be done with it and the
>> > inevitable?
>>
>> I think it is far too early to decide.
>> Math has yet to start using git in earnest.
>>
>> Let's not try to run before we have even learnt to crawl.
>>
>
> At Log4j 2, we've switched, and so far so good.

But AFAIK, there is not yet any Commons documentation on how to do
things in Git.
Nor what conventions we should use where there are different ways to do things.

> Gary
>
>
>> > Gary
>> >
>> > --
>> > E-Mail: [hidden email] | [hidden email]
>> > Java Persistence with Hibernate, Second Edition
>> > <http://www.manning.com/bauer3/>
>> > JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>> > Spring Batch in Action <http://www.manning.com/templier/>
>> > Blog: http://garygregory.wordpress.com
>> > Home: http://garygregory.com/
>> > Tweet! http://twitter.com/GaryGregory
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
>
> --
> E-Mail: [hidden email] | [hidden email]
> Java Persistence with Hibernate, Second Edition
> <http://www.manning.com/bauer3/>
> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> Spring Batch in Action <http://www.manning.com/templier/>
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [discuss] Vote to git it?

Paul Benedict
Is there an itch to scratch (need) by moving to git as opposed to just
continue using svn?


Cheers,
Paul

On Tue, Sep 9, 2014 at 9:49 AM, sebb <[hidden email]> wrote:

> On 9 September 2014 15:32, Gary Gregory <[hidden email]> wrote:
> > On Tue, Sep 9, 2014 at 9:17 AM, sebb <[hidden email]> wrote:
> >
> >> On 9 September 2014 14:10, Gary Gregory <[hidden email]> wrote:
> >> > Should we vote to move Commons to git one component at a time (as Math
> >> just
> >> > has), or just vote to move them all at once and be done with it and
> the
> >> > inevitable?
> >>
> >> I think it is far too early to decide.
> >> Math has yet to start using git in earnest.
> >>
> >> Let's not try to run before we have even learnt to crawl.
> >>
> >
> > At Log4j 2, we've switched, and so far so good.
>
> But AFAIK, there is not yet any Commons documentation on how to do
> things in Git.
> Nor what conventions we should use where there are different ways to do
> things.
>
> > Gary
> >
> >
> >> > Gary
> >> >
> >> > --
> >> > E-Mail: [hidden email] | [hidden email]
> >> > Java Persistence with Hibernate, Second Edition
> >> > <http://www.manning.com/bauer3/>
> >> > JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> >> > Spring Batch in Action <http://www.manning.com/templier/>
> >> > Blog: http://garygregory.wordpress.com
> >> > Home: http://garygregory.com/
> >> > Tweet! http://twitter.com/GaryGregory
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: [hidden email]
> >> For additional commands, e-mail: [hidden email]
> >>
> >>
> >
> >
> > --
> > E-Mail: [hidden email] | [hidden email]
> > Java Persistence with Hibernate, Second Edition
> > <http://www.manning.com/bauer3/>
> > JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> > Spring Batch in Action <http://www.manning.com/templier/>
> > Blog: http://garygregory.wordpress.com
> > Home: http://garygregory.com/
> > Tweet! http://twitter.com/GaryGregory
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [discuss] Vote to git it?

Emmanuel Bourg-3
In reply to this post by sebb-2-2
Le 09/09/2014 16:49, sebb a écrit :

> But AFAIK, there is not yet any Commons documentation on how to do
> things in Git.
> Nor what conventions we should use where there are different ways to do things.

The development workflow is another topic, but I don't think we should
change our habits. That is, development occurs on the master branch,
branches are created when needed (experimental work, maintenance
branches, etc).

Emmanuel Bourg


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [discuss] Vote to git it?

Emmanuel Bourg-3
In reply to this post by garydgregory
Le 09/09/2014 16:35, Gary Gregory a écrit :

> I started this thread to get a feel for it. Some folks have a lot of
> experience with git, some have none. Most of us here know Subversion 'by
> default'. Understanding that and the comfort of folks of do not know git
> and their willingness to get into a new VCS is what I am trying to
> understand. I do not want to call a [vote] with out talking first.

The last time we voted there were 4 people opposed. I tried to summarize
the objections (please correct if I'm wrong):

Mark Thomas: not needed, not fully thought out, trial with one component
Thomas Vandahl: doesn't see any advantage
Damjan Jovanovic: trial with one component first
Gilles Sadowski: doesn't solve any problem, not used to the tool

Emmanuel Bourg


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [discuss] Vote to git it?

sebb-2-2
In reply to this post by Emmanuel Bourg-3
On 9 September 2014 16:05, Emmanuel Bourg <[hidden email]> wrote:

> Le 09/09/2014 16:49, sebb a écrit :
>
>> But AFAIK, there is not yet any Commons documentation on how to do
>> things in Git.
>> Nor what conventions we should use where there are different ways to do things.
>
> The development workflow is another topic, but I don't think we should
> change our habits. That is, development occurs on the master branch,
> branches are created when needed (experimental work, maintenance
> branches, etc).

I meant git-specific things like when to rebase etc.

> Emmanuel Bourg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [discuss] Vote to git it?

Emmanuel Bourg-3
In reply to this post by Paul Benedict
Le 09/09/2014 16:52, Paul Benedict a écrit :
> Is there an itch to scratch (need) by moving to git as opposed to just
> continue using svn?

I guess the "itch" is simply an increasing preference for Git among the
people involved here. I don't think the migration will fix any important
problem.

Emmanuel Bourg


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [discuss] Vote to git it?

garydgregory
On Tue, Sep 9, 2014 at 11:27 AM, Emmanuel Bourg <[hidden email]> wrote:

> Le 09/09/2014 16:52, Paul Benedict a écrit :
> > Is there an itch to scratch (need) by moving to git as opposed to just
> > continue using svn?
>
> I guess the "itch" is simply an increasing preference for Git among the
> people involved here. I don't think the migration will fix any important
> problem.
>

One thing that is a PITA is when getting pull requests from GitHub. The GH
patches are not usable as it.

Gary



>
> Emmanuel Bourg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
E-Mail: [hidden email] | [hidden email]
Java Persistence with Hibernate, Second Edition
<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Reply | Threaded
Open this post in threaded view
|

Re: [discuss] Vote to git it?

Mark Fortner-3
In reply to this post by Emmanuel Bourg-3
If I had to pick one feature that makes git more useful than svn, it would
be the ease in creating feature branches.  If you want to add a feature,
you simply create a local branch to implement the feature, implement it,
and commit it, and create a pull request.  If you're using Atlassian's
Crucible or Stash, it's pretty easy to do a code review of the pull
request.

Feature branching makes it easy for developers to get their feet wet with a
code base. You can try out experiments.  Have branches for each experiment.
 It makes it easier to attract new developers to a project.

From the previous discussion thread, it seems like the main objections were
(paraphrasing a bit here):

   - I'm not familiar with git. I've got a process that works for me and I
   don't want to change it.
   - I don't see the value in it.
   - We don't know the impact on the release process.


In order to address these concerns, it makes sense to try it out on a
project.  The next question is -- which project.  The project needs to be
central enough that everyone has some skin in the game.  It should be a
project that you have an interest in.  If you haven't used git before, then
you need to try implementing a feature in that project. The project lead
should also be someone who's familiar with git, and feels comfortable with
answering questions about git.

I think if we can identify a project, and get commitment from everyone who
hasn't tried git, to add a small feature, add some comments, or add a unit
test, we'll learn enough.  The project lead can look at the impact on the
release process, and report any findings.  At least at that point, we'll
have learned enough from the process to make an informed decision.


Regards,

Mark



On Tue, Sep 9, 2014 at 8:27 AM, Emmanuel Bourg <[hidden email]> wrote:

> Le 09/09/2014 16:52, Paul Benedict a écrit :
> > Is there an itch to scratch (need) by moving to git as opposed to just
> > continue using svn?
>
> I guess the "itch" is simply an increasing preference for Git among the
> people involved here. I don't think the migration will fix any important
> problem.
>
> Emmanuel Bourg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [discuss] Vote to git it?

Mark Fortner-3
In reply to this post by garydgregory
Gary,

<snip>
One thing that is a PITA is when getting pull requests from GitHub. The GH
patches are not usable as it.
</snip>

Atlassian's Stash makes that easier to deal with. This video describes a
fork-based workflow using Stash, and shows you how code reviews work.  It
also means that people can contribute to projects without having commit
access to the project.  They just submit a pull request to the project.
http://youtu.be/JYC9yDJ0dZo


Cheers,

Mark
Reply | Threaded
Open this post in threaded view
|

Re: [discuss] Vote to git it?

Schalk Cronjé
In reply to this post by Mark Fortner-3
On 09/09/2014 16:57, Mark Fortner wrote:
> If I had to pick one feature that makes git more useful than svn, it would
> be the ease in creating feature branches.  If you want to add a feature,
> you simply create a local branch to implement the feature, implement it,
> and commit it, and create a pull request.  If you're using Atlassian's
> Crucible or Stash, it's pretty easy to do a code review of the pull
> request.
For me that is the killer feature of Git where it beats Subversion
hands-down.

Personally I also find that performing a code review of a pull request
on Github easy enough.

--
Schalk W. Cronjé
@ysb33r


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [discuss] Vote to git it?

Mark Fortner-3
Schalk,
The only problem I see with the way that you do code reviews on Github, is
the fact that you can only review change sets.  You can't simply go through
an existing codebase and point out the problems.  I suggested Stash and
Crucible since they're both linked with JIRA, and I think Apache has free
access to Atlassian's stack for its projects

Cheers,

Mark



On Tue, Sep 9, 2014 at 10:15 AM, Schalk Cronj é <[hidden email]> wrote:

> On 09/09/2014 16:57, Mark Fortner wrote:
>
>> If I had to pick one feature that makes git more useful than svn, it would
>> be the ease in creating feature branches.  If you want to add a feature,
>> you simply create a local branch to implement the feature, implement it,
>> and commit it, and create a pull request.  If you're using Atlassian's
>> Crucible or Stash, it's pretty easy to do a code review of the pull
>> request.
>>
> For me that is the killer feature of Git where it beats Subversion
> hands-down.
>
> Personally I also find that performing a code review of a pull request on
> Github easy enough.
>
> --
> Schalk W. Cronjé
> @ysb33r
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [discuss] Vote to git it?

Paul Benedict
In reply to this post by Mark Fortner-3
Mark, can you help me understand why git branches (the "feature" branch) is
better than an svn branch?


Cheers,
Paul

On Tue, Sep 9, 2014 at 10:57 AM, Mark Fortner <[hidden email]> wrote:

> If I had to pick one feature that makes git more useful than svn, it would
> be the ease in creating feature branches.  If you want to add a feature,
> you simply create a local branch to implement the feature, implement it,
> and commit it, and create a pull request.  If you're using Atlassian's
> Crucible or Stash, it's pretty easy to do a code review of the pull
> request.
>
> Feature branching makes it easy for developers to get their feet wet with a
> code base. You can try out experiments.  Have branches for each experiment.
>  It makes it easier to attract new developers to a project.
>
> From the previous discussion thread, it seems like the main objections were
> (paraphrasing a bit here):
>
>    - I'm not familiar with git. I've got a process that works for me and I
>    don't want to change it.
>    - I don't see the value in it.
>    - We don't know the impact on the release process.
>
>
> In order to address these concerns, it makes sense to try it out on a
> project.  The next question is -- which project.  The project needs to be
> central enough that everyone has some skin in the game.  It should be a
> project that you have an interest in.  If you haven't used git before, then
> you need to try implementing a feature in that project. The project lead
> should also be someone who's familiar with git, and feels comfortable with
> answering questions about git.
>
> I think if we can identify a project, and get commitment from everyone who
> hasn't tried git, to add a small feature, add some comments, or add a unit
> test, we'll learn enough.  The project lead can look at the impact on the
> release process, and report any findings.  At least at that point, we'll
> have learned enough from the process to make an informed decision.
>
>
> Regards,
>
> Mark
>
>
>
> On Tue, Sep 9, 2014 at 8:27 AM, Emmanuel Bourg <[hidden email]> wrote:
>
> > Le 09/09/2014 16:52, Paul Benedict a écrit :
> > > Is there an itch to scratch (need) by moving to git as opposed to just
> > > continue using svn?
> >
> > I guess the "itch" is simply an increasing preference for Git among the
> > people involved here. I don't think the migration will fix any important
> > problem.
> >
> > Emmanuel Bourg
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: [discuss] Vote to git it?

Luc Maisonobe-2
In reply to this post by sebb-2-2
Le 09/09/2014 15:17, sebb a écrit :
> On 9 September 2014 14:10, Gary Gregory <[hidden email]> wrote:
>> Should we vote to move Commons to git one component at a time (as Math just
>> has), or just vote to move them all at once and be done with it and the
>> inevitable?
>
> I think it is far too early to decide.
> Math has yet to start using git in earnest.

I agree with this.

I think I am fairly at ease with git by now (having used it for about 3
years I think), but I also remember there are a lot of things to learn.
So the [math] experiment is worth doing and we can try to iron a few
things for the other components. One specific task will probably be
challenging: doing a release. There are some magics with subversion done
by maven in our components and we need the same kind of magic with git.
Once we have done that and documented what we have done, it will
probably be time to discuss about other components switching or not.

best regards,
Luc

>
> Let's not try to run before we have even learnt to crawl.
>
>> Gary
>>
>> --
>> E-Mail: [hidden email] | [hidden email]
>> Java Persistence with Hibernate, Second Edition
>> <http://www.manning.com/bauer3/>
>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>> Spring Batch in Action <http://www.manning.com/templier/>
>> Blog: http://garygregory.wordpress.com
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [discuss] Vote to git it?

Mark Fortner-3
In reply to this post by Paul Benedict
Paul,
Git branching is faster, computationally cheaper, and requires less disk
space than svn branching.  This link provides more information:
https://git.wiki.kernel.org/index.php/GitSvnComparison.

In git, you have a remote repo, and a local repo.  Typically, people create
local branches for experiments or new features and then merge and create
pull-requests whenever they have something that they want to share with the
community.  In svn, whenever you branch, you're branching on the server
first.  Usually, if you're new to a code base, you don't want to do that if
you're just experimenting.  Ideally, you want to encourage experimentation
(and attract new developers), so "feature branches" make a lot of sense in
that context.

Cheers,

Mark



On Tue, Sep 9, 2014 at 10:46 AM, Paul Benedict <[hidden email]> wrote:

> Mark, can you help me understand why git branches (the "feature" branch) is
> better than an svn branch?
>
>
> Cheers,
> Paul
>
> On Tue, Sep 9, 2014 at 10:57 AM, Mark Fortner <[hidden email]> wrote:
>
> > If I had to pick one feature that makes git more useful than svn, it
> would
> > be the ease in creating feature branches.  If you want to add a feature,
> > you simply create a local branch to implement the feature, implement it,
> > and commit it, and create a pull request.  If you're using Atlassian's
> > Crucible or Stash, it's pretty easy to do a code review of the pull
> > request.
> >
> > Feature branching makes it easy for developers to get their feet wet
> with a
> > code base. You can try out experiments.  Have branches for each
> experiment.
> >  It makes it easier to attract new developers to a project.
> >
> > From the previous discussion thread, it seems like the main objections
> were
> > (paraphrasing a bit here):
> >
> >    - I'm not familiar with git. I've got a process that works for me and
> I
> >    don't want to change it.
> >    - I don't see the value in it.
> >    - We don't know the impact on the release process.
> >
> >
> > In order to address these concerns, it makes sense to try it out on a
> > project.  The next question is -- which project.  The project needs to be
> > central enough that everyone has some skin in the game.  It should be a
> > project that you have an interest in.  If you haven't used git before,
> then
> > you need to try implementing a feature in that project. The project lead
> > should also be someone who's familiar with git, and feels comfortable
> with
> > answering questions about git.
> >
> > I think if we can identify a project, and get commitment from everyone
> who
> > hasn't tried git, to add a small feature, add some comments, or add a
> unit
> > test, we'll learn enough.  The project lead can look at the impact on the
> > release process, and report any findings.  At least at that point, we'll
> > have learned enough from the process to make an informed decision.
> >
> >
> > Regards,
> >
> > Mark
> >
> >
> >
> > On Tue, Sep 9, 2014 at 8:27 AM, Emmanuel Bourg <[hidden email]>
> wrote:
> >
> > > Le 09/09/2014 16:52, Paul Benedict a écrit :
> > > > Is there an itch to scratch (need) by moving to git as opposed to
> just
> > > > continue using svn?
> > >
> > > I guess the "itch" is simply an increasing preference for Git among the
> > > people involved here. I don't think the migration will fix any
> important
> > > problem.
> > >
> > > Emmanuel Bourg
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [hidden email]
> > > For additional commands, e-mail: [hidden email]
> > >
> > >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: [discuss] Vote to git it?

Oliver Heger-3
In reply to this post by Luc Maisonobe-2


On 09.09.2014 19:56, Luc Maisonobe wrote:

> Le 09/09/2014 15:17, sebb a écrit :
>> On 9 September 2014 14:10, Gary Gregory <[hidden email]> wrote:
>>> Should we vote to move Commons to git one component at a time (as Math just
>>> has), or just vote to move them all at once and be done with it and the
>>> inevitable?
>>
>> I think it is far too early to decide.
>> Math has yet to start using git in earnest.
>
> I agree with this.
>
> I think I am fairly at ease with git by now (having used it for about 3
> years I think), but I also remember there are a lot of things to learn.
> So the [math] experiment is worth doing and we can try to iron a few
> things for the other components. One specific task will probably be
> challenging: doing a release. There are some magics with subversion done
> by maven in our components and we need the same kind of magic with git.
> Once we have done that and documented what we have done, it will
> probably be time to discuss about other components switching or not.

+1

Our decision was to use [math] as a test balloon, so let's be consequent
and wait for first results.

I also understand that Gary wants to push things forward. So maybe we
can agree on a kind of time frame? Is there a release pending for
[math]? Or can you estimate how long you need to come to a decision?

Oliver

>
> best regards,
> Luc
>
>>
>> Let's not try to run before we have even learnt to crawl.
>>
>>> Gary
>>>
>>> --
>>> E-Mail: [hidden email] | [hidden email]
>>> Java Persistence with Hibernate, Second Edition
>>> <http://www.manning.com/bauer3/>
>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>>> Spring Batch in Action <http://www.manning.com/templier/>
>>> Blog: http://garygregory.wordpress.com
>>> Home: http://garygregory.com/
>>> Tweet! http://twitter.com/GaryGregory
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

12