[ On Monday, February 28, 2000 at 17:42:31 (-0500), William Lewis Brown wrote: ]
> Subject: Re: Private repositories v.s. Open Source repositories
>
> I have not heard of CVSup nor of course used it. It sounds like the
> type of tool for which I am searching. Thanks for the reference.
> I am working with the Mozilla sources. I don't know yet if they
> support any distribution of the ",v" files. The default answer is no.
Ah, Mozilla. I doubt they'd be willing to set up a CVSup server. You
can do a checkout of their source though using anonymous CVS.
> I don't really know what you mean by a "vendor-branched" module. Could
> you explain?
See the node "Tracking sources" (titled "Tracking third-party sources")
in the CVS manual.
Basically any module created with "cvs import" is a vendor branced
module -- i.e. it contains a magic CVS "vendor" branch (1.1.1).
> What happens when I need to update the ",v" files from the remote
> repository after I have added my changes into the trunk? Does CVSup
> just do the right thing? Since I don't really know what the right thing
> is, please tell me. For example, assume that version 1.9 of file X was
> created as the result of a merge of my changes into version 1.8 from the
> remote repository. If the remote repository has a version 1.9 distinct
> from my own 1.9, what happens during the next download of the ",v"
> files, via CVSup??, from the remote repository? Thanks.
If you were using CVSup, like I have done with FreeBSD, you would only
be adding a tag to the CVSup'ed copy of the ``official'' repository.
Yes, CVSup does handle this correctly (assuming you choose a tag name
that won't ever clash with any tag the "vendor" might want to add at
some later date).
>From the locally tagged CVSup'ed copy of the repository you would run
"cvs export my-local-tag-DATE-etc module" and thus locally create a
custom "release" of the third-party code. You would then "cvs import"
the resulting code into another local repository (thus creating the
magic vendor branch). Finally you would create one or more workspace
from your local vendor-branched module and do your work in there,
perhaps making periodic commits and perhaps also tagging local releases
there too.
You can then rerun the CVSup/"cvs tag"/"cvs export"/"cvs import" process
as often as you wish in order to keep as current as you need to be with
the third-party repository. Note that with every subsequent "cvs
import" you'll have to merge the new vendor changes with any local
changes too. Note that the manual (and the runtime "import" report) is
I think still giving wrong advice as to how to do this merge -- you
should instead always use the exact previous and current vendor release
tags on the merge ("cvs update -j PREV -j NEW") command.
With Mozilla though you'll probably have to do something a little more
complex if you need to accurately identify the exact revisions
w.r.t. their repository that you "import" locally. Without having
access to their ,v files you're mostly stuck with using the date you
obtain the source files from them (unless you can guarantee that every
file of consequence has a valid and up-to-date $Revision or more complex
keyword containing their current revision). This is similar to what I
do with NetBSD.
> > The only major caveat here is that you can't easily use normal CVS
> > branches in a vendor-branched module, at least not so long as you expect
> > the normal "features" of a vendor branched module to continue to work
> > properly.
>
> I don't really know to what features your refer.
Everything that makes "vendor branching" useful! ;-) The manual should
help explain in more detail.
(I think most of these problems are caused by the lazy creation of first
revision on a new branch in combination with the fact that a vendor-
branched workspace isn't entirely on one consistent branch at any given
time, at least after the first local modification is committed and
before all files are locally modified. I don't see any solution other
than somehow changing the entire branch-handling architecture of CVS and
thus making it incompatible with any previously created CVS repository.)
--
Greg A. Woods
+1 416 218-0098 VE3TCP <[EMAIL PROTECTED]> <robohack!woods>
Planix, Inc. <[EMAIL PROTECTED]>; Secrets of the Weird <[EMAIL PROTECTED]>
