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

[Hernán Ordiales]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: typed_controls_v13_BigPatchReloaded.patch
Type: application/octet-stream
Size: 114815 bytes
Desc: not available
URL: <http://lists.clam-project.org/pipermail/clam-devel-clam-project.org/attachments/20080717/04ddcf19/attachment-0004.obj>