[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [sc-dev] call-backs, co-routines and inversion of control
- To: sc-dev@xxxxxxxxxxxxxxxx
- Subject: Re: [sc-dev] call-backs, co-routines and inversion of control
- From: Julian Rohrhuber <julian.rohrhuber@xxxxxxxxxxxxxxxxxx>
- Date: Wed, 16 Jan 2013 17:32:44 +0100
- In-reply-to: <CALfiFhDgaObkspV1ZWF85aLgV+zq_PDU8krLDwLoweZ_e4mk5A@mail.gmail.com>
- List-id: SuperCollider developers mailing list <sc-devel.create.ucsb.edu>
- References: <778221C9-492A-4DB9-BA09-EB1DEEAECB49@friendlyvirus.org> <50ABBC37.firstname.lastname@example.org> <A145DF2F-0446-498D-86EE-E5A8C9D7582E@bham.ac.uk> <1F4DC433-1998-48B1-BF7D-B139E2E6A88E@musikundmedien.net> <CALfiFhD_XXFG62jVvHE9D4wdKviZ8NMjXSdB1+7Sh8k+qfU5Jg@mail.gmail.com> <0D25C620-C6F3-4FA0-9386-F643B48B87E0@musikundmedien.net> <6970E904-41EB-4F4B-976F-7B8B25930B10@friendlyvirus.org> <2901865F-E435-4187-9EE8-88649F84CADA@musikundmedien.net> <CAFniQ7W4kKUsgmR1KwB+VL9O=LGB__wM2UgW=CP56QLB-9BhbQ@mail.gmail.com> <97E72E9E-6576-49D4-A51E-12C58EAA6B6F@musikundmedien.net> <CAFniQ7XbX_tuMVs7Oc1dKGy6aM8KotXYbY_3nPg=cfX3_XCJPQ@mail.gmail.com> <C3DC6B65-7432-4F81-97EB-DCDAF0D92EC8@musikundmedien.net> <79E883CF-EBAF-41BF-BC17-75146B15A206@friendlyvirus.org> <E3730DCA-1B98-42DF-AFA0-6FF6084D2436@musikundmedien.net> <E0FCBEE0-D9BF-4656-963C-5E3EA9E20045@musikundmedien.net> <1C65DD7F-62FC-4374-8F58-592533FC2880@friendlyvirus.org> <9F3E5205-3976-4A5D-946A-58BF3317E230@friendlyvirus.org>
- Reply-to: sc-dev@xxxxxxxxxxxxxxxx
- Sender: owner-sc-dev@xxxxxxxxxxxxxxxx
- Sun-java-system-smtp-warning: Lines longer than SMTP allows found and truncated.
On 11.01.2013, at 12:10, Jonatan Liljedahl <lijon@xxxxxxxxxxxx> wrote:
> Well, if s.bind changes to always synching at the end, and it didn't
> before, then it's a change in behavior that might break peoples code.
> I haven't studied the code or your patch in detail so I don't really
> know if this is the case or not.
Ah, didn't think of this. Well if this is the only issue, we can change this easily.
> However, using branches or keeping track of them are not hard.
> git branch - shows a list of your branches
> git checkout <the_branch> - switch to the branch
You also have to keep the branch up to date with master. If someone else starts working on the same thing, you get conflicts you have to resolve. Then you also need to build the branch and run it on a day to day basis in order to find problems
This is something more than two or three people should do, I think.
> Anyone interested in this particular feature would check out the
> branch while developing it into finished state, then people can test
> it, then it can be merged back into master. Another good thing with
> this approach is that the merge back can be compressed into one or a
> few commits, instead of having half-finished work spread out over
> multiple commits, making it hard to backtrack in case of discovered
> bugs or regressions, etc.
It would be good, I just doubt that this is what would be happening now. Maybe I'm too pessimistic, but it seems to me that currently, the branch would just stay untouched and untested.
sc-dev mailing list
info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml