Re: GPS issues: laundry list

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Mon, 17 Sep 2012 17:32:38 -0400, Stephen Leake wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> 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?

It re-maps them to other files.

ClearCase, for example, has a virtual file system for doing this
efficiently.

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

You would have to write a lot of software in order to support that on top
of primitive file versioning.

If funding is no problem for you, why not to buy ClearCase?

> First, every time
> you change versions, you have to recompile (unless you use a version
> control system that maintains compiled files, which I hate).

No. It is a different way of handling dependencies.

The things your project depends on are *already* compiled and their state
is frozen in the code management system. In fact you cannot refer to
anything that is not compiled and checked in, unless that is not your
project. And in our system projects are encouraged to be small, even empty.
That is when we aggregate existing projects in order to deliver them to the
customer. Such an aggregate project may have no sources at all.

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

Any decent system supports that without checking out. Our system is very
punitive to checkouts. You cannot check out anything from the project
without scheduling a new version of it. And once you do, nobody can check
out that project again. We do everything to prevent branching. We never
ever merge any files.

You would not need to compare anything, if you worked the way we do. I
don't remember the last time I did. The reason why you are comparing
versions is mainly because, effectively, you do not version projects.

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

How could you use both versions in one project? Otherwise, it is absolutely
no problem.

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

And how do you select the proper versions/paths of hundreds of projects? In
our case each library is a project. Each project has a dependency list
where the version is specified. When the project is mapped or checked out,
the right versions of all projects it depends on are automatically mapped.

As I understand, you are running a poor-man's project management by mapping
project versions onto directories. We started it this way 15 years ago and
when it became an expected catastrophe 5-7 years later, we were forced to
build a proper project management system.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de