Re: Handling project documentation using CVS

[James Knowles]

I'm in a similar situation.

> I am debating whether or not it makes sense to put this stuff into my CVS
> repository.  

What is your alternative? If you don't have any other approach, then DO IT!
Better CVS on binary data than nothing at all. I can't count how many times
I've said, "OOPS!" and lost something forever. Once is excusable. Twice
isn't. 

> Just
> create a
> subdir called "docs" in my source tree, 

That's what I do for each project. Each project has a bin, obj, doc, src,
and test subdirectory. Only things in doc, src, and test are actually
checked in. The others are for automatically creating the directories. 

This works fine for our purposes. We don't have any need to check out the
documentation divorced from the rest of the project. If you do, then a
second module may be appropriate.

> On one level, I have a feeling that CVS isn't the best way to handle
> versioning these documents.  

What are you looking for? Of course, one can't do a diff between versions.
If you don't make lots of small changes, CVS is fine as a repository. If you
do, things may get big and slow over time. In this case you'll have to adopt
a strategy, such as a secondary repository for milestones, and wiping out
the incremental repository. 

> I can't think of any really, really, solid reasons why NOT 

As opposed to doing what? 

-- 
Only the future is certain; the past is always changing.