From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: a07f3367d7,8d33ebaa85598950 X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII-7-bit Received: by 10.216.202.93 with SMTP id c71mr214647weo.3.1348190012333; Thu, 20 Sep 2012 18:13:32 -0700 (PDT) Path: ed8ni3498083wib.0!nntp.google.com!feeder2.cambriumusenet.nl!194.109.133.84.MISMATCH!newsfeed.xs4all.nl!newsfeed5.news.xs4all.nl!xs4all!feeder1.cambriumusenet.nl!feed.tweaknews.nl!85.12.40.131.MISMATCH!xlned.com!feeder3.xlned.com!news.astraweb.com!border5.a.newsrouter.astraweb.com!border2.nntp.ams.giganews.com!border3.nntp.ams.giganews.com!border1.nntp.ams.giganews.com!nntp.giganews.com!newsreader4.netcologne.de!news.netcologne.de!weretis.net!feeder4.news.weretis.net!news.mixmin.net!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: GPS issues: laundry list Date: Tue, 18 Sep 2012 10:35:03 +0200 Organization: cbb software GmbH Message-ID: References: <854nn34fv2.fsf@stephe-leake.org> <1unaedlxs0o9j$.lbivg0rltyvw$.dlg@40tude.net> <85r4q62nw0.fsf@stephe-leake.org> <1b2nanavkx67n$.1rkpkv1o50bkj.dlg@40tude.net> <85d31p2g9s.fsf@stephe-leake.org> <851ui3ivac.fsf@stephe-leake.org> <85obl4ibd5.fsf@stephe-leake.org> Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: FbOMkhMtVLVmu7IwBnt1tw.user.speranza.aioe.org Mime-Version: 1.0 X-Complaints-To: abuse@aioe.org User-Agent: 40tude_Dialog/2.0.15.1 X-Notice: Filtered by postfilter v. 0.8.2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Date: 2012-09-18T10:35:03+02:00 List-Id: On Mon, 17 Sep 2012 17:32:38 -0400, Stephen Leake wrote: > "Dmitry A. Kazakov" 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 /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