DOCSLIB.ORG

CVS QUICK REFERENCE CARD Overview CVS Is a Version Control System Aimed at Keeping an His- Tory and Managing Multiple People

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
CVS QUICK REFERENCE CARD Overview CVS Is a Version Control System Aimed at Keeping an His- Tory and Managing Multiple People CVS QUICK REFERENCE CARD CVS command summary Checkout This list summarizes all possible cmd available. Only cvs co [-ANPRcflnps][-rrev -Ddate][-ddir][-jrev1 j Overview cmd ticked with . are detailed here. [-jrev2 ]] [-kopt] module... CVS is a version control system aimed at keeping an his- . add :::::::::::::::::::::::: add new files or directories Obtain a new sandbox by getting files from module into tory and managing multiple people working at the same admin ::::::::::::: control/administrate the repository the directory CVS creates. cvs co in an already checked time on a same source hierarchy. CVS keeps a single . checkout :::::: get a new sandbox from the repository out module is identical to cvs upd -d. copy of the master sources, called the repository. Each . commit:::::::::::::apply changes, additions, deletions -A::::::::::::::::reset any sticky ( ) tags, flags, dates ◦ person works on one's own copy of the repository, called . diff ::: show differences between sandbox & repository -jv ::::::::::::::::: merge changes from the revision v the sandbox. CVS allows one to control the changes export :::::::::::: prepare copies for off-site shipment -jv1 -jv2 ::::::::::::::: merge changes from v1 & v2 between its sandbox and the global repository. history :::::::::: show report on commands executed -N :::::::::::::::::::: avoid shortening modules paths . import :::::::::::: incorporate a set of off-site updates -c:::::::::only list all module files to standard output Synopsis init::::::::::::::::::::::::initialize a new repository -ddir :::::: use dir for new directory instead of module cvs [cvsopt] cmd [cmdopt] files... log ::::::::::::::::::::::: show stored log information -s ::::::::: display status information for each module cvsopt :::: options controlling the overall CVS program rdiff ::::::::: prepare a collection of diffs as patch file cmd:::::particular action to perform on the repository release :::::: cancel a checkout, abandoning changes Commit cmdopt:::::::options controlling the specific command . remove ::::::::::::::: remove files from the source tree cvs ci [-nRlf][-m'msg' -Ffile][-rrev] files... files ::::::: files to act on, or specific arguments to cmd rtag :::::::::::::: specify a symbolic tag for a revision Incorporate changes madej locally in the sandbox back If you do not specify any files, CVS will normally recurse . status :::::::::::::::::::: show current status of files into the repository. into subdirectories and apply the command to each CVS . tag:::::::::::::specify a symbolic tag from a sandbox -R :::::::::::::: force recursion when scanning for files files encountered. Warning: the same option can mean . update :::::::::::: get the changes from the repository -l ::::::::::::::::: disable recursion in sub-directories different things depending on whether it is in the cvsopt ::::::force commit even if no change has been made or cvscmd group. -f -Ffile :::::::::::::::: use content of file as log message Overall CVS options -mmsg ::::::::::::::::::::: specify msg as log message This list describes all possible cvsopt available. -rrev :::::::::::::::::: commit to specific revision rev -b bindir ::::::::::: use bindir as location of RCS files same as the RCSBIN environment variable Common command options Update cvs upd [-APdflRp][-rtag -D date][-jrev][-Iign] -d cvsdir :::::::::: use cvsdir as location of repository This list describes all possible cmdopt available, com- j same as the CVSROOT environment variable mon for all cmd, except history. Not all commands [-kopt][-Wspec] files... -e editor ::::::::::: use editor to enter log information support all options, only when it makes sense. The Update the sandbox with external changes made to the same as the CVSEDITOR or EDITOR variable symbol specifies a sticky option (CVS remembers the◦ repository. -A::::::::::::::::reset any sticky ( ) tags, flags, dates -f:::::::::::::::do not read the /.cvsrc startup file option on subsequent commands). ◦ -H ::::::: display a summary of all commands available -Ddate ::::: the most recent revision no later than date -jrev ::::::::::::: merge changes from the revision rev ◦ -H cmd::::::::::display usage information about cmd 1 month ago, 6/29/97 08:20:00 PST, -d :::::: create any new directories from the repository -l ::::::::::::::::: do not log the command in history yesterday, last Friday, 18:30 GMT... -If ::::::::::::::::::: ignore file whose names match f -q :::::::::: be quiet, suppress informational messages -f :::::::: use file even if it does not match tag or date -I!:::::::::::::::::::::::avoid ignoring any file at all -Q ::::::: be really quiet, output only serious problems -kb :::: set the file as binary (do not expand keywords) -C :::: overwrite locally modified files with clean copies -n :::::::::::::: do not change any files, only simulate ◦ -kv::::::::::::::::::::::::retain keyword information The cvs upd prints a status flag for each file: -r :::::::::::::::::::: make new working file read-only ◦ -l ::::::::::::::::: disable recursion in sub-directories U :::::::::::::: brought up to date with the repository same as if CVSREAD variable is set -n ::::::::::: do not run program associated with cmd A ::::::::::::::::: added locally but not yet commited -t :: trace program execution, useful with -n to explore -P ::: remove empty directories after checkout/update R ::::::::::::::: removed locally but not yet commited -v:::::::::::display version and copyright information -p ::: pipe files from the repository to standard output M ::::::: modified locally or merged with the repository -w::::::::::make new working file read-write (default) -r tag:::::::::::::use the revision tag instead of head C:::::::conflicting merge that needs manual resolution -x:::::encrypt communication between client & server ◦ use HEAD for the latest version available a backup copy is made under .#file.version -z n ::: use n as compression level for transferring files or BASE for the file you last checked out ? :: ignored local file which does not exist in repository Remove History Keywords cvs remove [-flR] files... cvs hist [-Tcoealw][-mmodule][opts] files... Embedded strings $keyword:...$ in text files are up- Remove files or directories from repository. Show a report on CVS commands that you or others dated with the current keyword value from CVS when- -f::::::::::::::::::::delete the file before removing it have executed on a particular file or directory in the ever you obtain a new revision. source repository. Warning: uses options in ways con- $Author$:::login name of the user who last checked in Add flicting with common meaning. $Date$ :::::::::: UTC date & time of the last check in cvs add [-kkflag][-m'msg'] files... -T :::::::::::::::::::::::::::::::::: report on all tags $Header$:::::RCS file, rev., date, author, state, locker :::::::::::::::::: same as without path Add new files or directories to repository. -c ::::::::::::::::::::::::::::: report on each commit $Id$ $Header$ $Name$ :::::::::::: tag name used to check out the file -kkflag :::::::::::::::::::::::::::::: use kflag for RCS -o ::::::::::::::::::::: report on checked-out modules $Locker$ ::: login name of the user who locked the file -m'msg':::::::::::::::::::use msg as the creation log -e ::::::::::::::::::::::::::::::: report on everything -a :::::::::::::::::::::::::::: report data for all users $Log$ ::::: log message preceded by a header (append) -l :::::::::::::::::::: report on last modification only $RCSfile$::::::::::::::::::::RCS file without a path Differences :::::::::::::::::::current revision number -w :::::::::::::::: report on the current directory only $Revision$ cvs diff [-lNR][-rr1 [-rr2 ] -Dd2 [-Dd1 ]] files... $Source$ :::::::::::::::::::::: RCS file full pathname j -mmod ::::::::::::::::::::::::: report on module mod Show differences between sandbox and repository. $State$ ::::::::::::::::: state assigned to the revision -Dd1 :::::::::::::::::: diff working file against date d1 -xtype ::::: extract record type, a list of several letters: -Dd1 -Dd2 ::::::::::::::: diff date d1 against date d2 O checked-out A first added Administrative files -rr1 ::::::::::::::: diff working file against revision r1 W deleted during an updated T rtagged Here is a list of administrative files that CVS keeps in copied from repository modified -rr1 -rr2::::::::::diff revision r1 against revision r2 U M your working directory under CVS/. Do not delete them. G merged with success F released -N :::::::::::::::::::::::: include added/removed files Entries :::::::::::::::: list and status of working files merged with conflict removed C R Entries.Static :::: do not add more files on cvs upd -bstr :::::::::::: up to module/file/path matching str Log Root ::::::::: pathname used if CVSROOT is not defined -Ddate ::::::::::::::::::::::::::::::: report since date cvs log [-lRhtNb][-rr1 [;r2 ]] [-dd1 [d2 ]] [-sstates] Repository::::::pathname to the repository directory -prep :::::::::::::::::::::::: report for repository rep [-wlogins] files... Tag::::::::::::::::::::sticky date or tag per directory -uuser :::::::::::::::::::::::::::: report for user user Show log information stored for some files. Checkin.prog::::::::::::::program to run on cvs ci Update.prog::::::::::::::program to run on cvs upd -R :::::::::::::::::::::::: print name of RCS file only Status -h:::::::::::::::::::::::::::::::::::print header only cvs status [-lRqQ][-v] files... Environment variables -t:::::::::::::::::::print header and description only Display a brief report on the current status of files: lat- Here is a list of environment variables that CVS uses. :::::::::::::::::::::::::::::::::::::do
Load more

Recommended publications
  • Auswirkungen Der Benutzung Von Zentralen Und Dezentralen Versionsverwaltungssystemen in Open Source Projekten
    Auswirkungen der Benutzung von zentralen und dezentralen Versionsverwaltungssystemen In Open Source Projekten Masterarbeit an der Freien Universität Berlin für den Abschluss zum Master of Computer Science Jana von dem Berge 16. April 2009 Fachbereich Mathematik und Informatik Arbeitsgruppe Software Engineering Betreuer: Christopher Oezbek II Selbstständigkeitserklärung: Hiermit erkläre ich, dass ich diese Arbeit vollkommen selbständig verfasst und keine anderen als die angegebenen Quellen und Hilfsmittel benutzt sowie Zitate kenntlich gemacht habe. Berlin, 16. April 2009 Jana von dem Berge III IV Inhalt 1 Einleitung............................................................................................................. 1 1.1 Open Source Projekte .................................................................................. 1 1.2 Aufgabenstellung.......................................................................................... 1 1.3 Versionsverwaltungssysteme....................................................................... 3 1.3.1 Einführung............................................................................................. 3 1.3.2 Zentrale Versionsverwaltungssysteme.................................................. 5 1.3.3 Dezentrale Versionsverwaltungssysteme ............................................. 8 2 Forschungsmethode.......................................................................................... 10 2.1 Grounded Theory ......................................................................................
    [Show full text]
  • 0000000000000000000000000
    Why use version control? Setting up CVS Saves all previous versions of all files so that Create the repository: you can undo (buggy) edits. % mkdir ~/cvsroot % [set permissions for ~/cvsroot] % setenv CVSROOT ~/cvsroot Logs changes to files so you can trace how % cvs init your sources have evolved over time. Set the CVSROOT environment variable in Mediates conflicting changes made by your .cshrc file. several different users---helps keep consistency. Repository Creating a Project Project 1 Project 2 Project 3 Create a project from existing files: % cd base64 % cvs import -m “base64” base64 carlk start Checkout the new project and delete the old files. % cvs checkout base64 Working copies Development Process with CVS Dealing with Conflicts If another user has committed changes to Get working copy Get any changes cvs checkout cvs update lines you have edited, CVS will report a conflict. Your version Edit files decode (infile, stdout); <<<<<<< decode64.c if( fclose (infile) ) return 0; ======= cvs commit if( fclose (infile) ) printf(" couldn't close file."); >>>>>>> 1.5 no Repository version Conflicts? Manually edit to remove the conflict. yes cvs update Edits on different lines are automatically Most of the merged. Resolve time you stay conflicts in shaded loop. 1 Frequently Used Commands Keywords Get the latest revisions of files with: Useful to put dynamic information in source file. % cvs update When you get a new revision, keywords are replaced with information about the file. Write changes back to repository with: % cvs commit -m“log msg” Keyword Replaced with $Author$ Username who checked in this revision. If you omit –m the editor given in the EDITOR $Date$ Date the this revision was checked in.
    [Show full text]
  • Technical Report
    Eric-Hg Technical Report S-PM 140524 Mercurial Version Control of Eric Projects Technical Report – 1 – Eric-Hg Technical Report Copyright Page S-PM 140400 No commercial uses, No modifications allowed; Jurisdiction International, Format Text This work is licensed under the Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License. To view a copy of this license, visit http://creativecommons.org/licenses/by-nc-nd/3.0/ or send a letter to Creative Commons, 444 Castro Street, Suite 900, Mountain View, California, 94041, USA. Current edition PDF file, Eric_Deliver site URL: http://www.box.net/shared/k64yenrpey under the “Creative Commons License” Disclaimer The information in this document is subject to change without notice. The author and publisher have made their best efforts about the contents of this book, nevertheless the author and the publisher make no representation or warranties of any kind with regard to the completeness or accuracy of the contents herein and accept no liability of any kind including but not limited to performance, merchantability, fitness for any particular purpose, or any loss or damages of any kind caused or alleged to be caused directly or indirectly from this book. Brand Names Brand names such as Linux, Windows, Python are assumed to be universally known, and are here used in full respect of their respective owners. Planned edition On paper, under traditional copyright Published by [not yet—just appointed] Town & Country Reprographics, Inc. 230 N Main St Concord, NH 03301 (U.S.A.) All rights reserved No part of this book may be reproduced, if not for personal use, in any form or by any means, such as: graphic, electronic, or mechanical, including photocopying, recording, videotaping, or information storage and retrieval systems, without written permission of the publisher.
    [Show full text]
  • Tortoisecvs User's Guide Version 1.8.0
    TortoiseCVS User's Guide Version 1.8.0 Ben Campbell Martin Crawford Hartmut Honisch Francis Irving Torsten Martinsen Ian Dees Copyright © 2001 - 2004 TortoiseCVS Table of Contents 1. Getting Started What is CVS? What is TortoiseCVS? Where to Begin? 2. Basic Usage of TortoiseCVS Sandboxes Checking out a Module Windows Explorer and TortoiseCVS Total Commander and TortoiseCVS Updating your Sandbox Committing your Changes to the Repository Resolving Conflicts Adding Files and Directories to the Repository 3. Advanced Usage of TortoiseCVS Creating a New Repository or Module Watch, Edit and Unedit Tagging and Labeling Reverting to an Older Version of a File Branching And Merging Creating a Branch Selecting a Branch to Work On Merging from a Branch Going Back to the Head Branch Binary and Unicode Detection File Revision History History Dialog Revision Graph Dialog Web Log Making a Patch File 4. Customizing TortoiseCVS Overlay Icons Selecting a Different Set of Overlay Icons Changing how the Overlay Icons Work 5. Command Reference for TortoiseCVS Installing TortoiseCVS Obtaining a Working Copy: CVS Checkout... Getting Other People's Changes: CVS Update CVS Update Special... Making Your Changes Available to Others: CVS Commit... Adding New Files: CVS Add and CVS Add Contents... Discarding Obsolete Files: CVS Remove Finding Out What Has Changed: CVS Diff... Making a Snapshot: CVS Tag... Lines of Development: CVS Branch... CVS Merge... CVS Make New Module Watching And Locking Finding Out Who to Blame: CVS Annotate Showing More Information: CVS Explorer Columns Keyboard Shortcuts How Web Log Autodetects the Server URL 6. Dialog Reference for TortoiseCVS Add Dialog Checkout Dialog Update Special Dialog Commit Dialog Branch Dialog Make New Module Dialog Progress Dialog Tag Dialog Preferences Dialog Merge Dialog History Dialog Revision Graph Dialog About Dialog 7.
    [Show full text]
  • When Developers Build Software, They're Able to Keep Track of All The
    < Day Day Up > Practical Perforce By Laura Wingerd ............................................... Publisher: O'Reilly Pub Date: November 2005 Print ISBN-10: 0-596-10185-6 Print ISBN-13: 978-0-59-610185-5 Pages: 358 Table of Contents | Index When developers build software, they're able to keep track of all the different versions and all the components they use with software configuration management (SCM) systems. One of the more popular SCM products is Perforce. Authored by Perforce's own VP of product technology, Practical Perforce is the ideal complement to the existing product manual, focusing less on the 'how" and more on the "why" and "when." The book is not only a helpful introduction to Perforce, it's an enlightening resource for those already familiar with this versatile SCM product. Whether you're a programmer, product manager, or build engineer, you stand to benefit from the many insider tips and ideas presented in this convenient guide. Practical Perforce is divided into two main parts. Part I offers a whirlwind technical tour, complete with careful descriptions of basic and advanced Perforce commands designed to give you a baseline knowledge. Part II describes the big picture-using Perforce in a collaborative software development. It outlines recommended best practices and quickly shows how to implement them with the Perforce operations introduced in Part I. Throughout the book, you'll learn how to maximize Perforce so it completes tasks like these in the most efficient manner possible: Keep track of changes as you conduct concurrent parallel work on files Log activity Generate reports on who did what when Compare, merge and branch files Store files and file configurations Restore lost bug fixes Recognizing the pitfalls and practices of an SCM system like Perforce is absolutely essential to producing good software.
    [Show full text]
  • Version Management with CVS
    Version Management with CVS for cvs 1.11.22 Per Cederqvist et al Copyright c 1993, 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005 Free Software Foundation, Inc. Portions Copyright c 1999, 2000, 2001, 2002, 2003, 2004, 2005 Derek R. Price, Copyright c 2002, 2003, 2004, 2005 Ximbiot http://ximbiot.com, Copyright c 1992, 1993, 1999 Signum Support AB, and Copyright c others. Permission is granted to make and distribute verbatim copies of this manual provided the copyright notice and this permission notice are preserved on all copies. Permission is granted to copy and distribute modified versions of this manual under the conditions for verbatim copying, provided also that the entire resulting derived work is distributed under the terms of a permission notice identical to this one. Permission is granted to copy and distribute translations of this manual into another lan- guage, under the above conditions for modified versions, except that this permission notice may be stated in a translation approved by the Free Software Foundation. i Short Contents 1 Overview ..................................... 1 2 The Repository................................. 7 3 Starting a project with CVS ....................... 29 4 Revisions .................................... 33 5 Branching and merging .......................... 41 6 Recursive behavior ............................. 51 7 Adding, removing, and renaming files and directories ...... 53 8 History browsing ............................... 59 9 Handling binary files ............................ 61 10 Multiple developers ............................. 63 11 Revision management ........................... 73 12 Keyword substitution............................ 75 13 Tracking third-party sources ....................... 79 14 How your build system interacts with CVS ............. 83 15 Special Files .................................. 85 A Guide to CVS commands ......................... 87 B Quick reference to CVS commands .................
    [Show full text]
  • Version Control
    Version Control So#ware Quality Quality Audit and Cer2ficaon Master in Computer Engineering Roberto García (rgarcia@diei.udl.cat) Introduc2on • Change-control procedures. Avoid uncontrolled changes, destabilize and degrade quality: • In requirements, disrupt design and coding • In design, code disagrees with requirements • In the code, inconsistencies and uncertain2es about what has been reviewed and tested – Version Control Systems (VCS): • Standalone (CVS, Subversion, Git,…) • Word processors (MicrosoL Office, OpenOffice,…) • Content Management Systems (Drupal, Joomla,…) • Wikis (MediaWiki, TWiki, Trac (wiki+svn)…) Features • Backup and Restore. Files are saved as they are edited, and you can jump to any moment in 2me • Synchronizaon. Lets people share files and stay up-to-date with the latest version • Short-term undo. Throw away your changes and go back to the “last known good” version in the database • Long-term undo. Jump back to the old version, and see what change was made that day • Track Changes. As files are updated, you can leave messages explaining why the change happened (stored in the VCS) • Track Ownership. A VCS tags every change with the name of the person who made it • Sandboxing. You can make temporary changes in an isolated area and test before “checking in” changes • Branching and merging. A larger sandbox. You can branch a copy of your code into a separate area and modify it in isolaon (tracking changes separately). Later, you can merge your work back into the common area Basic Setup • Repository (repo): The database storing the files • Server: The computer storing the repo • Client: The computer connec2ng to the repo • Working Set/Working Copy: Your local directory of files, where you make changes • Trunk/Main: The primary locaon for code in the repo, the main development line Basic Ac2ons • Add: Put a file into the repo and begin tracking it • Revision: What version a file is on (v1, v2, v3,...) • Head: The latest revision in the repo • Check out: Download a file from the repo • Check in: Upload a file to the repository (if it has changed).
    [Show full text]
  • Download the Wincvs-1.3 User Guide
    Users Guide Don Harper November 1, 2001 Copyright 2001 Don Harper Permission is granted to make and distribute verbatim copies of this manual provided the copyright notice and this permission notice are preserved on all copies. Permission is granted to copy and distribute modified version of this manual under the conditions for verbatim copying, provided also that the entire resulting derived work is distributed under the terms of a permission notice identical to this one. 2 Section 1 – Introduction ................................................................................................................... 5 Section 2 – Download and Installation ............................................................................................ 6 Section 3 – CVS Repository Configuration...................................................................................... 7 3.1 Local – Direct Access to Local Repository .........................................................................................7 3.2 Pserver, Rhosts, and Ssh – Remote Repository on Non-Windows Server.......................................7 3.3 Ntserver – Remote Repository on Windows Server ..........................................................................7 Section 4 – Beginners Guide to WinCvs .......................................................................................... 8 4.1 Running WinCvs for the First Time ...................................................................................................8 4.2 Setting WinCvs Preferences...............................................................................................................10
    [Show full text]
  • Buildbot This Is the Buildbot Manual
    BuildBot This is the BuildBot manual. Copyright (C) 2005, 2006, 2009, 2010 Brian Warner Copying and distribution of this file, with or without modification, are permitted in any medium without royalty provided the copyright notice and this notice are preserved. i Table of Contents 1 Introduction..................................... 1 1.1 History and Philosophy ........................................ 1 1.2 System Architecture............................................ 2 1.2.1 BuildSlave Connections.................................... 3 1.2.2 Buildmaster Architecture .................................. 4 1.2.3 Status Delivery Architecture............................... 6 1.3 Control Flow ................................................... 6 2 Installation ...................................... 8 2.1 Requirements .................................................. 8 2.2 Installing the code ............................................. 8 2.3 Creating a buildmaster ......................................... 9 2.4 Upgrading an Existing Buildmaster............................ 10 2.5 Creating a buildslave.......................................... 10 2.5.1 Buildslave Options ....................................... 12 2.6 Launching the daemons ....................................... 13 2.7 Logfiles ................................................... .... 14 2.8 Shutdown ................................................... 14 2.9 Maintenance .................................................. 15 2.10 Troubleshooting.............................................
    [Show full text]
  • Lpi Linux Certification in a Nutshell
    LPI LINUX CERTIFICATION IN A NUTSHELL LPI LINUX CERTIFICATION IN A NUTSHELL Third Edition Adam Haeder, Stephen Addison Schneiter, Bruno Gomes Pessanha, and James Stanger Beijing • Cambridge • Farnham • Köln • Sebastopol • Taipei • Tokyo LPI Linux Certification in a Nutshell, Third Edition by Adam Haeder, Stephen Addison Schneiter, Bruno Gomes Pessanha, and James Stanger Copyright © 2010 Adam Haeder, Stephen Addison Schneiter, Bruno Gomes Pessanha, and James Stanger. All rights reserved. Printed in the United States of America. Published by O’Reilly Media, Inc., 1005 Gravenstein Highway North, Sebastopol, CA 95472. O’Reilly books may be purchased for educational, business, or sales promotional use. Online editions are also available for most titles (http://my.safaribooksonline.com). For more infor- mation, contact our corporate/institutional sales department: 800-998-9938 or corporate@oreilly.com. Editor: Andy Oram Indexer: Jay Marchand Production Editor: Adam Zaremba Cover Designer: Karen Montgomery Copyeditor: Genevieve d’Entremont Interior Designer: David Futato Proofreader: Jennifer Knight Illustrator: Robert Romano Printing History: May 2001: First Edition. July 2006: Second Edition. June 2010: Third Edition. Nutshell Handbook, the Nutshell Handbook logo, and the O’Reilly logo are registered trade- marks of O’Reilly Media, Inc. LPI Linux Certification in a Nutshell, the image of a bull, and related trade dress are trademarks of O’Reilly Media, Inc. Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this book, and O’Reilly Media, Inc. was aware of a trademark claim, the designations have been printed in caps or initial caps. While every precaution has been taken in the preparation of this book, the publisher and authors assume no responsibility for errors or omissions, or for damages resulting from the use of the information contained herein.
    [Show full text]
  • Best Practices for Web Developers V1.01
    Best Practices for Web Developers v1.01 by Kate Rhodes ( masukomi at masukomi dot org ) May 18, 2007 1 This work is licensed under a Creative Commons Attribution-Noncommercial-No Derivative Works 3.0 License. http://creativecommons.org/licenses/by-nc-nd/3.0/ Contents 1 Let’s get a few things straight 3 2 Tools, tools, tools 4 3 Getting version control right 5 3.1 Youhaveaproductionbranch. 6 3.2 Emergencybugfixesstartwithproduction. 6 3.3 Exploring new functionality starts with a new branch. 6 3.4 You have a main development branch. 7 3.5 You are not using a version control system that makes branching and merging a pain. 7 3.6 You are not using CVS anymore. 7 3.7 You have started using a version control system that’s actually good.......... 8 4 Testing 10 4.1 Basictestingconcepts ............................... 11 4.1.1 Unittesting..................................... 11 4.1.2 Functional / Acceptance testing . 11 4.1.3 Integration testing . 12 4.1.4 Systemtesting ................................... 12 4.2 HeuristicDrivenDevelopment. 13 4.2.1 Triage . 13 4.2.2 When things break. 14 4.2.3 Your development environment . 15 2 CONTENTS 3 5 Optimization & load tests 16 5.1 Triage based on predicted usage. 16 5.2 Create test data early in realistic amounts. 17 5.3 Mirror your production environment. 17 5.4 Learn to use profiling software. 18 5.5 Setsometargets. ..................................... 18 5.6 Usediversionarytactics. .... ........ ....... ........ .. 18 5.7 Loadtestingrulesofthumb... ........ ....... ........ ... 19 6 Application deployment 20 6.1 Rulesofthumb ...................................... 20 6.1.1 Your live webapp is never in a state that can’t be rolled back to in the future.
    [Show full text]
  • CVS-RCS- HOW-TO Document for Linux (Source Code Control System)
    CVS−RCS− HOW−TO document for Linux (Source Code Control System) CVS−RCS− HOW−TO document for Linux (Source Code Control System) Table of Contents CVS−RCS− HOW−TO document for Linux (Source Code Control System)...............................................1 Al Dev (Alavoor Vasudevan) alavoor@yahoo.com................................................................................1 1.Introduction...........................................................................................................................................1 2.Which one is for me? CVS or RCS......................................................................................................1 3.Setting up CVS ....................................................................................................................................1 4.Shell Scripts .........................................................................................................................................1 5.CVS Documentation ............................................................................................................................2 6.Emacs Editor ........................................................................................................................................2 7.Problem Reporting System ..................................................................................................................2 8.Other Formats of this Document...........................................................................................................2
    [Show full text]