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

Thu Jul 17 14:34:28 PDT 2008

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)

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
> >
> 
> 
> 