Dev:Ref/GoogleSummerOfCode/2005/CVS guide

提供: wiki
< Dev:Ref‎ | GoogleSummerOfCode‎ | 2005
2018年6月29日 (金) 02:45時点におけるYamyam (トーク | 投稿記録)による版 (1版 をインポートしました)
(差分) ← 古い版 | 最新版 (差分) | 新しい版 → (差分)
移動先: 案内検索

Work with CVS

We've decided to do the one tree, 10 branch solution, and make merges optional. We have created the tree and the branches and they are accessed as follows:

1) make sure that you have set up you're environment to use ssh with cvs, i.e.,

export CVS_RSH=ssh

if you use csh or tcsh

setenv CVS_RSH ssh

Optionally, you can use the p.b.o website to upload some ssh public keys so that you don't have to type a password everytime you access the repository. If you are new to ssh, and keys, etc, just ask for a more detailed elaboration.

2) The cvs module name is soc-blender and there are ten branches that are named after the student coders.

I'm going to pretend I'm jiri. Here is how I would check out my branch:

$ cvs -z3 -d:ext:jiri@cvs.blender.org:/cvsroot/soc-2005 co -r jiri soc-blender

(unless Jiri has uploaded his ssh public key, he will need to enter his p.b.o password)

This will create a directory called soc-blender with jiri's branch inside it.

We can confirm that this is the right branch using 'cvs status' on a file:

$ cd soc-blender
$ cvs status README
===================================================================
File: README				Status: Up-to-date

Working revision:	 1.1.1.1
Repository revision: 1.1.1.1 /cvsroot/soc-2005/soc-blender/README,v
Sticky Tag:			 jiri (branch: 1.1.1.1.6)
Sticky Date:			(none)
Sticky Options:		(none)

Henceforth, jiri can do cvs update, commit, etc as usual, and it will only effect his branch, provided that he does not reset the sticky tag. Before committing, it may be prudent to do a cvs status on a file to make sure you are indeed effecting the right branch.

3) Occasionally (say weekly, but it can even be done on request if something is needed). We can merge the HEAD branch with the latest bf-blender sources (HEAD branch is basically the main branch, i.e. the branch you get if you don't specify a branch name). This will be effortless: since none of you are working on the main branch I will get no conflicts. Also, this will not effect your branches so you will get no conflicts. Life will be good.

4) Well, how do the changes in HEAD get propagated to a branch? This is through merging HEAD onto the branch. I recommend checking out a separate working directory to do merges, as not to damage any un-committed work. So, it would go something like this:

# checkout new working directory
$ cvs -z3 -d:ext:jiri@cvs.blender.org:/cvsroot/soc-2005 co -r jiri soc-blender

# merge head onto our jiri branch
$ cd soc-blender
$ cvs up -jHEAD

# fix conflicts if any then commit:
# cvs commit

By the way, for you cvs newbies, I'd recommend setting up a .cvsrc file in your home directory that looks something like this:

cvs -z3 -q
diff -up
update -Pd
checkout -P
rdiff -u

These are nice options for compression, etc.

One last thing. This is a nice way to merge: when you do the 'cvs up -jHEAD' it *does not* modify the repository in any way, just your local copy. So if you get freaked out because the conflicts are getting ugly, you can just abort the merge and ask for help or something.

One more last thing: I am not a cvs guru, I just basically read the docs and learn things well enough to get the task done. If you want to find out more, and in fact check that I'm not totally out to lunch, I would recommend reading the relevant section of the cvs manual:

https://www.cvshome.org/docs/manual/cvs-1.12.12/cvs_5.html#SEC56

(btw, the merging I will do on the HEAD branch is the stuff in Section 13 on third party sources.)

5) Well, that's about it. Things are ready to check out, but I think I have to talk to an admin about unix file permissions before anybody can commit (although all of the students and admins are supposed to have commit rights according to p.b.o).

6) Just a few do's & don't's (well, mostly don't's):

  • Don't commit files that are in msdos text format - check your editor settings! If in doubt, run'file' on a file to report it's status, e.g.:
$ file README
README: ASCII English text

$ unix2dos README
$ file README
README: ASCII English text, with CRLF line terminators

Try to keep the style and indentation of your work similar to what is currently in the blender sources, e.g., use tabs for indentation rather than spaces. There are some docs about conventions that are often followed here:

http://www.blender.org/modules.php?op</tt>modload&nameocumentation&fileindex

OK, that's it for now, feel free to send any questions to the list.