Re: attic files

[Kaz Kylheku]

"Stefan Monnier <address@hidden>" 
<monnier+gnu.cvs.help/news/@flint.cs.yale.edu> wrote in message 
news:<address@hidden>...
> >>>>> "Kaz" == Kaz Kylheku <address@hidden> writes:
> > I have that script; it's called ``mcvs convert''. That's the one
> 
> Sorry, I missed it.

I looked at the source; it's broken. I never updated it to use the new
MAP format since the symlink support was added. It should also pull
out the execute permissions and represent them properly.

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

That's not all; how about reconstructing the renames properly? Suppose
that in the history of the CVS sandbox, someone removed a foo.c, then
added a bar.c with exactly the same contents and kept going. The grab
command can figure this out from snapshots; so the convert command
should do no worse, right?

So you are looking at: taking the contents of foo.c,v and bar.c,v,
determining that they are supposed to be the same object, and then
merging their RCS files into one RCS file, and storing the appropriate
information in the appropriate faked out version nodes of the MAP
file.

> > 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.
> 
> Well, I have many small projects.  I guess I could turn them into
> a single large project, hmmm....

You could. Note that Meta-CVS supports the concept of a ``partial
sandbox''. If you type ``mcvs co project sub/dir'' then you get a
sandbox called ``dir'' containing only the specified subdirectory.
This is (currently) not efficient in terms of reducing the amount of
material actually downloaded from CVS, but it gives you the high level
semantics of having checked out just that subdirectory, which can be
useful. As a developer you can pretend that you have a bunch of small
projects. As a release manager, you can treat them as one big project:
branch the whole world at once, tag a release over all the projects,
etc.

If someone renames a file from your visible area into an area of the
project that is not visible in your partial sandbox, or moves files
into your sandbox, this is intelligently handled, and you see messages
like:

   * moving foo.c -> (out of sandbox)
   * moving (out of sandbox) -> bar.html

The grab command supports partial sandboxes also; this allows you to
track third party code at the component level, rather than
whole-project level. For instance if there is some interesting library
you'd like to add as a subdirectory of your project, just add an extra
parameter to grab to specify the subdirectory name. Only that
subdirectory is synchronized to the third-party tree; the invisible
parts of the project are ignored and untouched. If you don't plan on
making any local modifications to it right away, you can just grab
snapshots of it directly to the trunk.

The current Meta-CVS has features that are not described at all in the
Jan. 25 paper, and the format of the MAP file is different too.