I think what I've learned in the last two days is that I needed to tag all files when I checked them in (both Frame and online help files). Previously, I hadn't known that. So I'll be religious about that from here on in. That way, we can roll back to a previous time and re-release the docs as they were on that date, while still allowing me to check in new files as we move forward in the development/documentation process.
That may be obvious to others, but it wasn't to me. D'oh! Also, I've learned a bit about how NOT to remove files. We had literally hundreds of outdated and unused images in CVS and I wanted to hide them from showing up when I checked in my new files b/c they were confusing and just plain unneccessary going forward. (I'm a big believer in careful housekeeping. Why carry forward hundreds of unused images?) Unfortunately, the method our old release engineer told me for removing them was a permanent "hard" delete that caused no end of problems when we tried to roll back to a previous date and time. So if anybody knows a better method for dealing with this, that'd be helpful. The third problem we have yet to solve may have had to do with changing the case on some file names and caching within CVS, but I can't quite get my head around that one yet - not enough to explain what happened and why. So chalk it up to one of those painful learning experiences. I now know a bit about CVS that I didn't know before. Bottom line for all you others out there who may find yourselves in my position: Tag early, tag often... Karyn >From: "Combs, Richard" <richard.combs at Polycom.com> >To: <framers at FrameUsers.com> >Subject: RE: Methodology for Source Code Control >Date: Fri, 23 Jun 2006 10:55:45 -0600 > >Karyn Hunt wrote: > > > So I'm wondering, how many of you out there use branching > > when checking your Frame files in to a source code control > > system and how many of you just overwrite in one place? > >And Laura Sponhour wrote: > > > Harvest can't compare FM files, so, like you, we don't have > > branches to go back to for versions from previous releases. > >We don't check our FM files into our source control system (Subversion, >but it used to be CVS), only the Help and PDF files that go into the >software build. So I'm not exactly an expert on this stuff. But, I don't >understand what you mean by "overwrite" and not being able to go back to >previous versions. > >The whole point of a source control system is to never "overwrite" >anything and to keep every version. Whether you check files into a >branch or into the head is irrelevant. You should be able to go back and >get any FM file that you committed to the repository. > >Committing a new version will never "overwrite" a previous version; the >only way a previous version disappears from the repository is if someone >consciously and deliberately removes it. Which, I suppose, someone could >do (but it would be wrong!) because of the space problem binary files >create... > >You see, source control systems are primarily intended to store text >files, and can do that very space-efficiently: they can compare two >versions of a text file and only store the deltas -- the differences >between the previous version and the new one. Each new commit of the >file adds only a small set of deltas to the repository, which can >reconstruct any commit version by assembling the correct deltas. > >When you store binary files (like FM files), most source control systems >can't compare/diff those, so they have to store a complete new copy of >the file each time it changes. That's why a lot of source control system >admins don't want you checking in your docs -- you eat up massive >amounts of disk space, compared to the programmers' source code (text) >files. > >If earlier versions of your docs are deliberately being removed from the >repository because of space problems -- well, that pretty much defeats >the whole purpose, so you need to rethink your process completely. But >unless that's happening, every version of every doc you checked in >should still be in the repository. > >HTH! >Richard > > >------ >Richard G. Combs >Senior Technical Writer >Polycom, Inc. >richardDOTcombs AT polycomDOTcom >303-223-5111 >------ >rgcombs AT gmailDOTcom >303-777-0436 >------ > > > > >_______________________________________________ > > >You are currently subscribed to Framers as karyn_hunt at hotmail.com. > >Send list messages to framers at lists.frameusers.com. > >To unsubscribe send a blank email to >framers-unsubscribe at lists.frameusers.com >or visit >http://lists.frameusers.com/mailman/options/framers/karyn_hunt%40hotmail.com > >Send administrative questions to lisa at frameusers.com. Visit >http://www.frameusers.com/ for more resources and info.
