Re: GPS issues: laundry list

[Stephen Leake <stephen_leake@stephe-leake.org>]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

>> You have misunderstood what I'm proposing; I'm not editing file _names_,
>> just what directory the project is checked out in.
>> 
>> For version 07, the project is in mms_version_07/*. For version 08, the
>> project is in mms_version_08/*.
>> 
>> How else would you do it?
>
> I would have the stuff in a source control system. I mean a true system
> which maintains consistent project views rather than merely tracking
> individual files. 

I do; monotone.

> The project (under the source control) would depend on the project
> MMS, which is in some DB. You change current view from v7 to v8 by
> changing the project dependency.

What does that do to the directories on the disk?

I'm guessing you are saying:

1) only use one directory to check out the files; say <some root>/mms

2) to change the version in the directory, use the appropriate monotone
command

That is certainly possible, but extremely cumbersome. First, every time
you change versions, you have to recompile (unless you use a version
control system that maintains compiled files, which I hate). Second,
there are _many_ times when I want to compare changes between two
versions, and it is much simpler to do that when both are checked out.

But most importantly, I have customers using both versions (some have
not upgraded yet), so I need both versions checked out and compiled.

That's why I need <some root>/mms_version_07, /mms_version_08

> This is how we maintain our middleware project. It depends on hundreds of
> other projects of third-party libraries, drivers etc. It would be
> impossible to handle it using your way.

No, it would not. If I counted all the OS libraries I use, mine probably
depends on hundreds as well. 

In any case, that is othogonal to the issue at hand, which is how to
specify ADA_PROJECT_PATH properly.

>>> GPS is an IDE, it is not a language. 
>> 
>> Correct. But I can customize it by writing Python and XML, so I want
>> adequate documentation to help me do that.
>
> Can /= must. Customizable IDE defeats the purpose of. 

Ok, you don't want to discuss the issue. Never mind.

> This is what makes MS Developing Studio so uncomfortable. Once you
> start customizing anything, you open a hell of problems how do I
> manage customizations. How do I switch them, how do I store them, how
> do I version them, how do I train personal on them, how do I keep them
> in the incoming version of the tool...

All of these problems are solved nicely by a monotone project of Emacs
customizations. Well, except the 'train personel', which I accomplish by
working on the same hallway ...

-- 
-- Stephe