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

Thu Jul 17 14:18:28 PDT 2008

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.

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
>

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