incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carlos Rovira <carlos.rov...@codeoscopic.com>
Subject Re: Planning for Git
Date Thu, 22 Nov 2012 16:01:41 GMT
Hi Erik

2012/11/22 Erik de Bruin <erik@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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message