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! cheers, Leo [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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
