Search icon CANCEL
Arrow left icon
Explore Products
Best Sellers
New Releases
Books
Videos
Audiobooks
Learning Hub
Conferences
Free Learning
Arrow right icon
Arrow up icon
GO TO TOP
WordPress Plugin Development Cookbook

You're reading from   WordPress Plugin Development Cookbook Create powerful plugins to extend the world's most popular CMS

Arrow left icon
Product type Paperback
Published in Jul 2017
Publisher
ISBN-13 9781788291187
Length 386 pages
Edition 2nd Edition
Languages
Concepts
Arrow right icon
Author (1):
Arrow left icon
Yannick Lefebvre Yannick Lefebvre
Author Profile Icon Yannick Lefebvre
Yannick Lefebvre
Arrow right icon
View More author details
Toc

Table of Contents (13) Chapters Close

Preface 1. Preparing a Local Development Environment FREE CHAPTER 2. Plugin Framework Basics 3. User Settings and Administration Pages 4. The Power of Custom Post Types 5. Customizing Post and Page Editors 6. Accepting User Content Submissions 7. Customizing User Data 8. Creating Custom MySQL Database Tables 9. Leveraging JavaScript, jQuery, and AJAX Scripts 10. Adding New Widgets to the WordPress Library 11. Enabling Plugin Internationalization 12. Distributing Your Plugin on wordpress.org

Checking out files from a Subversion repository

After performing an initial import of the files to a Subversion repository, the files need to be checked out to really start working in a version control environment. This recipe explains how to check out files from your local repository and what the resulting file structure changes will be.

Getting ready

You should have already installed a Subversion client, created a local repository, and imported files before following this recipe. These steps will be slightly different based on the Subversion client that you have selected and the operating system you are using.

How to do it...

  1. Navigate to the WordPress plugin directory of your local installation in the file explorer if you are not already there.
  2. Right-click in the white space of the directory window and select the SVN Checkout... menu item.
  3. Enter the file location of your local Subversion repository in the URL of repository field (for example, file:///c:/WPSVN), if it is not already specified.
  4. Set Checkout directory to the plugin folder of your local WordPress installation (for example, C:\WPDev\wp-content\plugins).
By default, the TortoiseSVN client adds the word WPSVN at the end of the path used when performing checkouts. Be sure to remove that last part of the path so that all files that are checked out go to the correct location.
  1. Click Yes on the dialog asking if files should be checked in a folder that is not empty. At this time, TortoiseSVN will retrieve all the files that were added to the repository and copy them locally.
  2. Once the operation is complete, look back at the file listing in the plugins directory to see that it has changed from its previous state:

How it works...

Performing a checkout operation takes copies of all files from the repository and places them in the target directory. It also creates a .svn directory at the top level of the file hierarchy to store files that will support the version control functionality.

By default, most operating systems do not show folders that have a period at the beginning of their name, since this usually identifies hidden files and directories. To display hidden folders on the Windows 10 platform, carry out the following steps:

  1. Open Windows Explorer.
  2. Click on the View tab and check the option labeled Hidden Items.

The .svn directory contains information on the address of the repository that is associated with the files in the current folder. It also contains an original version of each file that was checked out. These original files are used for Subversion to determine when changes have been made to each file relative to their state when they were checked out or updated. While it might seem a bit redundant to have an original copy of all the files in the .svn folders when our repository is locally hosted, this functionality allows Subversion to identify file changes when working on a remote repository, such as the official WordPress plugin server, even when your computer is not connected to the internet.

There's more...

As you work with Subversion and TortoiseSVN, files that you create, modify, and delete will go through a number of different states. The following section explains what each of them represents.

Subversion file statuses

The green check mark indicator shown over each file icon, after performing this recipe, shows us that our files and directories have not been modified since they were last checked out or updated. These indicators will change over time as we start modifying existing files and creating new ones. The following is a list of the most common statuses that files will have as you work on a project, along with their associated TortoiseSVN icons:

  • Normal (green check mark): The file or directory is in a normal state and has not changed since it was last checked out or updated.
  • Modified (red exclamation mark): The file or directory has been modified since it was last checked out or updated.
  • Non-versioned (blue question mark): The file or directory is not under version control.
  • Added (blue plus sign): The file or directory is new and has been marked to be committed to the repository in the next commit operation.
  • Deleted (red x icon): The directory has been deleted and will be removed from the repository in the next commit operation.
  • Ignored (grey do not pass symbol): This file or directory will never be sent to the repository and Subversion should stop checking for changes. This state is useful for keeping private files, such as personal documentation or to-do lists, in the same directory as the plugin but without uploading them to the repository and tracking their history over time.
  • Conflicted (yellow exclamation mark): This icon appears in situations of conflict, typically when more than one person works on the same repository and multiple users have made changes to the same file. While the Subversion client will normally try to merge these changes to create a single file, a conflicted state indicates that the system was not able to merge these changes automatically. Conflicted files need to be manually merged or the user needs to indicate if the file has priority over the version that is currently stored in the repository.

See also

  • The Committing changes to a Subversion repository recipe
You have been reading a chapter from
WordPress Plugin Development Cookbook - Second Edition
Published in: Jul 2017
Publisher:
ISBN-13: 9781788291187
Register for a free Packt account to unlock a world of extra content!
A free Packt account unlocks extra newsletters, articles, discounted offers, and much more. Start advancing your knowledge today.
Unlock this book and the full library FREE for 7 days
Get unlimited access to 7000+ expert-authored eBooks and videos courses covering every tech area you can think of
Renews at $19.99/month. Cancel anytime