1 Subject: Information about using CVS
2 X-Mailer: mh-e 6.1; nmh 1.0.4+dev; Emacs 21.2
3 Date: Thu, 16 Sep 2004 15:08:54 -0700
4 From: Lewis Girod <girod@lecs.cs.ucla.edu>
5
6 you should be able to find info on cvs via "man cvs" and other sources on
7 the web.
8
9 To add a file,
10
11 cvs add <filename> ...
12
13 When adding new source code to the emstar repository, it's a good idea
14 to add it to somewhere in the 'devel' directory, unless you are certain
15 about where it belongs in the main tree and that it's ready for release.
16 we are trying to keep the main tree very organized, which is difficult
17 with CVS because once defined, you cannot change directory structures.
18 thus we are only very carefully adding new directories to the main tree.
19 if you are in doubt, add it to devel.. we can always move it later into
20 the main tree
21
22 To commit changes you MUST first
23
24 * update the repository, resolving any conflicts
25 * if anything was patched, make sure it builds
26
27 NOTE: if you are making changes to EmTOS, or moving files around,
28 it's a good idea to rm -rf obj.* to clear out any existing state
29 and get a fresh build. EmTOS code does not automatically rebuild
30 in the current make system.
31
32 * check to see what you're about to commit by doing a cvs diff
33 * then commit, and write a useful log message.
34 * for total safety, do a clean checkout and rebuild from scratch
35 to verify the build AFTER checkin
36
37 First, update to the latest revision:
38
39 cvs update -d | less
40 control-L
41
42 This will show all files you have modified with 'M', any files that
43 you have added with 'A', and any you have removed with 'R'. Any files
44 that were patched from later versions in the repository will be marked
45 'P'. Any files marked 'C' are conflicts and must be manually resolved
46 or deleted and re-updated.
47
48 Pay special attention to '?' files -- these are files that exist in
49 your checkout that are not known to CVS. If files that are needed for
50 the build are marked '?', it will break for other users. Typically
51 these files are random junk you may have left lying around, output
52 files, and TinyOS build directories. If you're sure that the files
53 are harmless, you can leave them, but if you're not sure, move them to
54 another location outside of the repo. Or do a followup checkout after
55 you commit (described below).
56
57 If any patches or conflicts occurred during the update, resolve them
58 and make sure that your repository still builds before going on to
59 commit. NOTE: If you are using EmTOS, be aware that it won't
60 automatically rebuild EmTOS images. So, if your changes might have
61 changed a library inside TOS, please rm -rf obj.* and make sure your
62 repo builds clean.
63
64 After it builds, do a cvs diff to find out what changes you will be
65 committing:
66
67 cvs diff | less
68 control-L
69
70 This will show you all the changes you are about to commit. once you
71 are sure you want to commit them, then do the cvs commit. If there are
72 a lot of changes, it's goot to take some notes about that changed so that
73 you can create a good log message.
74
75 Finally, after updating, building, and diffing, you can commit:
76
77 cvs commit <filename> ...
78
79 You can commit on individual files, or directories. If you commit on a
80 directory it will process directories recursively. When you commit, it
81 will ask you to write a log message that describes the nature of the
82 changes you are committing.
83
84 For extreme safety, when you have made lots of changes or done unusual
85 things like moved files around or added lots of files, it's sometimes
86 a good idea to do a followup checkout of a clean repo and rebuild from
87 scratch. Be sure the enable BUILD_EMTOS. This will ensure that other
88 users who do a clean checkout will get all the files they need to build
89 (e.g. that your repo doesn't have any files that make it work only for
90 you).
91
92
93 =====================================================================
94 =====================================================================
95 =====================================================================
96
97 A note on CVS orderliness
98 -------------------------
99
100 One of the drawbacks to CVS is that moving/renaming and deleting
101 directories is not generally possible. For this reason we try to
102 commit experimental stuff into devel/ (a big sandbox for new projects)
103 and the migrate it to the main tree after it is more mature.
104
105 CVS Administrators can move or rename these files while keeping
106 complete revision history. The procedure is to copy the files to
107 their new locations on the server, and then cvs remove the originals
108 via normal CVS.
109
110 It is also possible to rename or remove directories from the CVS
111 server so that empty directories are not left sitting around.
112 However, this should only be done in extreme cases, and when no tags
113 will break. Thus if a directory is checked in accidentally, it's OK
114 to immediately delete it. The other times when this is OK are left to
115 the judgement of administrators -- but generally this should be
116 avoided if it will break important tags, or if it doesn't involve
117 whole directories. In general, it should not be done.
118
This page was automatically generated by the
LXR engine.
Visit the LXR main site for more
information.