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

[Pau Arumí]

On dj, 2008-07-17 at 21:03 +0200, David García Garzón 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 was curious about your reaction on this particular branch proposal.
Seems clear that you are even more not-keen-on-svn-branches than me :-)

I agree with you that we could do better to have a smaller delta between
trunk and the patch.

On the other hand, I perfectly agree on the point stated by Hernan (on a
parallel mail, seen after started this mail): a) the patch is evolving
way too much b) there are a lot of changes spread over all the code that
makes changing Control to TypedControl potentially dangerous and need to
be thoroughly tested (I'd like running a multi-platform testfarm on that
branch, for example)

On (yet) the another hand (3 hands sometimes is, er, handy), you are
depicting the subversion branch hell a little worst that I see it.
First of all, because it should be short lived, so we don't expect many
changes to happen in the same files. Second, you have to take a VERY
systematic methodology but it works: the branch maintainer monitors the
changes in trunk, then does the merge using a standard commit message,
such as " MERGE FROM TRUNK revisions 12000:12004"
Next merge will start on 12005, etc. (if you mess the numbers
"la-cagaste", yes, so don't mess it). Following this, the diff between
trunk and branch is mergeable to trunk. Right? (or I'm missing some
chance for nasty things to happen?)

Conclusion:

Let's begin makeing the delta smaller: Let's put some effort analyzing
the patch, and see a) what can be readily commited and b) strategies to
prepare the big change by safe commitable steps (David is good on that).
When/If we see that there is a considerable gap to jump (several changes
that will need a lot of testing) then let's branch (we can reuse the
existing one synching to the latest trunk)
If we get stuck in this small-safe-commits path (maybe because core
developers don't have enough time to devote on it), let's unblock it by
going to the branch.

You buy it David and Hernan? 

P  


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