"Stefan Monnier <[EMAIL PROTECTED]>" <[EMAIL PROTECTED]> wrote in message news:<[EMAIL PROTECTED]>... > >>>>> "Kaz" == Kaz Kylheku <[EMAIL PROTECTED]> 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. _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
