description: activity of managing the versions of one or more files
44 results
by Jon Loeliger and Matthew McCullough · 14 Aug 2012
Version Control with Git Jon Loeliger Matthew McCullough Published by O’Reilly Media Beijing ⋅ Cambridge ⋅ Farnham ⋅ Köln ⋅ Sebastopol ⋅ Tokyo Preface Audience Although some familiarity with revision control systems will be good background material, a reader who is not familiar with any other system will still be able to learn enough about basic
…
and tracks different versions of software or other content is referred to generically as a version control system (VCS), a source code manager (SCM), a revision control system (RCS), and several other permutations of the words “revision,” “version,” “code,” “content,” “control,” “management,” and “system.” Although the authors and users of each tool
…
, and record all changes in a log. In this book, the term version control system (VCS) is used to refer generically to any form of revision control system. This book covers Git, a particularly powerful, flexible, and low-overhead version control tool that makes collaborative development a pleasure. Git was invented by
…
model instead of a centralized model also ensured that network latency would not hinder daily development. Maintain Integrity and Trust Because Git is a distributed revision control system, it is vital to obtain absolute assurance that data integrity is maintained and is not somehow being altered. How do you know the data
…
(a convention enforced through the Unix file system). When finished, he or she would check the file back into the repository and unlock it. The Revision Control System (RCS) was introduced by Walter F. Tichy in the early 1980s. [“RCS: A System for Version Control,” Software Practice and Experience 15(7) (1985
…
to grasp, so some exposition is worthwhile. Git’s content tracking is manifested in two critical ways that differ fundamentally from almost all other[7] revision control systems. First, Git’s object store is based on the hashed computation of the contents of its objects, not on the file or directory names
…
. A Note on Tracking Renames Let’s talk a bit more about how Git keeps track of file renames. SVN, as an example of traditional revision control, does a lot of work tracking when a file is renamed and moved around because it keeps track only of diffs between files. If you
…
state of index, It’s All About the Index quotes ('), for ref as single word, The Reflog R -r option, for Unix diff, Diffs RCS (Revision Control System), Precedents Reachability, Commit Ranges, Garbage Collection in garbage collection, Garbage Collection in graphs, Commit Ranges read-only address, cloned submodules with, Why Read Only
…
version of file, Retrieve Old Version of a File–Retrieve Old Version of a File rev-list, GitHub in Sum (see git rev-list command) Revision Control System (RCS), Precedents RFC 1738, Referring to Remote Repositories RFC 2396, Referring to Remote Repositories right (>), for git log --left-right display, git log with
by Travis Swicegood · 1 Dec 2008 · 184pp · 12,922 words
cvsimport. Since the cvs2svn command is much more stable to a Git repository, we’ll focus on it. To start with, you need to get revision control system (RCS) files from your CVS repository. Once you have those, you need to convert them to an SVN dump file using the cvs2svn tool
…
see also History, repository; Remote repositories Resources bundles, 167 online, 13, 172–173 repository hosting, 171–172 third-party tools, 168–171 Reverting commits, 93 Revision control system (RCS), 146 Revisions, 18, 82 Prepared exclusively for Trieu Nguyen 178 V ERSION CONTROL SYSTEMS (VCS S ) S Server setup, see Gitosis SHA (secure
by Clif Flynt · 18 May 2003 · 792pp · 48,468 words
may want to go through all the source code to see what has been changed in each file before you commit the changes to your revision control system. Using a UNIX-style shell, you can compare all files in one directory to files with the same name in another directory and place
by Thomas A. Limoncelli, Strata R. Chalup and Christina J. Hogan · 27 Aug 2014 · 757pp · 193,541 words
: With a software-defined datacenter (i.e., virtual machines), you can keep a description of the entire infrastructure as code that can be maintained under revision control. Infrastructure as code is further described in Section 10.6. • Automated Provisioning and Deployment: Every step of the deployment process is automated and/or scripted
…
via software, as can software-defined networks. The more we treat infrastructure as code, the more we can benefit from software development techniques such as revision control and testing. This automation should be treated like any other software product and put through the same service delivery flow as any application. When service
…
by the SDP. This approach is called infrastructure as code. Like application code, the code that describes the infrastructure is stored in the source repository, revision controlled, and tested in a test environment before being approved for deployment in the live production environment. Configuration code includes the automation to do configuration management
…
and less flexible. When infrastructure configuration is encoded in software, the entire infrastructure can be treated as software, with all the benefits of source code: revision control, testing, and so on. Before a release is used in the live environment, it must pass many tests. System tests check the system as a
…
multiplies the more you use the code. Making changes to the running system should involve making changes to code and data files stored in a revision-controlled central repository. Those changes are then picked up by the software delivery platform, tested, and deployed to production. To work in this way modern system
…
main repository when desired, or not at all. A VCS should not be used only for source code; that is, configuration files must also be revision controlled. When automation or use of tools involves configuration file changes, you should automate the steps of checking the config file out of version control, modifying
…
then figures out how to bring the system to that state. Best practices dictate that all code for automation and configuration files be kept under revision control or in a database that tracks changes. As is true for the software development environment, automation tools should not be developed or tested in the
…
to store and access the data. These configurations should be treated like any other software source code: kept under revision control, tested using both unit tests and system tests, and so on. Revision control tracks changes of a file over time, enabling one to see what a file looked like at any point in
by Amy Brown and Greg Wilson · 24 May 2011 · 834pp · 180,700 words
was more efficient than just keeping around copies, and didn't help with publishing these changes to others. It was followed in 1982 by the Revision Control System, RCS, which was a more evolved and free alternative to SCCS (and which is still being maintained by the GNU project). After RCS came
by John Ousterhout · 28 Jan 2018 · 211pp · 58,677 words
comment was moved or deleted, this inconsistency will be self-evident because developers won’t find the comment at the indicated place; they can use revision control history to find out what happened to the comment and then update the reference. In contrast, if the documentation is duplicated and some of the
…
the diffs One good way to make sure documentation stays up to date is to take a few minutes before committing a change to your revision control system to scan over all the changes for that commit; make sure that each change is properly reflected in the documentation. These pre-commit scans
by Scott Chacon and Ben Straub · 12 Nov 2014 · 549pp · 134,988 words
to. To deal with this issue, programmers long ago developed local VCSs that had a simple database that kept all the changes to files under revision control. Figure 1-1. Local version control. One of the more popular VCS tools was a system called RCS, which is still distributed with many computers
by Adam Goucher and Tim Riley · 13 Oct 2009 · 351pp · 123,876 words
§ operate on the purist concept that, since bugs ultimately reside in the source code, defect tracking should live alongside the code and use the same revision control system (e.g., CVS, SVN, Mercurial). This does have significant advantages, especially for small systems where the entire code base can live within one
…
revision control system. When a defect is fixed, both the patched source code and updated defect report are checked into the revision control system, and the correspondence between the defect state and the defect report state are correctly
by Betsy Beyer, Chris Jones, Jennifer Petoff and Niall Richard Murphy · 15 Apr 2016 · 719pp · 181,090 words
an example. If TestDnsMonitoringConfigExists fails, as shown, we can call FixDnsMonitoringCreateConfig, which scrapes configuration from a database, then checks a skeleton configuration file into our revision control system. Then TestDnsMonitoringConfigExists passes on retry, and the TestDnsMonitoringConfigPushed test can be attempted. If the test fails, the FixDnsMonitoringPushConfig step runs. If a fix fails
…
hermetic test that is executed by the testing infrastructure always combines the fake backend and the test frontend at the same build point in the revision control history. That build dependency may be providing a runnable hermetic binary and, ideally, the engineering team maintaining it cuts a release of that fake backend
by Scott Chacon · 17 Aug 2009 · 282pp · 79,176 words
to. To deal with this issue, programmers long ago developed local VCSs that had a simple database that kept all the changes to files under revision control (see Figure 1–1). Figure 1–1. Local version control diagram. One of the more popular VCS tools was a system called rcs, which is
by Steve McConnell · 8 Jun 2004 · 1,758pp · 342,766 words
by Karl Fogel · 13 Oct 2005
by Sean P. Kane and Karl Matthias · 15 Mar 2018 · 350pp · 114,454 words
by Eric S. Raymond · 22 Sep 2003 · 612pp · 187,431 words
by Sean Kane and Karl Matthias · 14 May 2023 · 433pp · 130,334 words
by Fabio Alessandro Locati · 21 Nov 2016
by Lars George · 29 Aug 2011
by David Aronson · 1 Nov 2006
by Adam Freeman · 25 Mar 2014 · 671pp · 228,348 words
by David Sheff and Andy Eddy · 1 Jan 1993 · 500pp · 156,079 words
by Peter Seibel · 22 Jun 2009 · 1,201pp · 233,519 words
by Kim Schulz · 29 Apr 2010 · 236pp · 67,823 words
by Dave Thomas, Chad Fowler and Andy Hunt · 15 Dec 2000 · 936pp · 85,745 words
by Bryan O'Sullivan, John Goerzen, Donald Stewart and Donald Bruce Stewart · 2 Dec 2008 · 1,065pp · 229,099 words
by Jonathan Haskel and Stian Westlake · 7 Nov 2017 · 346pp · 89,180 words
by Vikram Chandra · 7 Nov 2013 · 239pp · 64,812 words
by Matt Behrens · 24 Jan 2015
by Francesco Cesarini · 496pp · 70,263 words
by Heather Adkins, Betsy Beyer, Paul Blankinship, Ana Oprea, Piotr Lewandowski and Adam Stubblefield · 29 Mar 2020 · 1,380pp · 190,710 words
by Ron Jeffries · 14 Aug 2015 · 444pp · 118,393 words
by Robert Peters · 18 May 2014 · 125pp · 28,222 words
by Adam Freeman
by Jeff Forcier
by James Turnbull · 1 Jan 2007
by Jim Waldo · 193pp · 31,998 words
by Andrew Hunt and Dave Thomas · 19 Oct 1999 · 509pp · 92,141 words
by Wes McKinney · 30 Dec 2011 · 752pp · 131,533 words
by Alan Berg · 15 Mar 2012 · 372pp · 67,140 words
by Antonio Cangiano · 15 Mar 2012 · 315pp · 85,791 words
by Robert C. Martin · 13 Oct 2019 · 333pp · 64,581 words
by Zigurd Mednieks, Laird Dornin, G. Blake Meike and Masumi Nakamura · 15 Jul 2011
by Pieter Hintjens · 12 Mar 2013 · 1,025pp · 150,187 words
by Lawrence Lessig · 2 Jan 2009
by Jonathan Taplin · 17 Apr 2017 · 222pp · 70,132 words