FAQ Answerpage
QUESTION:
"How do I use the CVS system to make changes to another user's package? In particular, how do I make needed changes to "common" packages, keep these changes consistent with my own work, and not cause trouble for other users?"
ANSWER:
The following detailed response will be included in the upcoming User Workbook. At that time, the details here will be omitted and replaced with a pointer to the User Workbook.
The following is one technique that involves refining your changes outside of the CVS system before you commit changes in CVS.
The basic idea is to keep things at known revisions (i.e. at a known CVS level) until you are ready to commit a consistent set of changes. This is particularly important if your changes are in several packages.
- Start with a test release based on something recent.
- addpkg the packages you want to modify without using any particular tags or the -h option. This may not give you the most current contents of CVS, but it will give you a consistent starting point.
- Edit, build, test, edit, build, test, edit, build, test, ...
- Once you have something working well, you want to commit it back to CVS. This may involve several packages, some of which are no longer at the revision level you originally checked out. Contact the package coordinator(s) and talk to
them.
- Note that this need not delay development work, only your committing code into CVS, which is in any case a serious step with implications for many other users.
- If they think that the head of CVS is in good shape, do a cvs update -A to update your directories to the head of CVS, fix any conflicts, build, test, and (hopefully) commit.
- The head of CVS may depend on various changes to other packages; one of the reasons you contacted the coordinator was to find out about these dependencies. addpkg (with the required tags) the required packages, then do a cvs update -A to
update your directories to the head of CVS, fix any conflicts, build, test, and (hopefully) commit.
- If they ask you to wait, be patient. It's their call. Commit your stuff when they say its OK (you can continue to develop in another set of directories if you want to).
- At this point, your changes are in CVS. The package coordinators should tag your changes so they can refer to them easily, although they may not be ready for a release. (If they forget, ask them to). You should now base your next development iteration
on these versions, so the whole process can repeat when needed.
Note how this differs from the usual "start with the head" and "commit when ready" cycle. First, you are guaranteed (well, almost) to start with a consistent set of code. This can save you a lot of grief. When you're ready to commit, you'll update as
needed. This can be confusing, as updating packages can result in dependencies on other packages, but by getting in touch with the package coordinator(s), you'll get the most recent info on what else you'll need. Finally, by committing a consistent set of
changes which get tagged, others will be able to figure out what's going on.
For a more detailed description of how to commit changes in the CVS system, see Development Software and CVS.
(Last updated 7/9/98)
[SLAC Homepage] [Search] [FAQ Homepage]
If you have a FAQ (with or WITHOUT an answer), use our prototype submission form.
If you have comments or suggestions, email me at sison@slac.stanford.edu
|
