Search code examples
windowssvntortoisesvncommand-line-interfacerevert

Revert all files with a specified name


Hi i want to revert all changes to the files with a specific filename in a local repository. In this case AssemblyInfo.vb, i'm using the TortoiseSVN cli.

I have the following directory structure

  • Root
    • Project 1
      • File1.txt
      • My Project
        • AssemblyInfo.vb
    • Project 2
      • File2.txt
      • My Project
        • AssemblyInfo.vb

Now while standing in Root i run the command svn.exe revert --recursive AssemblyInfo.vb and the output i get is:

Skipped 'AssemblyInfo.vb'

I have tried to add double and single * before the filename with no success, does --recursive/-R work or what am i missing?

svn help revert gives the following output:

revert: Restore pristine working copy state (undo local changes).
usage: revert PATH...

  Revert changes in the working copy at or within PATH, and remove
  conflict markers as well, if any.

  This subcommand does not revert already committed changes.
  For information about undoing already committed changes, search
  the output of 'svn help merge' for 'undo'.

Valid options:
  --targets ARG            : pass contents of file ARG as additional args
  -R [--recursive]         : descend recursively, same as --depth=infinity
  --depth ARG              : limit operation by depth ARG ('empty', 'files',
                             'immediates', or 'infinity')
  -q [--quiet]             : print nothing, or only summary information
  --changelist [--cl] ARG  : operate only on members of changelist ARG

Global options:
  --username ARG           : specify a username ARG
  --password ARG           : specify a password ARG (caution: on many operating
                             systems, other users will be able to see this)
  --no-auth-cache          : do not cache authentication tokens
  --non-interactive        : do no interactive prompting (default is to prompt
                             only if standard input is a terminal device)
  --force-interactive      : do interactive prompting even if standard input
                             is not a terminal device
  --trust-server-cert      : deprecated; same as
                             --trust-server-cert-failures=unknown-ca
  --trust-server-cert-failures ARG : with --non-interactive, accept SSL server
                             certificates with failures; ARG is comma-separated
                             list of 'unknown-ca' (Unknown Authority),
                             'cn-mismatch' (Hostname mismatch), 'expired'
                             (Expired certificate), 'not-yet-valid' (Not yet
                             valid certificate) and 'other' (all other not
                             separately classified certificate errors).
  --config-dir ARG         : read user configuration files from directory ARG
  --config-option ARG      : set user configuration option in the format:
                                 FILE:SECTION:OPTION=[VALUE]
                             For example:
                                 servers:global:http-library=serf

If i run svn.exe revert --recursive AssemblyInfo.vb in a directory that directly contains a modified AssemblyInfo.vb it works as intended.


Solution

  • svn revert is designed to help fix mistakes, not cause problems by "helping" users to accidentally or unintentionally remove their local and uncommitted changes.

    If you want to revert all the changes in your SVN working copy or in a directory and all its childs, you could run svn revert . -R. But you must not run this command if your working copy has a mixture of valid uncommitted changes that you don't want to lose and the changes that you want to revert to unmodified state.

    Reverting local changes is an irreversible operation. Therefore, reverting local changes in SVN working copy via svn revert must be done cautiously. Assume that you are working on a task and haven't yet committed some important changes you've been working on a couple of hours. But at the same time you have some changes in a file or directory that you want to revert. Carelessly running svn revert . -R at the root of working copy will revert all the uncommitted changes in the working copy.

    Citing SVNBook | svn revert

    svn revert is inherently dangerous, since its entire purpose is to throw away data—namely, your uncommitted changes. Once you've reverted, Subversion provides no way to get back those uncommitted changes.

    If you provide no targets to svn revert, it will do nothing. To protect you from accidentally losing changes in your working copy, svn revert requires you to explicitly provide at least one target.


    Now while standing in Root i run the command svn.exe revert --recursive AssemblyInfo.vb and the output i get is:

    svn revert does not work this way. By default, it runs with --depth=empty to ensure that it won't revert more than the user intended. But runningsvn revert with -R is the same as running it with --depth=infinity. Generally speaking, in this particular case --recursive is an alias for --depth=infinity and its purpose is to help users revert all the local modifications (e.g. after invalid merge).

    When you run svn revert with --recursive, the tool expects you to specify a path to a directory in your working copy and the operation will revert ALL the changes that are in this directory and its childs. There will be no effect if the command's target is a file.

    What you look for is --targets and a bit of scripting. For example, run the following commands in PowerShell console (I'm sure that it could be done more elegantly in PowerShell than in this example):

    (dir -Path "files.html" -Recurse -File).FullName | Out-File -Encoding ASCII mytargets.txt
    svn revert --targets mytargets.txt
    

    dir is an alias of Get-ChildItem cmdlet in PowerShell. In this case it grabs the list of all files with name files.html and writes the full paths to mytargets.txt file. Then it runs svn revert that reads paths from mytargets.txt and revert local modifications made to the files.

    I advise this approach instead of piping the output to svn revert because you can (and should) review the list of items that svn revert will process. This helps you ensure that you won't revert more that you actually intended.