harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Ellison <t.p.elli...@gmail.com>
Subject Re: [classlib] Preprocessor - CHECKPOINT
Date Thu, 02 Nov 2006 22:09:13 GMT
Etienne Gagnon wrote:
> Tim Ellison wrote:
>>>   For example, if class X of the main version is not part of j2me,
>>>   "process(j2me)" would move this file to a subdirectory ".streams/".
>> Why would you move the files rather than exclude them?
>> I was assuming that the processor would generate a whole new source tree
>> for each process() target, so that you could work on the original
>> checked-out file in it's 'canonicalized form' for Big Java work, or
>> process("jme") into a new location and work in the non-canonical form
>> your Little Java spectacles on.  [...]
> Neat idea!
> I would put the following restriction, though:  one should NOT modify
> more than one target at a time.

Fair enough -- at least for now.

> So, you would probably need some way to prevent parallel modifications
> in "spectacle views".

Perhaps we should agree to use your 'devtarget' term for this :-)

> One way to achieve this:
> process(X,target, destination) =>  Xtarget in a distinct location
>  and X files are changed to read-only and some tracking file F tells us
>  about Xtarget's location.

Sure, should be simple enough if there is a well-known location for this
lock file.  As you say, then developers would work on a single devtarget
at a time in their local workspace, but potentially go back to the
canonical form and switch to another devtarget to check that before
checking in the canonical form.

> So, you would also need:
> release(F)  =>  asks all kind of questions (want to lose changes? delete
>                 files? etc.)
> Of course:
> revert(F?|destination?) => makes X read-write.
> [Hoping this was clear enough...  It's not a very good explanation...]

Yep, I got it; and it seems quite simple with these restrictions.

>> Agreed.  It would be interesting to determine the most effective
>> location for those markers (measured by reverse mapping accuracy vs.
>> number of markers).
> I am a fan of accuracy...  Yet, maybe it would be simple enough if a
> release was always based on a specific svn URL, then the mark could be
> totally exact using svn keywords... :-)

You lost me here.  I'm trying to define tie-points between the
'releasetarget' source and the canonical form.  AIUI this will require
structured comments in the 'releasetarget', right?



Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.

View raw message