Back then people would just discuss bugs or features on the mailing lists. Developers would at best keep a TODO and BUGS text file to remember important things they wanted to do/needed to fix. Things were also a lot less intense since the Internet had a lot less people. If you even had Internet access in the first place. None of this dozens or hundreds of people communicating with developers thing. That is why bug trackers are so relevant today and back then people usually did not bother.
On Wed, Jan 12, 2022 at 11:20 PM Christopher Sean Morrison via brlcad-devel <[email protected]> wrote: > Douglas, > > On Jan 12, 2022, at 5:31 PM, willful merriment via brlcad-devel < > [email protected]> wrote: > > > thank you so much for your reply. Yes, for me the term change set would > correlate to a revision in a repository. I don't have the SVN change long > in front of me but yes it seems that 1984 is about the BOT for the repo. > It is the time starting from something like 1979 on I was asking about. As > to the SVN change log, the typical comments are "one line change", "spider > pig crawls", "depreciated"... > > > Don’t really agree with the characterization that those are typical (if > one can even summarize anything across 80,000 commits as being “typical”), > but shorter less helpful messages were more common dev practice prior to > 2004. Since then, you’ll find such commit messages are quite rare. > > The project goes back to 1979 but version control systems do not. CVS > came into existence in 1990. RCS around the time of our repo, 1982 I > think. There may have been some things in SCCS during the VAX/PDP days, > but such nuance is lost to time. Is there a reason you’re looking to go > back that far? > > You do realize how exceptionally rare it is to find a project that has > preserved history across revision control systems back this far? You seem > to be applying modern standards about 20 years too many… :) > > If it’s to understand origins, BRL-CAD’s were/are extensively documented > in formal publications, reports, and presentations. That was how things > were done back then. This may help: > https://brlcad.org/BRL-CAD_Bibliography.pdf > > Most of those are available online or can be accessed in a library. > > As to reading the changes and inferring the intended affect, that seems > obviously backwards. Yes git can show that graphically, but gets no one > any closer to understanding the motivation for the change. In my > experience the bugs list is indispensable in understanding the motivation > for the change, steps needed to replicate a problem and often discussions > between developers. > > > No bug tracking system goes back as far as our sources, so what you’re > hoping for simply was not a thing in the 80’s. Prior to GitHub and general > issue trackers, circa 2000, it was not at all common to use bug report > interfaces for discussion, understanding, or requirements traceability. As > I mentioned earlier, there are trackers on SourceForge and they will get > you back to around 2004-2018 with issues, feature requests, and bugs > tracked and discussed separately. There is also loads of documentation in > the aforementioned bibliography. > > Mailing lists were also common in the late 80’s early 90’s for design > discussion and BRL-CAD’s email archives are also in the repository in the > doc/ directory. > > If you have specific questions about the code or a given commit, please > feel free to ask. > > Cheers! > Sean > > > _______________________________________________ > BRL-CAD Developer mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/brlcad-devel > -- Vasco Alexandre da Silva Costa PhD in Computer Engineering (Computer Graphics) Instituto Superior Técnico/University of Lisbon, Portugal
_______________________________________________ BRL-CAD Developer mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/brlcad-devel
