info-cvs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: attic files


From: Kaz Kylheku
Subject: Re: attic files
Date: 3 Oct 2002 18:57:24 -0700

"Stefan Monnier <address@hidden>" 
<monnier+gnu.cvs.help/news/@flint.cs.yale.edu> wrote in message 
news:<address@hidden>...
> > Arguably, adding years to the life of CVS is CVS-friendly enough.
> > There are already enough architectural compromises in the software to
> > make it easy to integrate with CVS.
> 
> But how about a little script that creates a "MAP" file so you
> can smoothly transition from CVS to Meta-CVS.

I have that script; it's called ``mcvs convert''. That's the one
feature I have not been maintaining, because it doesn't do the right
thing. So it's almost certainly broken right now. It could be made to
work again with a little bit of TLC.

What mcvs convert does is scan through your entire CVS module, and
then create hard links to the ,v files to a bunch of F-...,v files
under a new directory. It then creates a MAP file and calls RCS to
check it in to make a MAP,v.

> After all, people don't want to lose that valuable history when switching.

That's debatable; some people don't care that much. Others are
satisfied to have an archive of the old system. Others still can live
with a few significant snapshots being imported into the new system,
like all their major releases or more fine-grained builds. If you have
that, you can still determine in which build a bug was introduced,
even if you don't have all the commit details between that and the
previous build.

> It should be all that's needed to turn a CVS repository into a Meta-CVS
> one, right ?

No. Doing it right is actually very complicated. You see the CVS
repository has a history, and that history contains file removals,
additions, branches, release tags and so on. To complicate matters,
the fidelity of some the information may be low. Tags may be
inconsistently applied, or appear in different orders in different
files and so on.  The problems is reconstructing a fake history of the
MAP file so that you can actually pull out branches and old releases
as they looked like under CVS, and have the MAP reflect their actual
contents.

With the naive approach, what happens is that the MAP has a single
version node, with an entry for every single object, and all branch
and version tags gathered from the CVS module are pointing at that one
node. When you update yourself to baselines that don't have some of
the files, you get annoying errors, because the MAP tells Meta-CVS to
create structure out of files that aren't there.

The job is to identify all symbolic branches and symbolic releases and
re-create version nodes for them in the MAP,v file.  There is some
primordial
code for doing this, but I haven't touched it in quite a while. Basic
parsing of the RCS file to Lisp data structures, etc.

> And while I'm moaning, I might as well say that I find all those capitals
> unnecessary, whereas I'd love to see a leading "." in those names so
> they don't pollute my listings and completions.

Since you aren't going to be descending into the MCVS directory much,
how the contents look like shouldn't bother you. There is only one
MCVS directory in your whole project, at the root level.

> I wasn't asking you to rewrite it in elisp, but just wondering how
> CLISP- (or just CL-) specific it is.

There is no restriction to any particular subset; any feature of CL
can be used. Presently there is some CLOS, structs, hashes, vectors,
lexical closures, various standard macros, restartable conditions,
etc.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]