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=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,6511c3dc6e1155c9 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!postnews2.google.com!postnews1.google.com!not-for-mail From: kaz@ashi.footprints.net (Kaz Kylheku) Newsgroups: comp.lang.ada Subject: Re: GWindows and David Botton Date: 18 Oct 2004 19:48:00 -0700 Organization: http://groups.google.com Message-ID: References: <2004100312401227544%david@bottoncom> <87zn31njc6.fsf@insalien.org> <10m5opffddc6e4d@news.supernews.com> <87r7odnhv0.fsf@insalien.org> NNTP-Posting-Host: 204.50.29.160 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: posting.google.com 1098154081 8288 127.0.0.1 (19 Oct 2004 02:48:01 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Tue, 19 Oct 2004 02:48:01 +0000 (UTC) Xref: g2news1.google.com comp.lang.ada:5426 Date: 2004-10-18T19:48:00-07:00 List-Id: Stephen Leake wrote in message news:... > Ludovic Brenta writes: > > > I cannot help but think that CVS is the "C" of revision control > > systems. Ada programmers deserve better than that :) > > I hadn't thought of it quite that way :). > > > With Meta-CVS, one can get the best of everything: the SourceForge > > CVS server and surrounding tools, without the annoying CVS > > deficiencies. > > > > At least, I think Meta-CVS is worth a look. > > If Meta-CVS is a purely client tool, then each developer can use it or > not; it doesn't have to be a project-wide choice. Such a tool can't do the things that Meta-CVS can do. People have played around with scripts to do things like simulate renaming over standard CVS projects that can be fully checked out with a regular client. In the Meta-CVS project, I did not want to aim the guns that low into the ground, but rather elevate the muzzle above the horizon. I just wanted to reuse all of the behaviors that CVS does reasonably well: namely keeping a vector of text documents synchronized between a remote repository and a local sandbox, with support for parallel editing, branching and merging. In order for an element of this vector to retain its identity, while changing its name and position within the filesystem tree, it is necessary to represent that name and position as a separate property. The name, as known to CVS, then just becomes an abstract identifier, which might as well be based on some 128 bit number or something like that. The question is where to store the name? The simplest answer is to store it in some other file which can also be versioned, and subject to branching and merging. This way, when you check out the database, all you have to do is parse this file, and arrange the rest of the documents into a tree, which can be done using efficient hard-linking operations, rather than bulk transfer of data. In fact, what Meta-CVS does is keep a farm of hard links so that it has the original vector as checked out by CVS. CVS checkouts and updates take place in this farm area. A restructuring algorithm reshapes the tree by looking at the differences between the current structure and the newly desired version. A simple synchronization algorithm repairs any broken hard links between the tree and farm. > I already use CVS for _everything_. While in general I'm in favor of > learning new tools, in this case I'm sticking with CVS. Meta-CVS is my way of expressing essentially the same attitude: I'm sticking with CVS! Only I'm going to make it jump through hoops that over years of CVS mailing list discussions declared impossible, that's all. ;)