harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Fedotov, Alexei A" <alexei.a.fedo...@intel.com>
Subject RE: [classlib] Preprocessor
Date Tue, 31 Oct 2006 12:43:22 GMT
Geir,
>We use SVN.  How do you propose to do it cleanly in SVN?

I believe it is possible to maintain branches cleanly in SVN.

Let me claim that the only significant difference between SVN and
advanced source control systems is a set of scripts which help merging
and moving files around.

Why do I call it a set of scripts? For example, the file movement
history in S*n TeamWare is kept in specially formatted commit comments.
Three way merge was a separate program, which was invoked instead of vi
for merge. I liked that product because they really thought about user
experience when were creating it, and not because of a questionable
implementation of that product.

If we miss a specific desired user experience working with SVN, we
better start looking for a system on the top of SVN which has this
feature implemented, or tune our environment with a minor script. This
would cost us less than creating a completely new stack for a
preprocessor.

Let me also add that people are always the key. I completely stopped
using all IDE decorators for ST and switched to the command line
interface after two years of putbacks and bringovers. From the other
side it wasn't hard at all for a newbie to break that system.

With best regards,
Alexei Fedotov,
Intel Java & XML Engineering

>-----Original Message-----
>From: Geir Magnusson Jr. [mailto:geir@pobox.com]
>Sent: Tuesday, October 31, 2006 1:50 PM
>To: harmony-dev@incubator.apache.org
>Subject: Re: [classlib] Preprocessor
>
>
>
>Fedotov, Alexei A wrote:
>> Geir,
>>
>> I tried this preprocessor staff for Java in my previous life. From my
>> experience the maintenance effort is higher for this solution than
for
>> Source Control.
>
>We use SVN.  How do you propose to do it cleanly in SVN?
>
>>
>> 1. I faced first time how slow regular expressions on Java could be.
>> 2. Perl worked fine but no one around me could understand my
>> pre-processing scripts and maintain them.
>> 3. The girl from Ireland beat my clever scripts with Sun's TeamWare
and
>> text editor.
>>
>> +1 for Source Control
>>
>> With best regards,
>> Alexei Fedotov,
>> Intel Java & XML Engineering
>>
>>> -----Original Message-----
>>> From: Geir Magnusson Jr. [mailto:geir@pobox.com]
>>> Sent: Tuesday, October 31, 2006 12:28 PM
>>> To: harmony-dev@incubator.apache.org
>>> Subject: Re: [classlib] Preprocessor
>>>
>>>
>>>
>>> Tim Ellison wrote:
>>>> Mikhail Fursov wrote:
>>>>> What are the reasons to exclude the most standard solution here:
>>> branching.
>>>>> Do you think we need a lot of them?
>>>> I don't think we are excluding any option for maintaining similar
>> code
>>>> streams (5.0 & 6.0, SE & ME, etc.) it's just a discussion at the
>> moment.
>>>> Similarly, I'm not advocating the use of aspects for maintaining
>>>> different code streams; but rather I was saying that IDE support is
>>>> likely going to be a requirement for any technology (apt,
>> preprocessor,
>>>> post-processing, aspects, ...) that we choose to solve the problem.
>>>>
>>>> I'm sure we wouldn't even want simple branching without a decent
>> merge
>>>> tool to keep things in sync.
>>> Yes - that's what I'm scared of.   A branch solution sounds like it
>>> leads to much misery and woe, because i think all the factors that
make
>>> this such an interesting problem for which a pre-processor is a
valid
>>> solution this implies the requirement of some kind of conditional
merge
>>>
>>>> I agree with Geir that we should endeavour to choose a technology
>> that
>>>> has broad tooling support.
>>>>
>>>> Regards,
>>>> Tim
>>>>
>>

Mime
View raw message