Hi Leo, thank you very much for all details and very valuable links! Yes, I'm aware about the existence the technologies mentioned by you.
Actually I meant a little bit other thing. I understand how it works when the patches are integrated to the repository on regular base. After this all customers can create new patches and etc. etc. etc. Here I see no any issues. There are a lot of GUI tools allowing to merge the changes. The number of patches is a constant approximately. I don't understand how it should [or will] work when any of contributions exists long time in the form of zip file. New bugs appear. As a result new patches will be created. The corresponding JIRA issues are linked to the original contribution. And etc. etc. It will be continued until all sources are integrated to the repository. I don't think the customers will be very happy to re-read each time the JIRA description to understand how to get the recent version of product. Maybe the latest situation is hypothetical I don't know. Probably I was wrong when I started this discussion. In any case thanks for your feedback. Regards, Vladimir. On 5/6/06, Leo Simons <[EMAIL PROTECTED]> wrote:
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]
