1 / 19

C oncurrent V ersions S ystem

C oncurrent V ersions S ystem. Overview of CVS architecture. Repository structure. Basic development tasks in WinCvs. Branching and merging. Other CVS interfaces. CVS Features. Concurrent access by multiple developers Multiple development lines in a single repository

nuri
Télécharger la présentation

C oncurrent V ersions S ystem

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Concurrent Versions System • Overview of CVS architecture. • Repository structure. • Basic development tasks in WinCvs. • Branching and merging. • Other CVS interfaces

  2. CVS Features • Concurrent access by multiple developers • Multiple development lines in a single repository • Grouping sources into modules • Symbolic source tagging • Diffs between versions • Configurable logging support • Binary files support • Repository event triggers

  3. The CVS Repository ewacvs:/data1/cvsroot CVSROOT shr project1 project2 project3 devkits ar cgi doc install reports util web unix nt cgipr esapps forms • Resides on a server • No working files inside the repository

  4. CVS Usage ModelCheckout, Commit, Update • Checkout Makes private copy in working directory Can check out anywhere Check out multiple copies, multiple versions • Update Brings working copy up to date with repository • Commit Commit changes to the repository when finished Working copies must be up to date with repository

  5. Working Copy V1.7 Working Copy V1.1 Working Copy V1.2 Working Copy V1.7 Working Copy V1.2.2.1 Concurrent checkout Checkout does not lock the files in repository Master Repository foo.c checkout latest checkout branch rel_1_fix checkout V1.1 checkout V1.2 checkout latest Karen Patrick Brigid Michael Chris checkin checkin checkin X X V1.8 or 1.9 V1.2.2.2 checkin prohibited V1.8 or 1.9

  6. 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). 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.

  7. Common CVS commands cvs [cvs-options] command [cmd-options] [files] cvs checkout Check out source for editing. cvs add Add new file/directory to repository. cvs remove Remove an entry from the repository. cvs status Show status of checked out files. cvs log Show revision history for files. cvs diff Compare working files to version in repository or versions inside the repository. cvs update Bring working files into sync with repository. cvs commit check files into the repository cvs tag Label the sources.

  8. When to commit • Commit to mark a working state that you might want to return to later. • Commit related files in a single operation. Use a common log message for all the files. • Commit to backup your sources. • Commit from an office desktop to be able to access the files from home much faster than through filesystem sharing.

  9. patch cvs tag -b rel_1_fix rel_1_fix 1.2.2.1 1.2.2.2 1.1 1.2 1.3 1.4 release_1 release_2 cvs up -r rel_1_fix cvs tag release_1 cvs tag release_2 Working on branches

  10. Branch if you need ... • to create sustaining (patch) releases • to have multiple development lines from a single repository • to do experimental development to merge later or forget about it • to keep temporary state of development without affecting builds

  11. Ideal development with CVS Developer A update development checkout checkin repository Developer B

  12. checkin conflict resolution checkin update X conflict Real development with CVS Developer A repository Developer B

  13. Reserved Checkouts and CVS Exclusive file locking prevents parallel development and is not recommended for plain text files • advisory locks: implemented via cvs edit and cvs watch. Get notification when someone edits or checks in the file. • all-o-nothing advisory locks: cvs edit does not succeed if files are already edited by someone else. Implemented using a patch to cvs edit • exclusive locks (RCS style): implemented via cvs admin. You cannot commit unless you’ve locked the file. One lock per file per branch.

  14. email alert CVS server edit/watch edit Advisory locks Developer A Developer B Editors: Developer A Editors: Developer A Developer B

  15. Client-server architecture • separate server (UNIX or NT) • no shared filesystems • a server process per connection ewacvs

  16. WinCVS on your desktop • Configuration • Main screen • Checking out the sources • Viewing source history • Diff • Commit • Update • Tag

  17. Directory listing Diff between 2 versions of the file Other CVS clients CVSweb

  18. Directory listing Diff between 2 versions of the file Other CVS clients jCVS

  19. CVS online • Official CVS site: http://www.cyclic.com • CVS Bubbles: http://www.loria.fr/~molli/cvs-index.html • CVS for Web development: http://durak.org:81/cvswebsites • WinCvs: http://www.wincvs.org • jCVS: http://www.jcvs.org/ • Netscape’s Mozilla under CVS: http://cvs-mirror.mozilla.org/webtools/tindertest/showbuilds.cgi?tree=SeaMonkey • FreeBSD CVS repository: http://www.freebsd.org/support.html#cvs

More Related