TypedControls branch? was Re: [Clam-devel] Bug solved for deleting Out In Ports and Out In Controls

Hernán Ordiales h at ordia.com.ar
Thu Jul 17 14:40:51 PDT 2008 

On Thu, Jul 17, 2008 at 6:34 PM, Pau Arumí <parumi at iua.upf.edu> wrote:
> On dj, 2008-07-17 at 18:18 -0300, Hernán Ordiales wrote:
>> just one note more, i think that the main issue that makes really big
>> this patch is because now we are using BaseTypedIn|OutControl where we
>> had In|OutControl (registry, etc)
>>
>> with this class diagram:
>> class BaseTypedIn|OutControl
>> class TypedIn|OutControl: BaseTypedIn|OutControl
>> class In|OutControl: TypedIn|OutControl<TControlData>
>>
>> so many of the code using In|OutControls types is replaced by
>> BaseTypedIn|Out to allow a general treatment of the controls. Other
>> issue is that in some parts where now is required a Base type, current
>> code is using an interface not present in Base, only at old
>> In|OutControl classes, and are methods not-convenient to add to Base,
>> so a code change/refactor is required.
>
> Yes, but many of these rafactorings can be done at trunk before the
> actual switch. For example substitute
> proc.GetInControl("MyIn").DoControl(1.); -> DoControlAsFloat(proc,
> "MyIn", 1.)   (I'm using wrong function names, I know)

I like this idea, i think we can make the delta smaller with this kind
of things.

> And maybe we should be refactoring In|OutControl to make it more similar
> to BaseTypedIn|OutControl interfaces also in trunk. However I'd like to
> see code on that issue.
>
> All this belongs to the "start making the delta smaller" approach.
>
> P
>
>
>> On Thu, Jul 17, 2008 at 5:08 PM, Hernán Ordiales <h at ordia.com.ar> wrote:
>> > On Thu, Jul 17, 2008 at 4:03 PM, David García Garzón
>> > <dgarcia at iua.upf.edu> wrote:
>> >> Don't do that, please. :-) Branches are like hell. Just keeping the branch up
>> >> to date has a lot of problems. It is hard to guess which differences are
>> >> because branch modifications and which ones because trunk evolution and
>> >> moreover, which branch modifications from the branch point are unique and
>> >> which ones are just merges from the trunk. Believe, you don't want that.
>> >> Maybe using bazar, but svn doesn't cope with that gently. The merge is also a
>> >> hard process. Are you sure, ok, so then proceed.
>> >>
>> >>
>> >> Needing branches are a symptom we are dealing with that project not in a
>> >> proper way. First **those patches should have been sent to the list**. Even
>> >> if they are not compiling, we could patch our sandboxes and see what is not
>> >> compiling and helping. Any changes concerning new classes should be commited
>> >> just to keep the delta as small as possible. The patches should contain just
>> >> horizontal modifications on updated old files.
>> >
>> > I'm fully agree to send the patches to the list, that was the way of
>> > work from first, maybe not lately because they were incomplete, but i
>> > agree they should be sent to the list (complete or not)
>> > About the branch, i think could be a good idea since the pending patch
>> > was in development for many days/weeks and wasn't ready to apply since
>> > it's always arising a new issue which breaks something more. I liked
>> > the idea to have a branch as a place where all can see and commit in
>> > an interactive way (and test beyond the automated tests), and a way to
>> > prepare the 'big patch' for typed controls 'in community' to then
>> > apply to the trunk. I know big patches are not recommended, but
>> > believe me with the last changes you can't split much of it since
>> > involves changes in all controls (basically beacause the port of
>> > In|OutControls deriving from TypedIn|Control<float> and some deprected
>> > uses of the Control interface) and that kind of thing are spread in
>> > all the clam code (you'll be able to see in detail when francisco
>> > sends the patch to the list, meantime i'm sending with this mail the
>> > last patch i have in my hands from about a week ago, have in mind many
>> > things there are already noted and discussed and i think already fixed
>> > by francisco)
>> >
>> >> So, please, send the patches to the list and explain the issues you have with
>> >> the code in front of us.
>> >>
>> >> BTW: Jun and Pawell are waiting for commit access for 3 weeks, Pau, if you get
>> >> it for Francisco in one day you are fuzzing lucky :-)
>> >>
>> >>
>> >> On Dijous 17 Juliol 2008, Pau Arumí wrote:
>> >>> On dj, 2008-07-17 at 14:10 -0300, Hernán Ordiales wrote:
>> >>> > On Thu, Jul 17, 2008 at 1:19 PM, Pau Arumí <parumi at iua.upf.edu> wrote:
>> >>> > > So I propose to create a branch in our subversion. This branch should
>> >>> > > live only during the controls transition, and the maintainers should
>> >>> > > keep all the changes in trunk commited in the branch. That is, in
>> >>> > > permanent state of merge with trunk.
>> >>> > >
>> >>> > > What do you think?
>> >>> >
>> >>> > I really like the idea. How we continue with this?
>> >>>
>> >>> Ok let's move quick. I've created a branch in commit 11621.
>> >>> Branches in svn are just copies. And they are cheap --it only copy files
>> >>> once are modified.
>> >>> So if there is some reason to not have such branch (maybe David have a
>> >>> reason against it) we'll roll it back easily.
>> >>>
>> >>> To checkout the branch (which is a copy of trunk/) do this:
>> >>>
>> >>> $ svn co http://iua-share.upf.edu/svn/clam/branches/typedcontrols
>> >>>
>> >>> I've asked the IUA sysadm to add Francisco as a commiter (this might
>> >>> take a day or so).  Hernan you can start commiting patches there.
>> >>>
>> >>> Hernan and Francisco, you should coordinate to keep adding all the
>> >>> changes in trunk to this branch, so we can keep in a "mergeable to
>> >>> trunk" state all the way. And of course, remember that this branch
>> >>> should be alive during a short lapse of time. Does it work for you?
>> >>>
>> >>> Instructions on how to copy changes between brances:
>> >>> http://svnbook.red-bean.com/en/1.1/ch04s03.html
>> >>>
>> >>>
>> >>> About the launch/bazaar thing: I think it's something we want to explore
>> >>> in the future. It gives any developer the possibility to work in his
>> >>> patches with a bazaar branch. Then commiters can pull (mergeable)
>> >>> changes and land it to the main repo.
>> >>> The nice thing is that bazaar (like git) is prepared to work with
>> >>> "merge" operations. And is distributed, of course.
>> >>>
>> >>> P
>> >>>
>> >>>
>> >>> _______________________________________________
>> >>> Clam-devel mailing list
>> >>> Clam-devel at llistes.projectes.lafarga.org
>> >>> https://llistes.projectes.lafarga.org/cgi-bin/mailman/listinfo/clam-devel
>> >>
>> >>
>> >>
>> >> --
>> >> David García Garzón
>> >> (Work) dgarcia at iua dot upf anotherdot es
>> >> http://www.iua.upf.edu/~dgarcia
>> >>
>> >> _______________________________________________
>> >> Clam-devel mailing list
>> >> Clam-devel at llistes.projectes.lafarga.org
>> >> https://llistes.projectes.lafarga.org/cgi-bin/mailman/listinfo/clam-devel
>> >>
>> >>
>> >
>> >
>> >
>> > --
>> > Hernán
>> > http://h.ordia.com.ar
>> > GnuPG: 0xEE8A3FE9
>> >
>>
>>
>>
>
>
> _______________________________________________
> Clam-devel mailing list
> Clam-devel at llistes.projectes.lafarga.org
> https://llistes.projectes.lafarga.org/cgi-bin/mailman/listinfo/clam-devel
>



-- 
Hernán
http://h.ordia.com.ar
GnuPG: 0xEE8A3FE9

More information about the clam-devel mailing list