harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vladimir Gorr" <vvg...@gmail.com>
Subject Re: DRLVM contribution - try this out!
Date Sun, 07 May 2006 06:36:11 GMT
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
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
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.


On 5/6/06, Leo Simons <mail@leosimons.com> 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: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message