KDevelop UI

[Andreas Pakulat]

On 20.07.07 13:56:26, Kris Wong wrote:
> > Right. However if somebody changes an interface that is used, 
> > he/she has
> > to fix all uses of that interface or talk to the authors of the
> > plugin(s) in question and coordinate the fixing. This can be 
> > done inside
> > the feature branch as well. And on the next merge to trunk 
> > its still all
> > "fixed".
> 
> Therein lies the problem.  If I were to fix something in an existing
> piece of code that someone else is either working on, or was updated by
> someone else, this will result in a merge conflict.

And why is that a problem? Sure the conflict needs to be resolved, but
the same thing happens if you work on trunk/ and don't commit for a
while because your stuff is not done yet.

> > I don't see the problem here as features are mostly done in separate
> > parts of kdevelop (i.e. the plugins). For the platform its a bit
> > different, but platform itself doesn't have all that much 
> > logic (except
> > shell/ and sublime) so I don't think it happens that much that you
> > change something in platform and screw somebody else's changes by that
> > even though it merges without conflicts... Also branches that 
> > exist for
> > a longer period of time (think > 1 month) should merge from trunk/ to
> > branch occasionally.
> 
> Well, you can speculate, or take it from someone who's done this sort of
> thing on many occasions in the past. =]  I'm sure some of the more
> experienced devs out there know what I am talking about.

I wasn't purely speculating. If you look at the commits there's been
really only little work done on any of the platform libs (except
language which is changed due to SoC). And those changes are not that
bug. 

And btw, I do have experience with developing everything in trunk and
its not really any better IMHO.

> > Right, but as everybody is supposed to build and test before 
> > committing
> > (that includes building and running unittests as well as running the
> > application) it shouldn't be that huge of a problem. (Hopefully)
> 
> Building and testing doesn't have anything to do with it.

Yes it does, it makes sure that combining your branch changes and
changes happened in trunk don't break anything. Which might happen even
though no merge conflicts arise.

> Anyway, I've said pretty much all I'm going to say here since:
> 1. I'm not really that active anyway, and
> 2. I am not the one who will have to deal with this.

Well, I'm not sure that letting Matt handle all merge's is such a good
idea.

Andreas

-- 
Domestic happiness and faithful friends.