J Krugman <[EMAIL PROTECTED]> 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. _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
