Mailing-List: contact dev-help@cordova.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cordova.apache.org
Received-SPF: pass (athena.apache.org: domain of fil@adobe.com designates
 64.18.1.237 as permitted sender)
From: Filip Maj <fil@adobe.com>
To: "dev@cordova.apache.org" <dev@cordova.apache.org>
Date: Wed, 12 Jun 2013 13:59:31 -0700
Subject: Re: Cordova CLI merge, new branch, INFRA ticket
Thread-Topic: Cordova CLI merge, new branch, INFRA ticket
Thread-Index: Ac5nr74dS50bjgqQSxynwwyl9WAn0w==
Message-ID: <CDDE2F30.208A9%fil@adobe.com>
In-Reply-To: 
 <CAJOjTCiP4x_FLKK8hgqWo2EveGOhgn3kZ2hzQg+r9D2dAPCmsA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/14.3.4.130416
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

Replied, but would be good for others to take a peak at this thread as I
am not 100% sure that my answers are correct..

On 6/12/13 1:18 PM, "Benn Mapes" <benn.mapes@gmail.com> wrote:

>What are we doing about https://issues.apache.org/jira/browse/INFRA-6302?
>
>I think they're afraid of messing things up for us. Does someone want to
>answer his questions? (I'm not sure what the correct approach is...)
>
>
>On Mon, Jun 10, 2013 at 1:27 PM, Braden Shepherdson
><braden@chromium.org>wrote:
>
>> Let's see how quickly they react to the new ticket.
>>
>> Braden
>>
>>
>> On Mon, Jun 10, 2013 at 4:18 PM, Filip Maj <fil@adobe.com> wrote:
>>
>> > My intuition is we'll need to bump the infra guys on irc..
>> >
>> > On 6/10/13 1:16 PM, "Braden Shepherdson" <braden@chromium.org> wrote:
>> >
>> > >Since it's been nearly two weeks with no movement despite a bump,
>>I've
>> > >closed the old INFRA ticket and opened a new one[1] stating that we
>> intend
>> > >to move forward with option 2.
>> > >
>> > >Braden
>> > >
>> > >[1] https://issues.apache.org/jira/browse/INFRA-6374
>> > >
>> > >
>> > >On Tue, Jun 4, 2013 at 2:46 PM, Braden Shepherdson
>> > ><braden@chromium.org>wrote:
>> > >
>> > >> Waiting on INFRA. I've already told them that we want to go with 2.
>> > >>
>> > >> Braden
>> > >>
>> > >>
>> > >> On Tue, Jun 4, 2013 at 2:41 PM, Benn Mapes <benn.mapes@gmail.com>
>> > wrote:
>> > >>
>> > >>> I'm fine with option 2, lets get this done.
>> > >>>
>> > >>>
>> > >>> On Tue, Jun 4, 2013 at 10:51 AM, Filip Maj <fil@adobe.com> wrote:
>> > >>>
>> > >>> > SGTM
>> > >>> >
>> > >>> > On 6/4/13 10:44 AM, "Braden Shepherdson" <braden@chromium.org>
>> > wrote:
>> > >>> >
>> > >>> > >I did some experimenting on my local disk to see what would
>>happen
>> > >>>if
>> > >>> we
>> > >>> > >did go with option 2. It's pretty sane and safe:
>> > >>> > >
>> > >>> > >- If someone re-clones as requested, all is well.
>> > >>> > >
>> > >>> > >- If someone doesn't re-clone, then there are two cases:
>> > >>> > >    - Merging the old local master against the new remote
>>master:
>> > >>> Massive
>> > >>> > >conflicts; should remind people that there was something about
>> this
>> > >>> repo.
>> > >>> > >    - Pushing the old local master to the new remote master:
>>Fails
>> > >>> because
>> > >>> > >it's not a fast-forward merge.
>> > >>> > >
>> > >>> > >So that's pretty okay. It would take real effort to resolve
>>these
>> > >>> > >conflicts
>> > >>> > >and try to push the result. No one is likely to do that, and
>>they
>> > >>>still
>> > >>> > >can't cause lasting damage unless it's a committer. All the
>> > >>>committers
>> > >>> are
>> > >>> > >aware of this problem, and getting that huge conflict is
>>likely to
>> > >>> remind
>> > >>> > >them of this.
>> > >>> > >
>> > >>> > >Braden
>> > >>> > >
>> > >>> > >
>> > >>> > >On Mon, Jun 3, 2013 at 1:16 PM, Filip Maj <fil@adobe.com>
>>wrote:
>> > >>> > >
>> > >>> > >> Thanks for taking that on Braden
>> > >>> > >>
>> > >>> > >> On 6/3/13 10:15 AM, "Braden Shepherdson"
>><braden@chromium.org>
>> > >>> wrote:
>> > >>> > >>
>> > >>> > >> >I've bumped the INFRA ticket[1], I'll keep this thread up to
>> date
>> > >>> with
>> > >>> > >>any
>> > >>> > >> >changes there.
>> > >>> > >> >
>> > >>> > >> >Braden
>> > >>> > >> >
>> > >>> > >> >
>> > >>> > >> >On Sat, Jun 1, 2013 at 6:36 PM, Filip Maj <fil@adobe.com>
>> wrote:
>> > >>> > >> >
>> > >>> > >> >> Option 2! Let's move forward and get this sorted.
>> > >>> > >> >>
>> > >>> > >> >> On 5/29/13 1:17 PM, "Jesse MacFadyen" <
>> purplecabbage@gmail.com
>> > >
>> > >>> > >>wrote:
>> > >>> > >> >>
>> > >>> > >> >> >I am liking option 2 now. Seems easy enough.
>> > >>> > >> >> >
>> > >>> > >> >> >Cheers,
>> > >>> > >> >> >  Jesse
>> > >>> > >> >> >
>> > >>> > >> >> >Sent from my iPhone5
>> > >>> > >> >> >
>> > >>> > >> >> >On 2013-05-29, at 9:06 AM, Michal Mocny <
>> mmocny@chromium.org>
>> > >>> > wrote:
>> > >>> > >> >> >
>> > >>> > >> >> >For the record, I don't mind a reclone, so long as there
>>are
>> > >>>no
>> > >>> > >> >>negative
>> > >>> > >> >> >repercussions, ie, (1) its not called master2 and (2)
>>there
>> > >>>is no
>> > >>> > >>way
>> > >>> > >> >>for
>> > >>> > >> >> >anyone to shoot us in the foot if they forget to re-clone
>> > >>> properly
>> > >>> > >>and
>> > >>> > >> >> >start doing merges/pushes/whatever.
>> > >>> > >> >> >
>> > >>> > >> >> >So, if (2) fails loudly thats my preference.  Otherwise,
>>I
>> > >>>don't
>> > >>> > >>mind
>> > >>> > >> >>(4)
>> > >>> > >> >> >but others might, and I hate (3) more than (1) :)
>> > >>> > >> >> >
>> > >>> > >> >> >-Michal
>> > >>> > >> >> >
>> > >>> > >> >> >
>> > >>> > >> >> >On Wed, May 29, 2013 at 11:51 AM, Braden Shepherdson
>> > >>> > >> >> ><braden@chromium.org>wrote:
>> > >>> > >> >> >
>> > >>> > >> >> >> This would be an example of "continuing to pay the
>>price
>> for
>> > >>> not
>> > >>> > >> >>being
>> > >>> > >> >> >> willing to re-clone 1, 3, 6, 12 months ago." We can
>>avoid
>> > >>>all
>> > >>> of
>> > >>> > >>that
>> > >>> > >> >> >> nonsense with three lines.
>> > >>> > >> >> >>
>> > >>> > >> >> >> Braden
>> > >>> > >> >> >>
>> > >>> > >> >> >>
>> > >>> > >> >> >> On Wed, May 29, 2013 at 11:38 AM, Michal Mocny
>> > >>> > >><mmocny@chromium.org>
>> > >>> > >> >> >> wrote:
>> > >>> > >> >> >>
>> > >>> > >> >> >>> Can we go with (1) and still keep master2 around
>>(perhaps
>> > >>> rename
>> > >>> > >>it
>> > >>> > >> >>to
>> > >>> > >> >> >>> something sensible) so that we can still get full
>>history
>> > >>>but
>> > >>> > >>with
>> > >>> > >> >>one
>> > >>> > >> >> >>> level of indirection:
>> > >>> > >> >> >>> - The mega commit could have a commit message such as
>> "THIS
>> > >>> WAS A
>> > >>> > >> >>HACKY
>> > >>> > >> >> >>> MERGE, FOR REAL HISTORY LOOK IN THE OLD_FUTURE BRANCH"
>> > >>> > >> >> >>> - When you bit blame and see that as the commit
>> > >>>responsible,
>> > >>> you
>> > >>> > >> >>know
>> > >>> > >> >> >>>you
>> > >>> > >> >> >>> have to git blame again in the other branch
>> > >>> > >> >> >>>
>> > >>> > >> >> >>> -Michal
>> > >>> > >> >> >>>
>> > >>> > >> >> >>>
>> > >>> > >> >> >>> On Wed, May 29, 2013 at 11:22 AM, Ian Clelland
>> > >>> > >> >><iclelland@google.com>
>> > >>> > >> >> >>> wrote:
>> > >>> > >> >> >>>
>> > >>> > >> >> >>>> SInce 2 and 3 both require re-cloning the repository,
>> I'd
>> > >>> much
>> > >>> > >> >>rather
>> > >>> > >> >> >> go
>> > >>> > >> >> >>>> with 2, and rename the branches appropriately.
>> > >>> > >> >> >>>>
>> > >>> > >> >> >>>>
>> > >>> > >> >> >>>> On Wed, May 29, 2013 at 11:11 AM, Brian LeRoux
>> > >>><b@brian.io>
>> > >>> > >>wrote:
>> > >>> > >> >> >>>>
>> > >>> > >> >> >>>>> ya the rename easiest
>> > >>> > >> >> >>>>>
>> > >>> > >> >> >>>>> On Wed, May 29, 2013 at 8:00 AM, Braden Shepherdson
>><
>> > >>> > >> >> >>> braden@chromium.org
>> > >>> > >> >> >>>>>
>> > >>> > >> >> >>>>> wrote:
>> > >>> > >> >> >>>>>> I'll keep this thread up to date with INFRA's
>> responses.
>> > >>> > >> >> >>>>>>
>> > >>> > >> >> >>>>>> I asked INFRA about options and their implications.
>> > >>>These
>> > >>> are
>> > >>> > >>the
>> > >>> > >> >> >>> four
>> > >>> > >> >> >>>>>> options I described, after I was informed that our
>> > >>>original
>> > >>> > >> >>request
>> > >>> > >> >> >>>> would
>> > >>> > >> >> >>>>>> actually require everyone to re-clone the repo.
>> > >>> > >> >> >>>>>>
>> > >>> > >> >> >>>>>> 1. Check out master, delete all the files, copy in
>>all
>> > >>>the
>> > >>> > >>files
>> > >>> > >> >> >>> from
>> > >>> > >> >> >>>>>> master2, check them all in. This keep the branching
>> the
>> > >>> same,
>> > >>> > >>and
>> > >>> > >> >> >> no
>> > >>> > >> >> >>>> one
>> > >>> > >> >> >>>>>> would need to re-clone. But it also makes the
>>history
>> > >>> nearly
>> > >>> > >> >> >> useless
>> > >>> > >> >> >>>>> before
>> > >>> > >> >> >>>>>> that point. I dislike this option, but it's there.
>> > >>> > >> >> >>>>>>
>> > >>> > >> >> >>>>>> 2. Rename master to old_master or similar, and
>>rename
>> > >>> master2
>> > >>> > >>to
>> > >>> > >> >> >>>> master.
>> > >>> > >> >> >>>>>> Since everyone is re-cloning anyway, this is
>>possible.
>> > >>> Keeps
>> > >>> > >>the
>> > >>> > >> >> >> name
>> > >>> > >> >> >>>>>> consistent. This might be nasty if someone tries to
>> > >>>merge
>> > >>> > >>between
>> > >>> > >> >> >> an
>> > >>> > >> >> >>>> old
>> > >>> > >> >> >>>>>> master and the new master. Unless git can notice
>>that
>> > >>> things
>> > >>> > >>are
>> > >>> > >> >> >>> wrong
>> > >>> > >> >> >>>>> and
>> > >>> > >> >> >>>>>> they should re-clone.
>> > >>> > >> >> >>>>>>
>> > >>> > >> >> >>>>>> 3. My original request to move HEAD. Exposes the
>> master2
>> > >>> name
>> > >>> > >>and
>> > >>> > >> >> >>>>> requires
>> > >>> > >> >> >>>>>> everyone to use it. Still requires a re-clone.
>> > >>> > >> >> >>>>>>
>> > >>> > >> >> >>>>>> 4. Abandon the repository and recreate it under a
>>new
>> > >>>name,
>> > >>> > >> >>pushing
>> > >>> > >> >> >>>> only
>> > >>> > >> >> >>>>>> master2 as the new master. Requires a re-clone and
>> > >>>changing
>> > >>> > >>the
>> > >>> > >> >> >> name.
>> > >>> > >> >> >>>>>> Probably not, but it's an option.
>> > >>> > >> >> >>>>>>
>> > >>> > >> >> >>>>>> What do people think? I'm most partial to 2, since
>>it
>> > >>> > >>preserves
>> > >>> > >> >>the
>> > >>> > >> >> >>>>> master
>> > >>> > >> >> >>>>>> name and it's hard to avoid recloning.
>> > >>> > >> >> >>>>>>
>> > >>> > >> >> >>>>>> Braden
>> > >>> > >> >> >>>>>>
>> > >>> > >> >> >>>>>>
>> > >>> > >> >> >>>>>> On Tue, May 28, 2013 at 8:07 PM, Jesse
>> > >>> > >><purplecabbage@gmail.com>
>> > >>> > >> >> >>>> wrote:
>> > >>> > >> >> >>>>>>
>> > >>> > >> >> >>>>>>> What is the resolution on this?
>> > >>> > >> >> >>>>>>>
>> > >>> > >> >> >>>>>>> My opinion: History is in the past, move on.
>> > >>> > >> >> >>>>>>> I think it's okay if it is history is messy, or
>>even
>> if
>> > >>> has a
>> > >>> > >> >>few
>> > >>> > >> >> >>>>> duplicate
>> > >>> > >> >> >>>>>>> commits.  Tangles and all.
>> > >>> > >> >> >>>>>>>
>> > >>> > >> >> >>>>>>>
>> > >>> > >> >> >>>>>>> @purplecabbage
>> > >>> > >> >> >>>>>>> risingj.com
>> > >>> > >> >> >>>>>>>
>> > >>> > >> >> >>>>>>>
>> > >>> > >> >> >>>>>>> On Fri, May 24, 2013 at 7:05 AM, Braden
>>Shepherdson <
>> > >>> > >> >> >>>>> braden@chromium.org
>> > >>> > >> >> >>>>>>>> wrote:
>> > >>> > >> >> >>>>>>>
>> > >>> > >> >> >>>>>>>> I think so, but only if we're prepared to keep
>>the
>> > >>> tangled
>> > >>> > >> >> >> history
>> > >>> > >> >> >>>> and
>> > >>> > >> >> >>>>>>>> duplicate about 30 commits. Several mistakes were
>> made
>> > >>> with
>> > >>> > >>the
>> > >>> > >> >> >>>>> branching
>> > >>> > >> >> >>>>>>>> and rebasing of things on master, and there's a
>>lot
>> of
>> > >>> > >> >> >> duplication
>> > >>> > >> >> >>>> and
>> > >>> > >> >> >>>>>>>> confusion in the history.
>> > >>> > >> >> >>>>>>>>
>> > >>> > >> >> >>>>>>>> When you get in this morning, I can show you the
>> > >>> whiteboard
>> > >>> > >> >> >>> diagram
>> > >>> > >> >> >>>> of
>> > >>> > >> >> >>>>>>> the
>> > >>> > >> >> >>>>>>>> long version above, and then you can look at the
>> > >>> histories
>> > >>> > >>of
>> > >>> > >> >> >>> master
>> > >>> > >> >> >>>>> and
>> > >>> > >> >> >>>>>>>> master2 on GitX. I think you'll agree it's worth
>> > >>>moving
>> > >>> > >>forward
>> > >>> > >> >> >>> with
>> > >>> > >> >> >>>>>>>> master2.
>> > >>> > >> >> >>>>>>>>
>> > >>> > >> >> >>>>>>>> Braden
>> > >>> > >> >> >>>>>>>>
>> > >>> > >> >> >>>>>>>>
>> > >>> > >> >> >>>>>>>> On Thu, May 23, 2013 at 11:16 PM, Andrew Grieve <
>> > >>> > >> >> >>>> agrieve@chromium.org
>> > >>> > >> >> >>>>>>>>> wrote:
>> > >>> > >> >> >>>>>>>>
>> > >>> > >> >> >>>>>>>>> Could we merge master2 into master with:
>> > >>> > >> >> >>>>>>>>>
>> > >>> > >> >> >>>>>>>>> git merge --strategy-option=3Dtheirs master2
>> > >>> > >> >> >>>>>>>>>
>> > >>> > >> >> >>>>>>>>>
>> > >>> > >> >> >>>>>>>>> On Thu, May 23, 2013 at 6:19 PM, Braden
>> Shepherdson <
>> > >>> > >> >> >>>>>>> braden@chromium.org
>> > >>> > >> >> >>>>>>>>>> wrote:
>> > >>> > >> >> >>>>>>>>>
>> > >>> > >> >> >>>>>>>>>> tl;dr version: cordova-cli now has a master2
>> branch
>> > >>> that
>> > >>> > >> >> >>> should
>> > >>> > >> >> >>>> be
>> > >>> > >> >> >>>>>>>>> treated
>> > >>> > >> >> >>>>>>>>>> as master going forward. DO NOT use master or
>> future
>> > >>> > >> >> >> anymore.
>> > >>> > >> >> >>>>>>>>>>
>> > >>> > >> >> >>>>>>>>>> Short version:
>> > >>> > >> >> >>>>>>>>>>
>> > >>> > >> >> >>>>>>>>>> - I tried to merge future and master.
>> > >>> > >> >> >>>>>>>>>> - I couldn't because the history is a train
>>wreck.
>> > >>>The
>> > >>> > >> >> >>> morbidly
>> > >>> > >> >> >>>>>>> curious
>> > >>> > >> >> >>>>>>>>>> should see [2].
>> > >>> > >> >> >>>>>>>>>> - Ian and I dug through the history, and played
>> CSI
>> > >>> until
>> > >>> > >>we
>> > >>> > >> >> >>>>> figured
>> > >>> > >> >> >>>>>>>> out
>> > >>> > >> >> >>>>>>>>>> what had happened, and found a sensible way to
>> > >>> > >>reconstruct a
>> > >>> > >> >> >>>> sane
>> > >>> > >> >> >>>>>>>> master
>> > >>> > >> >> >>>>>>>>>> branch.
>> > >>> > >> >> >>>>>>>>>> - This branch merged fairly neatly with future.
>> > >>> > >> >> >>>>>>>>>> - It is now committed as the new branch
>>master2.
>> > >>> > >> >> >>>>>>>>>> - The original master branch is deprecated.
>> > >>> > >> >> >>>>>>>>>> - I have filed an INFRA ticket[1] to get them
>>to
>> > >>>point
>> > >>> > >>HEAD
>> > >>> > >> >> >> at
>> > >>> > >> >> >>>>>>> master2,
>> > >>> > >> >> >>>>>>>>> and
>> > >>> > >> >> >>>>>>>>>> delete the old master branch.
>> > >>> > >> >> >>>>>>>>>> - Use master2 from now on. DO NOT touch the old
>> > >>>master
>> > >>> or
>> > >>> > >> >> >>> future
>> > >>> > >> >> >>>>>>>> branches
>> > >>> > >> >> >>>>>>>>>> anymore.
>> > >>> > >> >> >>>>>>>>>>
>> > >>> > >> >> >>>>>>>>>> I'll keep the list updated on the state of the
>> INFRA
>> > >>> > >>ticket.
>> > >>> > >> >> >>>>>>>>>>
>> > >>> > >> >> >>>>>>>>>> Braden
>> > >>> > >> >> >>>>>>>>>>
>> > >>> > >> >> >>>>>>>>>> [1]
>> > https://issues.apache.org/jira/browse/INFRA-6302
>> > >>> > >> >> >>>>>>>>>>
>> > >>> > >> >> >>>>>>>>>> [2] Long version:
>> > >>> > >> >> >>>>>>>>>>
>> > >>> > >> >> >>>>>>>>>> A long time ago, I forked cli's master to
>>create
>> > >>> future. I
>> > >>> > >> >> >>>>> committed
>> > >>> > >> >> >>>>>>> a
>> > >>> > >> >> >>>>>>>>>> half-dozen changes or so. Sometime later, a
>>2.7.x
>> > >>> branch
>> > >>> > >>was
>> > >>> > >> >> >>>>> forked
>> > >>> > >> >> >>>>>>>> /from
>> > >>> > >> >> >>>>>>>>>> future/. Several changes were made here. Later
>>it
>> > >>>was
>> > >>> > >>merged
>> > >>> > >> >> >>>> back
>> > >>> > >> >> >>>>> in,
>> > >>> > >> >> >>>>>>>> /to
>> > >>> > >> >> >>>>>>>>>> master/. The same changes were later rebased
>>onto
>> > >>> master
>> > >>> > >>and
>> > >>> > >> >> >>>>>>> committed
>> > >>> > >> >> >>>>>>>>>> again, duplicating them. Then this branch was
>> merged
>> > >>> with
>> > >>> > >> >> >>> master
>> > >>> > >> >> >>>>>>> again,
>> > >>> > >> >> >>>>>>>>>> creating a /third/ copy of the changes
>>originally
>> > >>>from
>> > >>> > >>this
>> > >>> > >> >> >>>> 2.7.x
>> > >>> > >> >> >>>>>>>> branch.
>> > >>> > >> >> >>>>>>>>>>
>> > >>> > >> >> >>>>>>>>>> Meanwhile, some of the changes from future were
>> > >>> reverted
>> > >>> > >>by
>> > >>> > >> >> >>> hand
>> > >>> > >> >> >>>>> (as
>> > >>> > >> >> >>>>>>>>>> opposed to with git revert) in master.
>> > >>> > >> >> >>>>>>>>>>
>> > >>> > >> >> >>>>>>>>>> Finally some new changes were made to future
>>and
>> > >>> master.
>> > >>> > >>It
>> > >>> > >> >> >>>> looks,
>> > >>> > >> >> >>>>>>>>>> according to git, like there are only these
>> changes
>> > >>>on
>> > >>> the
>> > >>> > >> >> >>>> future
>> > >>> > >> >> >>>>>>>> branch,
>> > >>> > >> >> >>>>>>>>>> since the earlier ones were merged by accident
>> some
>> > >>> time
>> > >>> > >> >> >> ago.
>> > >>> > >> >> >>>>>>>>>>
>> > >>> > >> >> >>>>>>>>>> When I came along and tried to merge master and
>> > >>>future
>> > >>> in
>> > >>> > >> >> >>> either
>> > >>> > >> >> >>>>>>>>> direction,
>> > >>> > >> >> >>>>>>>>>> or rebase in either direction, those older
>>future
>> > >>> changes
>> > >>> > >> >> >>> stayed
>> > >>> > >> >> >>>>>>>> deleted,
>> > >>> > >> >> >>>>>>>>>> because according to git they were made on the
>> same
>> > >>> > >>branch.
>> > >>> > >> >> >>>>>>>>>>
>> > >>> > >> >> >>>>>>>>>> Moral of the story: Don't take a branch off
>>master
>> > >>> (like
>> > >>> > >> >> >>>> future),
>> > >>> > >> >> >>>>>>> fork
>> > >>> > >> >> >>>>>>>>> it,
>> > >>> > >> >> >>>>>>>>>> commit to it, and then merge it back to master.
>> > >>>That's
>> > >>> > >>what
>> > >>> > >> >> >>>>> started
>> > >>> > >> >> >>>>>>>> most
>> > >>> > >> >> >>>>>>>>> of
>> > >>> > >> >> >>>>>>>>>> the insanity, because now future is partially
>> merged
>> > >>> into
>> > >>> > >> >> >>> master
>> > >>> > >> >> >>>>> even
>> > >>> > >> >> >>>>>>>>>> though it's not being treated that way.
>> > >>> > >> >> >>>>>>>>>>
>> > >>> > >> >> >>>>>>>>>> I need a drink.
>> > >>> > >> >> >>
>> > >>> > >> >>
>> > >>> > >> >>
>> > >>> > >>
>> > >>> > >>
>> > >>> >
>> > >>> >
>> > >>>
>> > >>
>> > >>
>> >
>> >
>>