]>
Commit | Line | Data |
---|---|---|
1 | gitcvs-migration(7) | |
2 | =================== | |
3 | ||
4 | NAME | |
5 | ---- | |
6 | gitcvs-migration - Git for CVS users | |
7 | ||
8 | SYNOPSIS | |
9 | -------- | |
10 | [verse] | |
11 | 'git cvsimport' * | |
12 | ||
13 | DESCRIPTION | |
14 | ----------- | |
15 | ||
16 | Git differs from CVS in that every working tree contains a repository with | |
17 | a full copy of the project history, and no repository is inherently more | |
18 | important than any other. However, you can emulate the CVS model by | |
19 | designating a single shared repository which people can synchronize with; | |
20 | this document explains how to do that. | |
21 | ||
22 | Some basic familiarity with Git is required. Having gone through | |
23 | linkgit:gittutorial[7] and | |
24 | linkgit:gitglossary[7] should be sufficient. | |
25 | ||
26 | Developing against a shared repository | |
27 | -------------------------------------- | |
28 | ||
29 | Suppose a shared repository is set up in /pub/repo.git on the host | |
30 | foo.com. Then as an individual committer you can clone the shared | |
31 | repository over ssh with: | |
32 | ||
33 | ------------------------------------------------ | |
34 | $ git clone foo.com:/pub/repo.git/ my-project | |
35 | $ cd my-project | |
36 | ------------------------------------------------ | |
37 | ||
38 | and hack away. The equivalent of 'cvs update' is | |
39 | ||
40 | ------------------------------------------------ | |
41 | $ git pull origin | |
42 | ------------------------------------------------ | |
43 | ||
44 | which merges in any work that others might have done since the clone | |
45 | operation. If there are uncommitted changes in your working tree, commit | |
46 | them first before running git pull. | |
47 | ||
48 | [NOTE] | |
49 | ================================ | |
50 | The 'pull' command knows where to get updates from because of certain | |
51 | configuration variables that were set by the first 'git clone' | |
52 | command; see `git config -l` and the linkgit:git-config[1] man | |
53 | page for details. | |
54 | ================================ | |
55 | ||
56 | You can update the shared repository with your changes by first committing | |
57 | your changes, and then using the 'git push' command: | |
58 | ||
59 | ------------------------------------------------ | |
60 | $ git push origin master | |
61 | ------------------------------------------------ | |
62 | ||
63 | to "push" those commits to the shared repository. If someone else has | |
64 | updated the repository more recently, 'git push', like 'cvs commit', will | |
65 | complain, in which case you must pull any changes before attempting the | |
66 | push again. | |
67 | ||
68 | In the 'git push' command above we specify the name of the remote branch | |
69 | to update (`master`). If we leave that out, 'git push' tries to update | |
70 | any branches in the remote repository that have the same name as a branch | |
71 | in the local repository. So the last 'push' can be done with either of: | |
72 | ||
73 | ------------ | |
74 | $ git push origin | |
75 | $ git push foo.com:/pub/project.git/ | |
76 | ------------ | |
77 | ||
78 | as long as the shared repository does not have any branches | |
79 | other than `master`. | |
80 | ||
81 | Setting Up a Shared Repository | |
82 | ------------------------------ | |
83 | ||
84 | We assume you have already created a Git repository for your project, | |
85 | possibly created from scratch or from a tarball (see | |
86 | linkgit:gittutorial[7]), or imported from an already existing CVS | |
87 | repository (see the next section). | |
88 | ||
89 | Assume your existing repo is at /home/alice/myproject. Create a new "bare" | |
90 | repository (a repository without a working tree) and fetch your project into | |
91 | it: | |
92 | ||
93 | ------------------------------------------------ | |
94 | $ mkdir /pub/my-repo.git | |
95 | $ cd /pub/my-repo.git | |
96 | $ git --bare init --shared | |
97 | $ git --bare fetch /home/alice/myproject master:master | |
98 | ------------------------------------------------ | |
99 | ||
100 | Next, give every team member read/write access to this repository. One | |
101 | easy way to do this is to give all the team members ssh access to the | |
102 | machine where the repository is hosted. If you don't want to give them a | |
103 | full shell on the machine, there is a restricted shell which only allows | |
104 | users to do Git pushes and pulls; see linkgit:git-shell[1]. | |
105 | ||
106 | Put all the committers in the same group, and make the repository | |
107 | writable by that group: | |
108 | ||
109 | ------------------------------------------------ | |
110 | $ chgrp -R $group /pub/my-repo.git | |
111 | ------------------------------------------------ | |
112 | ||
113 | Make sure committers have a umask of at most 027, so that the directories | |
114 | they create are writable and searchable by other group members. | |
115 | ||
116 | Importing a CVS archive | |
117 | ----------------------- | |
118 | ||
119 | NOTE: These instructions use the `git-cvsimport` script which ships with | |
120 | git, but other importers may provide better results. See the note in | |
121 | linkgit:git-cvsimport[1] for other options. | |
122 | ||
123 | First, install version 2.1 or higher of cvsps from | |
124 | https://github.com/andreyvit/cvsps[https://github.com/andreyvit/cvsps] and make | |
125 | sure it is in your path. Then cd to a checked out CVS working directory | |
126 | of the project you are interested in and run linkgit:git-cvsimport[1]: | |
127 | ||
128 | ------------------------------------------- | |
129 | $ git cvsimport -C <destination> <module> | |
130 | ------------------------------------------- | |
131 | ||
132 | This puts a Git archive of the named CVS module in the directory | |
133 | <destination>, which will be created if necessary. | |
134 | ||
135 | The import checks out from CVS every revision of every file. Reportedly | |
136 | cvsimport can average some twenty revisions per second, so for a | |
137 | medium-sized project this should not take more than a couple of minutes. | |
138 | Larger projects or remote repositories may take longer. | |
139 | ||
140 | The main trunk is stored in the Git branch named `origin`, and additional | |
141 | CVS branches are stored in Git branches with the same names. The most | |
142 | recent version of the main trunk is also left checked out on the `master` | |
143 | branch, so you can start adding your own changes right away. | |
144 | ||
145 | The import is incremental, so if you call it again next month it will | |
146 | fetch any CVS updates that have been made in the meantime. For this to | |
147 | work, you must not modify the imported branches; instead, create new | |
148 | branches for your own changes, and merge in the imported branches as | |
149 | necessary. | |
150 | ||
151 | If you want a shared repository, you will need to make a bare clone | |
152 | of the imported directory, as described above. Then treat the imported | |
153 | directory as another development clone for purposes of merging | |
154 | incremental imports. | |
155 | ||
156 | Advanced Shared Repository Management | |
157 | ------------------------------------- | |
158 | ||
159 | Git allows you to specify scripts called "hooks" to be run at certain | |
160 | points. You can use these, for example, to send all commits to the shared | |
161 | repository to a mailing list. See linkgit:githooks[5]. | |
162 | ||
163 | You can enforce finer grained permissions using update hooks. See | |
164 | link:howto/update-hook-example.html[Controlling access to branches using | |
165 | update hooks]. | |
166 | ||
167 | Providing CVS Access to a Git Repository | |
168 | ---------------------------------------- | |
169 | ||
170 | It is also possible to provide true CVS access to a Git repository, so | |
171 | that developers can still use CVS; see linkgit:git-cvsserver[1] for | |
172 | details. | |
173 | ||
174 | Alternative Development Models | |
175 | ------------------------------ | |
176 | ||
177 | CVS users are accustomed to giving a group of developers commit access to | |
178 | a common repository. As we've seen, this is also possible with Git. | |
179 | However, the distributed nature of Git allows other development models, | |
180 | and you may want to first consider whether one of them might be a better | |
181 | fit for your project. | |
182 | ||
183 | For example, you can choose a single person to maintain the project's | |
184 | primary public repository. Other developers then clone this repository | |
185 | and each work in their own clone. When they have a series of changes that | |
186 | they're happy with, they ask the maintainer to pull from the branch | |
187 | containing the changes. The maintainer reviews their changes and pulls | |
188 | them into the primary repository, which other developers pull from as | |
189 | necessary to stay coordinated. The Linux kernel and other projects use | |
190 | variants of this model. | |
191 | ||
192 | With a small group, developers may just pull changes from each other's | |
193 | repositories without the need for a central maintainer. | |
194 | ||
195 | SEE ALSO | |
196 | -------- | |
197 | linkgit:gittutorial[7], | |
198 | linkgit:gittutorial-2[7], | |
199 | linkgit:gitcore-tutorial[7], | |
200 | linkgit:gitglossary[7], | |
201 | linkgit:giteveryday[7], | |
202 | link:user-manual.html[The Git User's Manual] | |
203 | ||
204 | GIT | |
205 | --- | |
206 | Part of the linkgit:git[1] suite |