cse306 operating systems projects

35
1 CSE306 Operating Systems Projects CVS/SSH tutorial

Upload: nasim-gonzales

Post on 30-Dec-2015

46 views

Category:

Documents


1 download

DESCRIPTION

CSE306 Operating Systems Projects. CVS/SSH tutorial. What is CVS?. Concurrent Versions System Version Control System Multi-developer environment. CVS. Developer 4. Developer 1. Repository. Developer 3. Developer 2. Ideal development with CVS. Developer A. update. development. - PowerPoint PPT Presentation

TRANSCRIPT

Page 1: CSE306 Operating Systems Projects

1

CSE306 Operating Systems Projects

CVS/SSH tutorial

Page 2: CSE306 Operating Systems Projects

2

What is CVS?

• Concurrent Versions System

• Version Control System

• Multi-developer environment

Page 3: CSE306 Operating Systems Projects

3

CVS

RepositoryDeveloper1

Developer2

Developer3

Developer4

Page 4: CSE306 Operating Systems Projects

4

checkoutupdatecheckindevelopment

Ideal development with CVS

repository

Developer A

Developer B

Page 5: CSE306 Operating Systems Projects

5

Definitions-Repository

• The Repository is a directory tree containing the CVS administrative files and all the RCS files that constitute "imported" or "committed" work.

• Kept in a shared area, separate from the working areas of all developers.

Page 6: CSE306 Operating Systems Projects

6

Definitions-RCS

• An RCS file is a text file containing the source text and the revision history for all committed revisions of a source file.

• Stored separately from the working files, in a directory hierarchy, called the Repository.

• RCS is the "Revision Control System" that CVS uses to manage individual files. RCS file names normally end in ",v".

Page 7: CSE306 Operating Systems Projects

7

Definitions-Working file

• A working file is a disk file containing a checked-out copy of a source file that earlier had been placed under CVS. If the working file has been edited, the changes since the last committed revision are invisible to other users of CVS.

• A working directory is the place where you work and the place from which you "commit" files.

Page 8: CSE306 Operating Systems Projects

8

Definitions-Checkout

• “Checking out" is the act of using the "checkout" command to copy a particular revision from a set of RCS files into your working area.

• You normally execute "checkout" only once per working directory (or tree of working directories), maintaining them thereafter with the "update" command.

Page 9: CSE306 Operating Systems Projects

9

Definitions-Revision

• A "revision" is a version of a file that was "committed" ("checked in", in RCS terms) some time in the past.

• Each version of a file has a unique revision number.

• Every file in a CVS repository can contain many versions, which are given revision numbers in form x.y[.x.y[...]].

• ! 1.1 !----! 1.2 !----! 1.3 !----! 1.4 !----! 1.5 !

Page 10: CSE306 Operating Systems Projects

10

Definition-Tag-symbolic revision

• A release of a system will have many different revision numbers

• To let you find all the files in a release, use tags.

• Read Manual if you are interested

Page 11: CSE306 Operating Systems Projects

11

Definition-Branch

• Version number can contain more than two numbers to mark branches.

Reasons to branch:• fix bugs in product while working on next

version• work on subproject that will take a week to

finish

Page 12: CSE306 Operating Systems Projects

12

Working on branches

1.1 1.2 1.3

release_1

cvs tag release_1

cvs up -r rel_1_fix

1.4

release_2

cvs tag release_2

1.2.2.1 1.2.2.2

patch

rel_

1_fixcvs tag -b rel_1_fix

Page 13: CSE306 Operating Systems Projects

13

checkin

X

Real development with CVS

repository

Developer A

Developer B

updateconflict resolutioncheckin

conflict

Page 14: CSE306 Operating Systems Projects

14

CVS and the Development Cycle

1. Check out source files in working directory.

2. Edit source files.3. Unit test your code.4. Update working files to merge in

changes from other developers (if necessary).

Page 15: CSE306 Operating Systems Projects

15

CVS and the Development Cycle

5. Test again if the sources were merged on step 4.

6. Commit changes.7. Repeat from step 2 until you have

a new release.8. Tag the release.9. Submit the module name and

release tag for integration build.

Page 16: CSE306 Operating Systems Projects

16

Useful CVS commands

cvs [cvs-options] command [cmd-options] [files]

cvs checkout Check out source for editing.

cvs commit check files into the repository (check in

cvs add Add new file/directory to repository.

cvs remove Remove an entry from the repository.

cvs update Bring working files into sync with repository.

Page 17: CSE306 Operating Systems Projects

17

Useful CVS Commands(con.)

cvs diff Compare working files to version in repository or versions inside the repository.

cvs log Show revision history for files.

cvs status Show status of checked out files.

cvs tag Label the sources.

Page 18: CSE306 Operating Systems Projects

18

Notes

• When to commit:

Commit to mark a working state that you might want to return to later.

For more information on CVS, please see

• www.cvshome.org

Page 19: CSE306 Operating Systems Projects

19

Starting the Projectwith CVS/SSH

Page 20: CSE306 Operating Systems Projects

20

Enable us to check your project

• To enable us to check the log, you must do this:

cd ~ chmod 711 . mkdir ~/.ssh chmod 700 ~/.ssh

cat ~kifer/id_cse306.pub >> ~/.ssh/authorized_keys2

Page 21: CSE306 Operating Systems Projects

21

Start working with CVS

• Create empty repository

cvs -d ~/CVSROOT init

• protect yourself from copycats!

chmod -R 770 ~/CVSROOT

Page 22: CSE306 Operating Systems Projects

22

Working with partner

• if you are working with a partner and are assigned to the same user group, say c306-00 then also type the following two commands:

chgrp -R c306-00 ~/CVSROOT make sure new directories are created with the right permissions:

chmod -R g+s ~/CVSROOT

Page 23: CSE306 Operating Systems Projects

23

Create directory structure for your repository

• your OSP project dir mkdir ~/your-project-dir/OSP

• your project dir for Proj 1 mkdir ~/your-project-dir/OSP/memory

• your project dir for Proj 2 mkdir ~/your-project-dir/OSP/threads

• your project dir for Proj 3 mkdir ~/your-project-dir/OSP/devices

Page 24: CSE306 Operating Systems Projects

24

Import directory structure

• cd ~/your-project-dir/OSP • Import directory structure of your OSP project

into your CVS repository cvs -d ~/CVSROOT import -m "Created

OSP directory structure" OSP osp start

• In the above, `osp' and `start' are called "vendor" and "release" tags and can be anything. CVS requires them for import, but you can forget about them from now on.

Page 25: CSE306 Operating Systems Projects

25

Remove it

• Set the appropriate permissions for the OSP module in the cvs repository. Read/write for you and partner -- nobody else

chmod 770 ~/CVSROOT/OSP • Remove the OSP dir structure you just created (not

the CVSROOT repository)

cd ~/your-project-dir • BE CAREFUL HERE!!!!!!

rm -r OSP

Page 26: CSE306 Operating Systems Projects

26

Check Out

• Checkout OSP from the repository (this lets OSP create the necessary structures)

cvs -d ~/CVSROOT checkout OSP

• Protect yourself!

chmod 700 OSP

Page 27: CSE306 Operating Systems Projects

27

Partner

• Your partner should also check out the same thing, but, of course, use ~your_account_id instead of just ~. Let's suppose you are 'john': Your partner does:

cd ~/your-partner's-project-dir

cvs -d ~john/CVSROOT checkout OSP

chmod 700 OSP

Page 28: CSE306 Operating Systems Projects

The following is a bit outdated, but OK if you are not planning to use Eclipse

28

Page 29: CSE306 Operating Systems Projects

29

Add new files

• Adding files (such as memory.c) to your repository using the command 'cvs add‘

• Use `cvs add filename' to tell CVS that you want to version control the file.

• Command: cvs add [-k kflag] [-m message] files

The `-m' option specifies a description for the file. This description appears in the history log

Page 30: CSE306 Operating Systems Projects

30

Commit

• Use `cvs commit filename' to actually check in the file into the repository. Other developers cannot see the file until you perform this step.

Page 31: CSE306 Operating Systems Projects

31

Where should I work?

• Your repository should be on ug.cs.sunysb.edu

• Remote access to UG lab by SSH (no GUI)

• Working at home with Linux/FreeBSD using Emacs/Xemacs or Eclipse

• Working at home with MS Windows

using TortoiseCVS or Eclipse

Page 32: CSE306 Operating Systems Projects

32

UG Server

• Request a UG account at

www.ug.cs.sunysb.edu

• Read www.ug.cs.sunysb.edu to begin working

• Remote access to UG server by SSH only!

Page 33: CSE306 Operating Systems Projects

33

Working at home with Linux/FreeBSD

• Set the environment variable CVS_RSH to ssh • You can checkout a copy directly to your home computer as

follows (assuming that you are 'mary' in the UG lab): cvs –d :ext:[email protected]:your_homedir/CVSROOT checkout OSP

(this is all in 1 line!!)• Note: your_homedir must be the full path name to your home

directory at ug.cs.sunysb.edu • Then you can access the rest of the commands using the

Emacs/Xemacs graphical interfaces.• You can also access the repository using Eclipse:

– http://wiki.eclipse.org/CVS_Howto

• There are other graphical interfaces for Linux as well

Page 34: CSE306 Operating Systems Projects

34

Emacs and Xemacs Interfaces

• XEmacs– Nice interface to CVS, called pcl-cvs. Most of the CVS

commands are available through the Tools/PCL_CVS menu of XEmacs.

– After you invoke M-x cvs-update, you get a CVS buffer, where you can invoke even more commands through the top-level menu called CVS

• Emacs has a similar interface, called pcvs

Page 35: CSE306 Operating Systems Projects

35

TortoiseCVS and Eclipse

• Download a copy from

www.tortoisecvs.org

• TortoiseCVS+SSH:– http://www.tortoisevs.org/faq.shtml#ssh

• Eclipse with CVS and SSH:– http://wiki.eclipse.org/CVS_Howto