harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leo Simons <m...@leosimons.com>
Subject Re: DRLVM contribution - try this out!
Date Sat, 06 May 2006 10:07:49 GMT
Hi Vladimir!

On Sat, May 06, 2006 at 08:13:25AM +0700, Vladimir Gorr wrote:
> Certainly all I'll say is obvious

Don't worry about that one bit. I highly doubt this stuff is obvious for most of
the people reading this list -- you're getting a bunch of responses because its
an interesing topic, not because its an obvious one :-)

> but ...
> Suppose the patches A & B should change same lines of sources code to fix
> the different bugs.
> They cannot be accepted independently.

This depends on the specific patch. For example patch A might touch files x and y,
and patch B might touch file z. The patch will then apply "cleanly". For cases
where it doesn't (both A and B touch file x, and the "chunks" of the patches do not
all apply cleanly to that file), its a little more involved.

There is an extensive patch/diff/merge toolchain to take care of this kind of thing.
Basically it is the main secondary activity for the maintainers of the linux kernel
these days (the primary one is reading/verifying/discussing patches), and git
(http://git.or.cz/) is all but completely dedicated to this kind of use case.

If it is about source tree X and patches A and B the problem is called a "three-way
merge" [1]. If it is about source tree X and patches A1,A2,...,An it is sort of an
"n-way merge", which becomes n-1 three-way merges.

> Other example when the B patch is
> created after as A was accepted.
> In this case we should describe the exact order these patches should will be
> accepted in (a good example is JIRA-443).

Yep! One common way to do this is to postfix the filename for the patch with a
number, eg you get a classlib.patch.txt.1, classlib.patch.txt.2, etc etc.

> I  had in mind these things speaking about the advisability to have one
> patch for the user convenience.

Understood, and many thanks for that! I just think that "parallelized patches" is
a problem (or rather, challenge!) that harmony needs to deal with anyway (since
there is potential for huge numbers of patches especially from users of the class
libraries later on in the project) so we might as well accept it as a given and
design our workflows to match!



[1] - http://en.wikipedia.org/wiki/Merge_(revision_control)#Three-Way_Merge

Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org

View raw message