You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flex.apache.org by Erik de Bruin <er...@ixsoftware.nl> on 2012/11/22 16:46:01 UTC
Planning for Git
Since we can't indefinitely postpone the inevitable, I think we should
start to plan for the move to Git. I think at least these points
should be addressed (if they haven't already been, in which case they
should be documented such that they can be easily referenced, e.g. on
the Wiki):
1) once Git becomes available, does SVN become unavailable right away,
or will both repos be able to coexist for a while (both being able to
receive updates and updating the other when they do)?
2) several committers are "on loan" from Adobe for a very specific
goal (Peter and Gordon). Are they comfortable working with Git,
willing and able (in that they have enough time available to do so) to
learn Git, or would moving to Git mean that they are no longer able to
contribute?
3) what workflow does the project use (reading about Git, it seems
like there are endless possibilities), do we need to vote on that and
how do we 'enforce' one over the other? Also, this workflow needs to
be embedded in all the READMEs and the website, just like the SVN
workflow is now.
4) some technical aspects of the project are tied to SVN, like the
website with it's post-commit hook to the 'buildbot'. These apparently
have to stay with SVN, fragmenting the development environment. Are
there alternatives that will allow these types of services to move
over to Git as well?
5) is anyone aware of any technical issues with the codebase that are
specifically tied to SVN that need changing when the move happens
(can't think of any, but better safe than sorry)
That's all I've got now, just thought we needed a starting point and
I'm hoping this will help provide one.
EdB
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
RE: Planning for Git
Posted by Gordon Smith <go...@adobe.com>.
> several committers are "on loan" from Adobe for a very specific goal (Peter and Gordon).
> Are they comfortable working with Git, willing and able (in that they have enough time available to do so) to learn Git,
> or would moving to Git mean that they are no longer able to contribute?
I don't look forward to switching to Git but I'll cope. The time to learn Git will come out of my Falcon development time.
- Gordon
-----Original Message-----
From: Erik de Bruin [mailto:erik@ixsoftware.nl]
Sent: Thursday, November 22, 2012 7:46 AM
To: flex-dev@incubator.apache.org
Subject: Planning for Git
Since we can't indefinitely postpone the inevitable, I think we should start to plan for the move to Git. I think at least these points should be addressed (if they haven't already been, in which case they should be documented such that they can be easily referenced, e.g. on the Wiki):
1) once Git becomes available, does SVN become unavailable right away, or will both repos be able to coexist for a while (both being able to receive updates and updating the other when they do)?
2) several committers are "on loan" from Adobe for a very specific goal (Peter and Gordon). Are they comfortable working with Git, willing and able (in that they have enough time available to do so) to learn Git, or would moving to Git mean that they are no longer able to contribute?
3) what workflow does the project use (reading about Git, it seems like there are endless possibilities), do we need to vote on that and how do we 'enforce' one over the other? Also, this workflow needs to be embedded in all the READMEs and the website, just like the SVN workflow is now.
4) some technical aspects of the project are tied to SVN, like the website with it's post-commit hook to the 'buildbot'. These apparently have to stay with SVN, fragmenting the development environment. Are there alternatives that will allow these types of services to move over to Git as well?
5) is anyone aware of any technical issues with the codebase that are specifically tied to SVN that need changing when the move happens (can't think of any, but better safe than sorry)
That's all I've got now, just thought we needed a starting point and I'm hoping this will help provide one.
EdB
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: Planning for Git
Posted by Omar Gonzalez <om...@gmail.com>.
On Thursday, November 22, 2012, Erik de Bruin wrote:
> > just as long as the CI Server supports that particular Repo type. I
> don't quite get what the "buildbot hooks" are needed for.
>
> The buildbot takes the content files and the templates for the website
> and automatically applies one to the other, uploading the resulting
> files to the staging site. The buildbot is essentially the Apache CMS,
> without it there is no way I know of to make changes to the website.
> Not something the project can do without.
>
> If access to SVN is shut down once Git is activated, we'll need to
> prepare an alternative…
>
> EdB
>
>
INFRA has defined ways to handle this, again, all the existing projects on
Git wouldn't be operating of they didn't, and Apache INFRA is not going to
reinvent the wheel each time thy migrate a project.
-Omar
>
>
> --
> Ix Multimedia Software
>
> Jan Luykenstraat 27
> 3521 VB Utrecht
>
> T. 06-51952295
> I. www.ixsoftware.nl
>
Re: Planning for Git
Posted by Erik de Bruin <er...@ixsoftware.nl>.
> just as long as the CI Server supports that particular Repo type. I don't quite get what the "buildbot hooks" are needed for.
The buildbot takes the content files and the templates for the website
and automatically applies one to the other, uploading the resulting
files to the staging site. The buildbot is essentially the Apache CMS,
without it there is no way I know of to make changes to the website.
Not something the project can do without.
If access to SVN is shut down once Git is activated, we'll need to
prepare an alternative…
EdB
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
AW: Planning for Git
Posted by "christofer.dutz@c-ware.de" <ch...@c-ware.de>.
A few days ago I thought I posted how the process for switching to the "wip-git" (Work In Progress - Git). I talked to Gavin from the
Infra team on the ApacheCon and he told me that:
It seems that all you have to do is to open an Issue at the INFRA team and request the SVN to be moved to the GIT at a given time.
The migration is actually done by pushing the read-only GIT-View of the SVN into a clean read-write git-repo.
After that they turn off access to the SVN to prevent the Repos from becoming unsynced.
I think the main problem is that one of the main benefits of GIT Solutions is the handling of Pull-Request. So those drive-by-patchers
create their custom branch, fix stuff there and then send a pull-request. The maintainers of the master Git usually have some
web-based tooling to allow reviewing the change and applying that to the main repo. I think this is where the Work-In-Progress is.
It's this tooling on top of Git that makes it so popular as you don't have to manually apply patch files. Without this tooling however
I doubt there is a really big benefit of using Git. At the moment I think the Git repo at Apache would be almost the same as the SVN
repo.
Usually the CI Servers are able to detect changes in the Repo and start builds, no matter if SVN, Git or whatsoever ...
just as long as the CI Server supports that particular Repo type. I don't quite get what the "buildbot hooks" are needed for.
As I mentioned in the other post ... Atlassian Stash would already support all the stuff we would need and it would integrate nicely
Into the rest of the Atlassian Tools we are already using. But I guess the Infra guys started working on their own solution and are
Currently struggling to get it feature-complete and are probably not thrilled of the option to throw away what they already built.
I guess that their solution will probably be optimized on the usage at the Apache foundation ... at least when it's finished.
Chris
-----Ursprüngliche Nachricht-----
Von: Omar Gonzalez [mailto:omarg.developer@gmail.com]
Gesendet: Donnerstag, 22. November 2012 18:20
An: flex-dev@incubator.apache.org
Betreff: Re: Planning for Git
On Thu, Nov 22, 2012 at 7:46 AM, Erik de Bruin <er...@ixsoftware.nl> wrote:
> Since we can't indefinitely postpone the inevitable, I think we should
> start to plan for the move to Git. I think at least these points
> should be addressed (if they haven't already been, in which case they
> should be documented such that they can be easily referenced, e.g. on
> the Wiki):
>
> 1) once Git becomes available, does SVN become unavailable right away,
> or will both repos be able to coexist for a while (both being able to
> receive updates and updating the other when they do)?
>
I do not think they can both exist at the same time. There will be a coordination effort on the part of INFRA and the Flex team to set dates for when the switch would happen, if I understand what has happened on other teams correctly.
>
> 2) several committers are "on loan" from Adobe for a very specific
> goal (Peter and Gordon). Are they comfortable working with Git,
> willing and able (in that they have enough time available to do so) to
> learn Git, or would moving to Git mean that they are no longer able to
> contribute?
>
I would be very surprised, and frankly disappointed, if they are unable to make the switch. We are talking about very smart developers here, and its not like switching from English to Japanese. Most of the common/every day commands are the same and the new concepts are not that difficult to grasp.
Peter, Gordon, Alex and Carol are all extremely smart developers I am confident they will be perfectly fine.
>
> 3) what workflow does the project use (reading about Git, it seems
> like there are endless possibilities), do we need to vote on that and
> how do we 'enforce' one over the other? Also, this workflow needs to
> be embedded in all the READMEs and the website, just like the SVN
> workflow is now.
>
This was part of the original vote and the workflow we chose is based on the nvie model: "Git Branching Model on Git"
http://markmail.org/search/?q=+list%3Aorg.apache.incubator.flex-dev+VOTE+RESULT#query:%20list%3Aorg.apache.incubator.flex-dev%20VOTE%20RESULT+page:3+mid:ajlskznzec4wqda2+state:results
It is the workflow currently in use that has been adapted to SVN while the switch to Git happens.
>
> 4) some technical aspects of the project are tied to SVN, like the
> website with it's post-commit hook to the 'buildbot'. These apparently
> have to stay with SVN, fragmenting the development environment. Are
> there alternatives that will allow these types of services to move
> over to Git as well?
>
>From my understanding the CMS/site will have to stay on SVN, so no, I do not believe there is an alternative to move it to Git as well. I hardly see this as a fragmentation of the development environment. I would be more concerned about this if we needed tons of people working on the site/CMS continually. That is just not the case though.
>
> 5) is anyone aware of any technical issues with the codebase that are
> specifically tied to SVN that need changing when the move happens
> (can't think of any, but better safe than sorry)
>
I am 100% positive that INFRA would identify those for us being that they have migrated several projects to Git already and they have all of that kind of stuff documented at a very high level within INFRA.
-omar
Re: Planning for Git
Posted by Omar Gonzalez <om...@gmail.com>.
On Thursday, November 22, 2012, Erik de Bruin wrote:
> > So, any questions that you might have regarding Git, GitHub, Git clients
> > and workflows I would be happy to help you get through. I will do my best
> > to either explain it to the best of my ability or direct you to some
> > resources that will hopefully help you better understand Git.
>
> Thank you! I think that a central location for all decisions,
> suggestions and resources, like a page on the Wiki, would be a great
> help for people like me who have no idea what to expect and are a
> little daunted by the prospect of this change.
>
> EdB
>
>
>
> --
> Ix Multimedia Software
>
> Jan Luykenstraat 27
> 3521 VB Utrecht
>
> T. 06-51952295
> I. www.ixsoftware.nl
>
Sounds like a plan! Once I get done eat turkey carcasses tonight I'll start
a page on the wiki to start to add some resources and FAQs that I can think
of or find. I'll also post any questions I get as a response to the other
thread I started about understanding Git.
-omar
Re: Planning for Git
Posted by Erik de Bruin <er...@ixsoftware.nl>.
> So, any questions that you might have regarding Git, GitHub, Git clients
> and workflows I would be happy to help you get through. I will do my best
> to either explain it to the best of my ability or direct you to some
> resources that will hopefully help you better understand Git.
Thank you! I think that a central location for all decisions,
suggestions and resources, like a page on the Wiki, would be a great
help for people like me who have no idea what to expect and are a
little daunted by the prospect of this change.
EdB
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: Planning for Git
Posted by Omar Gonzalez <om...@gmail.com>.
On Thu, Nov 22, 2012 at 10:26 AM, Erik de Bruin <er...@ixsoftware.nl> wrote:
> >> 2) several committers are "on loan" from Adobe for a very specific
> >> goal (Peter and Gordon). Are they comfortable working with Git,
> >> willing and able (in that they have enough time available to do so) to
> >> learn Git, or would moving to Git mean that they are no longer able to
> >> contribute?
> >>
> >
> > I would be very surprised, and frankly disappointed, if they are unable
> to
> > make the switch. We are talking about very smart developers here, and its
> > not like switching from English to Japanese. Most of the common/every day
> > commands are the same and the new concepts are not that difficult to
> grasp.
> > Peter, Gordon, Alex and Carol are all extremely smart developers I am
> > confident they will be perfectly fine.
>
> Any claim that the transition will be effortless is plain wrong. There
> is a learning curve for each new tooling and from reading about it on
> the interweb, as well as from my own efforts trying to 'get' it, the
> curve for Git is rather steep. This means that if a developer is not
> familiar with Git, he/she will have to invest time to learn it to be
> able to contribute.
>
Please do not put words in my mouth.
I did not say a transition would be effortless. I said I was confident that
they would be capable of handling such a transition.
>
> In the case of Peter and Gordon the limited time they can spend on the
> project has a very specific goal and is part of their day job. So,
> what I'm saying is, do we want them to spend this time on (learning)
> Git, or do we want them to spend time on Mustella and Falcon?
>
If we stopped changes in this project because we were concerned that some
developers might have to learn something new than this project is doomed
from the start. There are plenty of developers here familiar with Git, me
among them, that would be more than happy to help people get through
issues. All they have to do is ask for help.
>
> Repeating that Git is easy to learn doesn't make it so. At least for
> me it doesn't seem to come as easily as I hoped, the paradigm is just
> too different (i.e. more complicated) from the 'centralised' version
> control I'm familiar with (SourceSafe, Perforce, SVN). If that
> disappoints you, I'm sorry. As an average guy with average programming
> skills, I'm unlikely to be unique in this, though.
>
I did not say that repeating Git is easy to learn makes it so, nor do I
think that. It has just been my experience in migrating teams from SVN to
Git that the teams I have helped make this migration often think it is
harder than they think it is once they have found their "groove". Anything
that is being learned for the first time takes effort. But if people go
into a learning situation with a negative outlook then they are setting
themselves up for a hard time. I am more than happy to help anyone on this
list to get them through learning the differences in Git from SVN.
>
> The transition will (temporarily) lessen my ability to contribute to a
> project I care about, so my current obsession with Git is now squarely
> aimed at making the transition as organised and predictable as
> possible. If my insistence on clarity and focus, as well as
> documentation and planning, irritates you, well, I guess that
> disappoints me.
>
> EdB
>
Again, do not put words in my mouth. I did not say that the insistence on
clarity and focus irritates me. I am trying to answer all of the questions
that you have. Some of those I am able to answer right away. Others I can
not because I have not gone through the migration process and I'm basing my
answers on conversations I've had with the INFRA team on IRC and the
threads and issues I've read in the mailing lists and JIRA.
So, any questions that you might have regarding Git, GitHub, Git clients
and workflows I would be happy to help you get through. I will do my best
to either explain it to the best of my ability or direct you to some
resources that will hopefully help you better understand Git.
-omar
AW: Planning for Git
Posted by "christofer.dutz@c-ware.de" <ch...@c-ware.de>.
I did document the process of contributing to Flexmojos: https://dev.c-ware.de/confluence/display/PUBLIC/Contributing+to+Flexmojos
If/When we switch to GIT this might be a good starting point for a documentation of the Flex Workflow, but I think it explains how stuff works.
Chris
-----Ursprüngliche Nachricht-----
Von: Erik de Bruin [mailto:erik@ixsoftware.nl]
Gesendet: Donnerstag, 22. November 2012 19:26
An: flex-dev@incubator.apache.org
Betreff: Re: Planning for Git
>> 2) several committers are "on loan" from Adobe for a very specific
>> goal (Peter and Gordon). Are they comfortable working with Git,
>> willing and able (in that they have enough time available to do so)
>> to learn Git, or would moving to Git mean that they are no longer
>> able to contribute?
>>
>
> I would be very surprised, and frankly disappointed, if they are
> unable to make the switch. We are talking about very smart developers
> here, and its not like switching from English to Japanese. Most of the
> common/every day commands are the same and the new concepts are not that difficult to grasp.
> Peter, Gordon, Alex and Carol are all extremely smart developers I am
> confident they will be perfectly fine.
Any claim that the transition will be effortless is plain wrong. There is a learning curve for each new tooling and from reading about it on the interweb, as well as from my own efforts trying to 'get' it, the curve for Git is rather steep. This means that if a developer is not familiar with Git, he/she will have to invest time to learn it to be able to contribute.
In the case of Peter and Gordon the limited time they can spend on the project has a very specific goal and is part of their day job. So, what I'm saying is, do we want them to spend this time on (learning) Git, or do we want them to spend time on Mustella and Falcon?
Repeating that Git is easy to learn doesn't make it so. At least for me it doesn't seem to come as easily as I hoped, the paradigm is just too different (i.e. more complicated) from the 'centralised' version control I'm familiar with (SourceSafe, Perforce, SVN). If that disappoints you, I'm sorry. As an average guy with average programming skills, I'm unlikely to be unique in this, though.
The transition will (temporarily) lessen my ability to contribute to a project I care about, so my current obsession with Git is now squarely aimed at making the transition as organised and predictable as possible. If my insistence on clarity and focus, as well as documentation and planning, irritates you, well, I guess that disappoints me.
EdB
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: Planning for Git
Posted by Alex Harui <ah...@adobe.com>.
On 11/22/12 10:26 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
>>> 2) several committers are "on loan" from Adobe for a very specific
>>> goal (Peter and Gordon). Are they comfortable working with Git,
>>> willing and able (in that they have enough time available to do so) to
>>> learn Git, or would moving to Git mean that they are no longer able to
>>> contribute?
>>>
>>
>> I would be very surprised, and frankly disappointed, if they are unable to
>> make the switch. We are talking about very smart developers here, and its
>> not like switching from English to Japanese. Most of the common/every day
>> commands are the same and the new concepts are not that difficult to grasp.
>> Peter, Gordon, Alex and Carol are all extremely smart developers I am
>> confident they will be perfectly fine.
>
> Any claim that the transition will be effortless is plain wrong. There
> is a learning curve for each new tooling and from reading about it on
> the interweb, as well as from my own efforts trying to 'get' it, the
> curve for Git is rather steep. This means that if a developer is not
> familiar with Git, he/she will have to invest time to learn it to be
> able to contribute.
>
> In the case of Peter and Gordon the limited time they can spend on the
> project has a very specific goal and is part of their day job. So,
> what I'm saying is, do we want them to spend this time on (learning)
> Git, or do we want them to spend time on Mustella and Falcon?
Peter is currently full time. He has all day to learn Git, and he will.
Gordon expressed a preference to not have to learn Git because it will slow
him down, but I'm sure he will.
The basic premise for Git is this: Despite the fact that many of us who
know SVN will have to learn a new SCM, it is worth it because Git will
encourage more contributions and eventually more committers, growing Flex
and its community faster than staying on SVN.
So, Erik, you and I and others are being asked to "take one for the
community". I promise I will grumble and complain until I get it down, but
I will and hopefully we will have a stronger code base and community in the
end.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: Planning for Git
Posted by Erik de Bruin <er...@ixsoftware.nl>.
>> 2) several committers are "on loan" from Adobe for a very specific
>> goal (Peter and Gordon). Are they comfortable working with Git,
>> willing and able (in that they have enough time available to do so) to
>> learn Git, or would moving to Git mean that they are no longer able to
>> contribute?
>>
>
> I would be very surprised, and frankly disappointed, if they are unable to
> make the switch. We are talking about very smart developers here, and its
> not like switching from English to Japanese. Most of the common/every day
> commands are the same and the new concepts are not that difficult to grasp.
> Peter, Gordon, Alex and Carol are all extremely smart developers I am
> confident they will be perfectly fine.
Any claim that the transition will be effortless is plain wrong. There
is a learning curve for each new tooling and from reading about it on
the interweb, as well as from my own efforts trying to 'get' it, the
curve for Git is rather steep. This means that if a developer is not
familiar with Git, he/she will have to invest time to learn it to be
able to contribute.
In the case of Peter and Gordon the limited time they can spend on the
project has a very specific goal and is part of their day job. So,
what I'm saying is, do we want them to spend this time on (learning)
Git, or do we want them to spend time on Mustella and Falcon?
Repeating that Git is easy to learn doesn't make it so. At least for
me it doesn't seem to come as easily as I hoped, the paradigm is just
too different (i.e. more complicated) from the 'centralised' version
control I'm familiar with (SourceSafe, Perforce, SVN). If that
disappoints you, I'm sorry. As an average guy with average programming
skills, I'm unlikely to be unique in this, though.
The transition will (temporarily) lessen my ability to contribute to a
project I care about, so my current obsession with Git is now squarely
aimed at making the transition as organised and predictable as
possible. If my insistence on clarity and focus, as well as
documentation and planning, irritates you, well, I guess that
disappoints me.
EdB
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: Planning for Git
Posted by Omar Gonzalez <om...@gmail.com>.
On Thu, Nov 22, 2012 at 7:46 AM, Erik de Bruin <er...@ixsoftware.nl> wrote:
> Since we can't indefinitely postpone the inevitable, I think we should
> start to plan for the move to Git. I think at least these points
> should be addressed (if they haven't already been, in which case they
> should be documented such that they can be easily referenced, e.g. on
> the Wiki):
>
> 1) once Git becomes available, does SVN become unavailable right away,
> or will both repos be able to coexist for a while (both being able to
> receive updates and updating the other when they do)?
>
I do not think they can both exist at the same time. There will be a
coordination effort on the part of INFRA and the Flex team to set dates for
when the switch would happen, if I understand what has happened on other
teams correctly.
>
> 2) several committers are "on loan" from Adobe for a very specific
> goal (Peter and Gordon). Are they comfortable working with Git,
> willing and able (in that they have enough time available to do so) to
> learn Git, or would moving to Git mean that they are no longer able to
> contribute?
>
I would be very surprised, and frankly disappointed, if they are unable to
make the switch. We are talking about very smart developers here, and its
not like switching from English to Japanese. Most of the common/every day
commands are the same and the new concepts are not that difficult to grasp.
Peter, Gordon, Alex and Carol are all extremely smart developers I am
confident they will be perfectly fine.
>
> 3) what workflow does the project use (reading about Git, it seems
> like there are endless possibilities), do we need to vote on that and
> how do we 'enforce' one over the other? Also, this workflow needs to
> be embedded in all the READMEs and the website, just like the SVN
> workflow is now.
>
This was part of the original vote and the workflow we chose is based on
the nvie model: "Git Branching Model on Git"
http://markmail.org/search/?q=+list%3Aorg.apache.incubator.flex-dev+VOTE+RESULT#query:%20list%3Aorg.apache.incubator.flex-dev%20VOTE%20RESULT+page:3+mid:ajlskznzec4wqda2+state:results
It is the workflow currently in use that has been adapted to SVN while the
switch to Git happens.
>
> 4) some technical aspects of the project are tied to SVN, like the
> website with it's post-commit hook to the 'buildbot'. These apparently
> have to stay with SVN, fragmenting the development environment. Are
> there alternatives that will allow these types of services to move
> over to Git as well?
>
>From my understanding the CMS/site will have to stay on SVN, so no, I do
not believe there is an alternative to move it to Git as well. I hardly see
this as a fragmentation of the development environment. I would be more
concerned about this if we needed tons of people working on the site/CMS
continually. That is just not the case though.
>
> 5) is anyone aware of any technical issues with the codebase that are
> specifically tied to SVN that need changing when the move happens
> (can't think of any, but better safe than sorry)
>
I am 100% positive that INFRA would identify those for us being that they
have migrated several projects to Git already and they have all of that
kind of stuff documented at a very high level within INFRA.
-omar
Re: Planning for Git
Posted by Carlos Rovira <ca...@codeoscopic.com>.
Hi Erik
2012/11/22 Erik de Bruin <er...@ixsoftware.nl>
> Since we can't indefinitely postpone the inevitable, I think we should
> start to plan for the move to Git. I think at least these points
> should be addressed (if they haven't already been, in which case they
> should be documented such that they can be easily referenced, e.g. on
> the Wiki):
>
> 1) once Git becomes available, does SVN become unavailable right away,
> or will both repos be able to coexist for a while (both being able to
> receive updates and updating the other when they do)?
>
For what I see in the Flume ticket here (
https://issues.apache.org/jira/browse/INFRA-5065)
it's part of the process to see in which moment exactly SVN turns read
only. You can read in the comments section.
>
> 2) several committers are "on loan" from Adobe for a very specific
> goal (Peter and Gordon). Are they comfortable working with Git,
> willing and able (in that they have enough time available to do so) to
> learn Git, or would moving to Git mean that they are no longer able to
> contribute?
>
As this question is direct for concrete people, is something they should
respond on their own.
>
> 3) what workflow does the project use (reading about Git, it seems
> like there are endless possibilities), do we need to vote on that and
> how do we 'enforce' one over the other? Also, this workflow needs to
> be embedded in all the READMEs and the website, just like the SVN
> workflow is now.
>
You can see diferent models here:
http://git-scm.com/book/en/Distributed-Git-Distributed-Workflows
We talked with Pepe Barragan about the nvie branching model is the way to
start with centralized workflow, but the final recomendation for complex
projects (and Flex is a large and complex project) out there ends using the
Dictator - Liuetenants wokflow.
>
> 4) some technical aspects of the project are tied to SVN, like the
> website with it's post-commit hook to the 'buildbot'. These apparently
> have to stay with SVN, fragmenting the development environment. Are
> there alternatives that will allow these types of services to move
> over to Git as well?
>
This should be addressed with Infra (I really don't know what should be the
real solution here).
I only can say that the real use of Git is for the code of this
project...other peripheral things like cms, website, are not really a
problem. But it's clear that if it lives in git the better, so to avoid to
manage more than one vcs and avoid project tooling complexity.
>
> 5) is anyone aware of any technical issues with the codebase that are
> specifically tied to SVN that need changing when the move happens
> (can't think of any, but better safe than sorry)
>
there should not be anything since SVN - GIT are only tools. I did some svn
- git migrations and nothing was affeted from one side to another pass.
>
> That's all I've got now, just thought we needed a starting point and
> I'm hoping this will help provide one.
>
Thanks Erik.
>
> EdB
>
>
>
> --
> Ix Multimedia Software
>
> Jan Luykenstraat 27
> 3521 VB Utrecht
>
> T. 06-51952295
> I. www.ixsoftware.nl
>
--
Carlos Rovira
Director de Tecnología
M: +34 607 22 60 05
F: +34 912 35 57 77
http://www.codeoscopic.com
http://www.directwriter.es
http://www.avant2.es
Re: Planning for Git
Posted by Carol Frampton <cf...@adobe.com>.
On 11/22/12 10 :46AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
>Since we can't indefinitely postpone the inevitable, I think we should
>start to plan for the move to Git. I think at least these points
>should be addressed (if they haven't already been, in which case they
>should be documented such that they can be easily referenced, e.g. on
>the Wiki):
>
>1) once Git becomes available, does SVN become unavailable right away,
>or will both repos be able to coexist for a while (both being able to
>receive updates and updating the other when they do)?
Will we lose access to all the SVN history?
>
>2) several committers are "on loan" from Adobe for a very specific
>goal (Peter and Gordon). Are they comfortable working with Git,
>willing and able (in that they have enough time available to do so) to
>learn Git, or would moving to Git mean that they are no longer able to
>contribute?
Peter Ent is on Apache Flex with Alex and I.
>5) is anyone aware of any technical issues with the codebase that are
>specifically tied to SVN that need changing when the move happens
>(can't think of any, but better safe than sorry)
It may be that one or more scripts rely on source files having native line
ending and binary files being made executable on OSX. I don't know how
Git handles each of these but we can certainly modify the script(s) if
need be.
Carol