Return-Path: X-Original-To: apmail-incubator-flex-dev-archive@minotaur.apache.org Delivered-To: apmail-incubator-flex-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 7AC68D7C9 for ; Fri, 10 Aug 2012 15:00:09 +0000 (UTC) Received: (qmail 87112 invoked by uid 500); 10 Aug 2012 15:00:08 -0000 Delivered-To: apmail-incubator-flex-dev-archive@incubator.apache.org Received: (qmail 87077 invoked by uid 500); 10 Aug 2012 15:00:08 -0000 Mailing-List: contact flex-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: flex-dev@incubator.apache.org Delivered-To: mailing list flex-dev@incubator.apache.org Received: (qmail 87069 invoked by uid 99); 10 Aug 2012 15:00:08 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 10 Aug 2012 15:00:08 +0000 X-ASF-Spam-Status: No, hits=1.0 required=5.0 tests=FRT_ADOBE2,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of Jason.Moore@harksolutions.co.uk designates 82.68.242.54 as permitted sender) Received: from [82.68.242.54] (HELO mail.harksolutions.co.uk) (82.68.242.54) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 10 Aug 2012 15:00:02 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-class: urn:content-classes:message X-Antivirus: AVG for E-mail Subject: RE: What would it take to move to Git? Date: Fri, 10 Aug 2012 15:59:40 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: What would it take to move to Git? thread-index: AQKf8Zv89diBgHV7qJlGpxvcu/1jJZWuLLJg References: From: "Jason Moore" To: X-Virus-Checked: Checked by ClamAV on apache.org +1 from me. The structure Carol outlined in the latter part with a development trunk and stable branches is how I'm used to working with SVN. Jason :) (Thank god I've manage to bypass the company legal footer - I think.) -----Original Message----- From: Carol Frampton [mailto:cframpto@adobe.com]=20 Sent: 10 August 2012 15:31 To: flex-dev@incubator.apache.org Subject: Re: What would it take to move to Git? Personally I'd like to come up with a relatively simple scheme for branching using SVN and then get to work, especially since Apache infra still considers Git experimental. I'm guessing we are one of the larger projects at Apache in terms of code size and I want us to be able to get infra support. I know we've used their services quite a few times already. We've spent 8 months pushing existing code around and not making any forward progress with Flex. I understand that some people prefer Git but at this point everyone knows SVN to some level and not everyone knows Git. Assuming we will release from trunk, I don't think everyone working in trunk can work, even aside from the stability issues. If we all worked for the same company, and all signed up to get our features done by date X so we could release on date Y it might be possible. In the Apache model people work on things when they can, so there might be features/components that aren't done when someone decides to do a release. I think Alex is proposing that we all work in the dev branch (aka unstable) and when it is time to release we cherry pick changes to move back to trunk and then release from trunk. We would not be merging on a daily or even weekly basis but at release time (perhaps too corporate but could also have base levels and merge then). I think Justin raises some legitimate concerns about multiple changes being made to the same file but I think we can come up with a solution for that. Perhaps changes don't get even get committed to the dev branch until you think they are worthy of release but there are other alternatives as well. I think you could also flip this and do dev work in trunk and then create a branch for the release that was based on the last release tag and then you move changes from trunk over to the release branch. I'm having a hard time following the Alex/Justin discussion but I have read some misinformation about SVN in there. You can do an svn merge and then if there are conflicts, go back and resolve those conflicts and mark the files resolved with svn resolve. Then you svn commit the results of the merge. You can also block merges with svn --record-only merge. Carol