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

[Leander Hasty]

> From: Greg A. Woods [mailto:address@hidden 
> Sent: Thursday, January 01, 2004 10:32 AM

> 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.

Yes and yes, I believe.

> >  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.

I think we're looking into getting the post-TAGNAME code, hopefully
something will come of it...

> 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.

Unfortunately I don't know if they'll be tagging any more releases any
time soon.  =(

> Otherwise just ask them to run "rcs2log" and ship you the result with
> the exported code and be satisfied with that.  

Ah, interesting.  Thank you -- another utility to go tinker with.

> 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.

"Safe" and "reliable" are the key words here, of course.  :sigh:  I
think I'm inclined to agree, overall.

Even if we had to just delete any entries in the RCS-file that were
timestamped after the TAGNAME checkin and have a non-working RCS file,
this would probably be better than nothing.  It probably would still
take a reasonably robust script not to delete something it shouldn't,
however.

> 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.

For the same reason that they won't be tagging any more releases, asking
for help is a bit difficult.  We're working on this, too, but as with
all things, this takes time.

Most of the reason we need the history is around is to track feature
changes -- a lot of code-paths in this project end very abruptly and
unexpectedly, and several hours into investigating a feature we'll find
that it dead-ends and has been replaced by a completely different
system.  Some also induce crashes for unknown reasons, and the
changelogs would help in tracking these down too.

--
Leander Hasty