Re: Personal CVS repository?

[Pierre Asselin]

J Krugman <address@hidden> wrote:

> For reasons that I'm not too clear on, my supervisor has instructed
> me that he must review my code before each submission to the off-site
> CVS repository, and he wants to do this once a week.

Then you have to play by those rules.  There may be intellectual
property issues.


> My only
> problem with this is that, even when I am the only programmer in
> a project, I prefer to keep a finer-grained version control than
> is possible with weekly submissions to the repository.

> It occurs to me, though, that maybe I could set up a "personal"
> CVS repository off my home directory

Yes, indeed.  Create a directory under you $HOME and run 'cvs init'.
You'll have to get familiar with 'cvs import' too.  Read the docs at
http://www.cvshome.org/docs/manual/cvs-1.11.15/cvs_13.html#SEC104 ,
slowly.  The first import is easy, the imports following that are more
complicated.

In your case, you'll want to keep yourself in sync with commits from
external developers.  Here's what I would do.

    1)  Keep a checked-out sandbox from the public repository, preferably
        from a read-only account so you don't commit by mistake and
        bypass your weekly review.

    2)  Import the said sandbox in your own private repository, to
        the vendor branch.
            outside-sandbox> cvs -d $CVSROOT import -I! -ICVS \
            > path VENDOR import-yyyy-mm-dd
    
    3)  Checkout another sandbox from your private repo.  This is the
        copy you work on.  Hack and commit normally.

    4)  At review time, go to your inside sandbox, and
            inside-sandbox> cvs commit
            inside-sandbox> cvs tag review-yyyy-mm-dd
            inside-sandbox> cvs diff -N -u -rVENDOR > ../to_review.patch

        Go over the to_review.patch with your supervisor.
        If approved, apply the patch to your outside sandbox.
        Commit from there, using a -d option to switch to the
        developer account they gave you, with read-write permission.

            outside-sandbox> cvs -d :ext:blahblah commit

Now there is the problem of keeping your outside sandbox up to date
(easy) and of propagating those changes to your inside sandbox
(takes some gymnastics).  At least every morning,

    outside-sandbox> cvs update
    outside-sandbox> cvs import -I! -ICVS path VENDOR import-yyyy-mm-dd-1

That was the import.  Now the merge,

    inside-sandbox> cvs commit
    inside-sandbox> cvs tag premerge
    inside-sandbox> cvs update -j <previous import tag> -j <last import tag>
fix conflicts
    inside-sandbox> cvs commit
    inside-sandbox> cvs tag -d premerge

The 'premerge' tag is in case something goes wrong with the merge.  It
represents your last good point before attempting the merge.  If the
merge is full of conflicts, you can start a branch off of premerge to
continue your work while your figure out how to finish the merge.


> (although I'll readily admit
> that I've never set up a CVS repository of *any* kind before); I
> would use it for my "fine-grain" version control, while submitting
> new, boss-approved stuff to the "real" off-site repository only
> once a week...

> My knowledge of CVS is very limited; I know a few commands, and I
> never deviate from the most basic functionality.

The potentially hard part is all those imports and merges.  The bit
about setting up your own repository is really trivial.  One annoying
bit is that when you reimport your fresh commits to the external site,
your merge will show spurious conflicts with the same text on both side
of the conflict.  You'll just have to clean them up.


> This "personal"
> repository idea is far more "adventurous" than anything I've done
> with CVS before.

Yes, but it's the perfect thing here.  You commit to your private
repository at your chosen pace and you generate diffs at review time.