flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jason Moore" <Jason.Mo...@harksolutions.co.uk>
Subject RE: What would it take to move to Git?
Date Fri, 10 Aug 2012 14:59:40 GMT
+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

Jason :)
(Thank god I've manage to bypass the company legal footer - I think.)

-----Original Message-----
From: Carol Frampton [mailto:cframpto@adobe.com] 
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

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

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


View raw message