Recent Changes - Search:

VCS-Home



Note: Due to heavy spamming, the edit password is: VCS-Home.

AutoCheckin

Automatically checking in Files and Directories

It can be convenient to have a cron job which will automatically checkin any changes to a directory tree in your VCS-System. But, except for in the most trivial cases (file content changes only) with most VCS systems you will run into some fundamental problems if you simply try to do a checkin without doing anything else. These problems have to do with adding and deleting files and directories. A mechanism is usually needed to tell the VCS system about these sorts of changes. The typical VCS system expects this to be a manual process.

Auto Everything

But our application of VCS system may warrant a non manual process since we are potentially using the VCS system as a backup mechanism more than a traditional version control system. One solution involves defining top level directory trees that a script can then prepare to be checked in by simply telling the VCS system about every change that has occurred to the underlying directory trees. This is simple and has worked fairly well for me. There are however some downsides to this solution, primarily the fact that it is not very flexible. It is a top-down, all-or-nothing solution. The only flexibility is in choosing various top level entry points. The other main downside is that the policy of "what directories to checkin automatically?" lives outside of the directories themselves making it hard to rearrange your working copies and/or working copies on multiple machines.

Local Policy-Based Checkins

Instead of the external all or nothing solution mentioned in the previous section, a better solution allows for a local policy based checkin mechanism. The svnauto script implements this mechanism by allowing users to add a policy file to a directory which defines exactly how files and subdirectories of the current directory should be treated as far as checkins are concerned.

Here are the possible entries in the svn_auto policy file (.svn-auto) and their meanings:

 ci      # check in any changes
 add     # add new elements
 rm      # delete missing elements

Policies apply recursively to entire subtrees unless overridden within a subtree by another policy file. Actions in ancestor policy files are canceled out merely by the existence of a policy file (even an empty one) in a subdirectory. The default policy (if a policy file exists within a subtree) is to take no action unless the action is called out in the policy file. Including an empty policy file is a safe way to avoid auto-committing any changes to a directory. A directory's policy is always determined by the first policy file found while traversing the directory path backwards from the current directory. This mechanism limits the inheritance model to one which should not be too hard to track. Despite an inheritance mechanism, all policies for a particular directory are defined in one and only one file.

Security

One security measure of this policy mechanism includes only trusting committed .svn-auto policy files. This prevents malicious users from simply dropping a file into one of your directories and causing you to commit changes. The trade-off is that this can be abused as a minor DOS attack since uncommitted policy files will be ignored.

Another security precaution is to only inherit policies from ancestral directories that are both ancestral in the current filesystem and in the repository! This prevents malicious users from dropping a policy file in an ancestor's directory and making it apply to the current directory.

Despite these two security precautions, a note of caution to consider: this policy mechanism makes the assumption that malicious users will not be committing files to your repository from elsewhere. Particularly, when taking updates to a working copy (which should probably never be automated due to conflict possibilities) a working copy could be acquiring policies that were set in the repository by way of updates/addition of .svn-auto files.

Avoiding Conflicts With a Single Source

Since this checkin mechanism is automatic, it is important to keep updates from a single source for any directory trees affected by this mechanism! Multiple update sources to a directory tree risks creating conflicts. These conflicts typically require manual intervention and do not lend themselves to automatic checkins very well. If this happens, conflicts will need to be resolved or the automatic checkin procedure will fail.

svnauto

 Usage: svnauto [[+-]add|rm|ci] [-n] dir ...

  Automatically sync svn directories (v1.0)

  Actions:

  add  # add any new elements
  rm   # rm  any missing elements
  ci   # checkin elements

  The overridding qualifiers are + and -.

  +    perform this action no matter what the local
       .svnauto says
  -    do not perform this action no matter what the local
       .svnauto says

  If no overriding qualifier is given, the action is taken
  as the parent action and will be used until overridden by
  a .svnauto file in a subdirectory.

  A local .svnauto can be placed in a subdirectory and if it
  is committed, the actions listed in this file will override
  any inherited actions.

  Options:

  -n  do not actually execute anything (this may not produce
      the same results since certain actions depend on other
      actions committing.

  -u  display this usage message

Implementation Note: This script currently commits each changed file and directory individually.

Future Enhancement Ideas

Edit - History - Print - Recent Changes - Search
Page last modified on March 11, 2008, at 11:47 AM