Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Received-SPF: neutral (herse.apache.org: 216.86.168.178 is neither permitted
 nor denied by domain of geir@pobox.com)
Message-ID: <454D343E.7030400@pobox.com>
Date: Sat, 04 Nov 2006 19:45:50 -0500
From: "Geir Magnusson Jr." <geir@pobox.com>
Reply-To: geir@pobox.com
User-Agent: Thunderbird 1.5.0.7 (Macintosh/20060909)
MIME-Version: 1.0
To: harmony-dev@incubator.apache.org
Subject: Re: [classlib] Preprocessor - an attempt at [even more] clarity
References: <8E389A5F2FEABA4CB1DEC35A25CB39CE694EF8@mssmsx411>
	 <45473BA9.1070709@gmail.com>
	 <bc79dd600610310412w6b7a64dfo3c4758ddb14409c0@mail.gmail.com>
	 <45474144.5060108@pobox.com>
 <4547431C.5080000@pobox.com>	 <3b3f27c60610311705q1cb2aeb1wa78d0c55fb7f026b@mail.gmail.com>
	 <4547F8D5.9040409@pobox.com>
 <454870F8.8080302@gmail.com>	 <454884DC.7070806@pobox.com>
 <4548A644.6060403@sablevm.org>
 <bc79dd600611010659rb7bd511p998f88c7d6deb591@mail.gmail.com>
 <4548BB62.7050503@sablevm.org> <45496DA6.9000708@pobox.com>
 <454A3BE6.7000008@sablevm.org> <454A3D9F.3090904@pobox.com>
 <454A4185.6070700@sablevm.org> <454A4A9A.4090509@pobox.com>
 <454A53EE.9040505@sablevm.org> <454A5A5C.7040305@pobox.com>
 <454A72C4.5020202@gmail.com> <454A77E8.3010305@pobox.com>
 <454B1C48.3060302@gmail.com> <454B3BB4.3030103@pobox.com>
 <454B6503.3010809@gmail.com>
In-Reply-To: <454B6503.3010809@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit


Tim Ellison wrote:
> Geir Magnusson Jr. wrote:
>>
>> Because I can imagine that as a SE programmer, I would want 1 of 2 things :
>>
>> 1) clean code to work on for a specific target (say SE 5)
>>
>> 2) a hybrid version of your dev1 that only has the glop for a subset of
>> the platforms (say just Java SE 5 and Java SE 6) in it, so I can focus
>> across just those two.
>>
>> Maybe it's just me, but I'd probably want the distractions of other
>> platforms out of the code so I can get better into the 'flow' when
>> developing.
>>
>> So that's why I think of dev1/2/3 as being the virtual code (not key to
>> the process) that can be generated either by the tooling onto disk as a
>> temp form, or by IDE virtually in situ.
> 
> but how do you resolve the ambiguity of where new/moved code should go
> in the master if you are working in a dev that has lost the context of
> other streams?

I want to make sure I understand what you are asking - I think you are 
asking the question "As a developer, if I can't see the content of the 
other streams, how can I place the changes in context of the other streams?"

It's not clear to me that there's a big problem here - the fact that a 
complete master exists means that when you "commit" your changes to the 
master, you can resolve ambiguities in placement relative to other 
streams at that time, *if* there are any.  (For the life of me, I can't 
figure out how to mechanically characterize an ambiguity...)

The big question here is if that's a reasonable approach, and the answer 
will be based on how often it happens.

If it happens in 1 in 50 "commits", I'd argue that the benefit of the 
reduction of clutter is worth it.  If it happens every time, it's 
clearly going to be a royal PITA.  I don't know actually where to draw 
that line.  I expect testing with toy examples will help us figure it out.

> 
> it's the point that was made here:
> http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200611.mbox/%3c454A4185.6070700@sablevm.org%3e
> 

I went back and review that, and I keep getting this nagging feeling 
that we're being a bit naive about this, but I can't put my finger on it 
and explain why :)  I'll try to explain in a separate post.

> it would be cool if we could do that.

Yes - my goal here is to make this as transparent as possible to the 
working harmony developer.

> 
>> Further, there aren't just N dev forms for the N distinct
>> platforms/version, but rather the freedom for combinations where they
>> make sense (a dev w/ SE 6 and SE 6 only)
>>
>> If you want to generate a dev1 and work on that on disk, great - do it,
>> you can go back to master.
> 
> Only if the reverse mapping is exact, which I believe means that you
> need to take the full master context along with you.

I don't believe so. I need to do some tests.  The reason I don't believe 
so simply because the master context exists in the master (by defn), 
which always is a part of the "commit" process - IOW, when committing a 
  dev1' (modified dev1), you can regenerate the clean original dev1 from 
master, then find your diffs to that from dev1' (the modified thing you 
are committing), and map those back into the master.

I think.

[SNIP]

>>
>> Or in simpler terms, the model differences seem to boil down to this.
>> Given N possible targets:
>>
>> 1) Master is concrete, dev1..M (where M possibly > N) are generated
>> simply for ease of use either as concrete tree on disk or virtually in IDE
>>
>> 2) Master is virtual, dev1..N are concrete, one dev form is Most Favored
>> Nation Status so something coherent can be shoved into SVN (Q: is MFNS
>> necessary? Nice, yes, but necessary?)
> 
> Yes, that seems to be the difference.  I'd like to be convinced that
> working in dev1..M code is possible in approach (1).

Yes, and I can almost prove now that not having a master is unworkable, 
because we're not talking only about file content, but different files, 
and different directory structure.  So if the classlib code spans both 
versions (SE 5, SE 6) as well as platforms (ME, SE), the build process 
will require processing to deal with that during the build.  if that's 
the case, then you are in case 1), not 2).

I'm going to try to cough up some simple use-cases of code trees and 
toss in the sandbox.

geir