incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "christofer.dutz@c-ware.de" <christofer.d...@c-ware.de>
Subject AW: Planning for Git
Date Thu, 22 Nov 2012 17:55:10 GMT
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 <erik@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

Mime
View raw message