RE: Copying parts of a repository, excluding revisions post-TAGNAME...

[Greg A. Woods]

[ On Wednesday, December 31, 2003 at 14:48:48 (-0800), Leander Hasty wrote: ]
> Subject: RE: Copying parts of a repository, excluding revisions 
> post-TAGNAME...
>
> Hmm.  This does avoid having to accumulate the tags post-TAGNAME to pass
> to "cvs tag -d".  "cvs admin -oTAGNAME::" dies on discovering any tags
> for later revisions.

Wow.  That's not something I would have expected, even had I been fully
aware the '-o' option for "cvs admin" had that enhanced "::" feature.

Although I didn't know off the top of my head that "cvs admin" had an
enhanced '-o' option, I didn't even bother looking because of your note
about the inexperience of your vendor's CVS administrator(s).  I thought
it would be better/safer if they modified a copy of their repository
directly with RCS commands than risk getting confused and do damage to
their real CVS repository with a mis-typed "cvs" command.

(someone really should port the "-o::" feature back to RCS and get a new
RCS release made too!  ;-)

>  It probably makes sense to make sure the dangling
> tags are deleted (or redirected to head, or something else safe).

I am assuming you'd only be using the repository copy in a read-only
manner and that any extra "future" tags will simply be ignored.  Surely
they don't give away any information your vendor doesn't want you to see
(yet).

It would be my strong opinion that if any CVS command breaks in the
presence of tags for non-existant revisions then that would indicate a
serious bug in CVS.  A warning message might be appropriate for some
commands if '-q' is not given, but that's all.

> I've passed along an inquiry about whether the cvs tree contains any
> branches post-TAGNAME to the other company.

If there are any branches at all then your vendor may not want you to
see what changes are on some or all of those branches.

They may also consider commits to any branches more recent than the time
they tagged the release to be proprietary.

I.e. the real question is why they don't want you to see future code
that they've not yet officially released to you.

>  If they do, it seems I will
> probably have to script something slightly more sophisticated, along the
> lines of what Mark D. Baushke suggested.

If it gets that complicated then I'd suggest getting the "future" code
included in your mutual agreement so that you and your colleagues can
view it all without concern.

Alternately maybe you could simply ask them to make a backup copy of
their repository immediately after tagging the next release they give
you and give you that backup copy.  Even if they have very active
developers and the module(s) they're giving you are very large it's not
likely there'll be much, if anything, leaked to you.

Otherwise just ask them to run "rcs2log" and ship you the result with
the exported code and be satisfied with that.  While all of the pruning
of branches is possible, it seems it would be vastly more work than it's
worth, even once it's turned into a safe and reliable script.  Sure it's
nice to be able to see a diff to understand a change, but if you're
really having trouble grasping their past changes to their code then
presumably you can ask them directly for help.

-- 
                                                Greg A. Woods

+1 416 218-0098                  VE3TCP            RoboHack <address@hidden>
Planix, Inc. <address@hidden>          Secrets of the Weird <address@hidden>