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
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 <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
>
>

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