Re: Handling project documentation using CVS
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. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Handling project documentation using CVS
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Friday, October 12, 2001 4:28 PM To: [EMAIL PROTECTED] Subject: Handling project documentation using CVS Hello all, I was wondering if some of you nice people could give me some feedback on an issue I've been wrestling with. Besides the actual source code to a project, I also need the ability to version design documentation ( and maybe other stuff, but this is my immediate concern ). By design documentation, I mean things like Visio documents, with UML diagrams, etc. As opposed to TeX or ?roff documents, I guess. These are likely to be proprietary formats best represented as binary files, which means that they aren't well suited for CVS. On one level, I have a feeling that CVS isn't the best way to handle versioning these documents. It kinda feels like using the wrong tool for the job. But, on the other hand, I can't think of any really, really, solid reasons why NOT to do it. I think it would be more accurate to say that these files aren't the ones CVS handles best. I think that a systems that does file locking better than CVS would do a little better, but nobody's shown me a system that works much better than CVS. You have to remember that automatic merging isn't going to work, and in general the only way to merge is to take one of the versions and manually recreate the changes. This means that you want at least advisory locking, so that anybody starting work on such a file will know that there's likely to be a conflict that will require redoing changes. It also means that, while you can have branches, merging doc changes between branches will not in general work, and so it would probably be necessary to redo the work when applying changes to more than one branch. CVS won't store the files efficiently, so frequent small changes are likely to take lots of disk space in the repository. This may or may not be important. If you have another system that does what you need it to do and has good file locking facilities, then it may or may not be worth your while to use it to control documentation in a separate project. It is likely to do somewhat better than CVS, but introduces two version control systems and potential confusion. So, if some of you have some experience, or thoughts, on this issue, please share them with me. It works. It isn't ideal, but it works. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Handling project documentation using CVS
--- Forwarded mail from [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Friday, October 12, 2001 4:28 PM To: [EMAIL PROTECTED] Subject: Handling project documentation using CVS Hello all, I was wondering if some of you nice people could give me some feedback on an issue I've been wrestling with. Besides the actual source code to a project, I also need the ability to version design documentation ( and maybe other stuff, but this is my immediate concern ). By design documentation, I mean things like Visio documents, with UML diagrams, etc. As opposed to TeX or ?roff documents, I guess. These are likely to be proprietary formats best represented as binary files, which means that they aren't well suited for CVS. Well, text formatters aren't usually the best design tools. On one level, I have a feeling that CVS isn't the best way to handle versioning these documents. It kinda feels like using the wrong tool for the job. But, on the other hand, I can't think of any really, really, solid reasons why NOT to do it. I think it would be more accurate to say that these files aren't the ones CVS handles best. I think that a systems that does file locking better than CVS would do a little better, but nobody's shown me a system that works much better than CVS. You have to remember that automatic merging isn't going to work, and in general the only way to merge is to take one of the versions and manually recreate the changes. This means that you want at least advisory locking, so that anybody starting work on such a file will know that there's likely to be a conflict that will require redoing changes. It also means that, while you can have branches, merging doc changes between branches will not in general work, and so it would probably be necessary to redo the work when applying changes to more than one branch. Automatic merges as built into CVS won't work, certainly. If you have suitable merge tools for your design documents, then you might consider hacking CVS to integrate them. There's demo code in the form of a patch posted to this list showing what's necessary. It's too early to tell if that capability will be supported in the mainstream, however. --- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Handling project documentation using CVS
Hello all, I was wondering if some of you nice people could give me some feedback on an issue I've been wrestling with. Besides the actual source code to a project, I also need the ability to version design documentation ( and maybe other stuff, but this is my immediate concern ). By design documentation, I mean things like Visio documents, with UML diagrams, etc. I am debating whether or not it makes sense to put this stuff into my CVS repository. And if I do, I'm wondering what the best approach is. Just create a subdir called docs in my source tree, and stick that stuff in? Or maybe make a parallel project, just for docs. Example: Project named WCISP, project named WCISPDocs. On one level, I have a feeling that CVS isn't the best way to handle versioning these documents. It kinda feels like using the wrong tool for the job. But, on the other hand, I can't think of any really, really, solid reasons why NOT to do it. So, if some of you have some experience, or thoughts, on this issue, please share them with me. Thanks, Phillip Rhodes Application Designer Voice Data Solutions 919-571-4300 x225 [EMAIL PROTECTED] Those who are willing to sacrifice essential liberties for a little order, will lose both and deserve neither. - Benjamin Franklin This country, with its institutions, belongs to the people who inhabit it. Whenever they shall grow weary of the existing government, they can exercise their constitutional right of amending it, or exercise their revolutionary right to overthrow it. - Abraham Lincoln No citizen shall be denied the right to bear arms, if as a last resort, to protect themselves from tyranny in Government. - Thomas Jefferson ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
