wongk at seapine.com
Fri Jul 20 17:56:26 UTC 2007
> 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
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.
> Well, even if the branch exists for a longer period of time, its meant
> to be merged every now and then when a new subfeature works. Also
> currently few people work on the same plugins so for kdevelop there's
> not much common code anyway - thats all in kdevplatform.
This is the area where I forsee issues.
> 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.
> Right, but as everybody is supposed to build and test before
> (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.
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.
More information about the KDevelop-devel