[Soc-2005-dev] Creating a CVS repository

[Chris Want]

Hey all,

First, thanks for the advice Jiri -- I think that 10
repositories would take up too much disk space, so I
don't think we can go that way. If you would like to
learn more about merging by tracking third-party sources
I can run you through a tuhopuu merge sometime.

After chatting with Daniel, I've decided to do the
one tree, 10 branch solution, and make merges optional.
I 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

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:

         timmeh
         qwe
         phaethon
         pdg
         n_t
         nescirian
         mfreixas
         jiri
         eman
         blendix

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

$ cvs -z3 -d:ext:jiri at 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) I 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 at 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

CRLF == bad!

* 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=modload&name=documentation&file=index

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

Chris