> From: Greg A. Woods [mailto:[EMAIL PROTECTED] > 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 _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
