How to Use an SVN Server: An Introductory Guide

By /

Okay, here’s a comprehensive introductory guide to using an SVN server, aiming for approximately 5000 words.

How to Use an SVN Server: An Introductory Guide

This guide provides a comprehensive introduction to using Subversion (SVN), a popular version control system. We’ll cover everything from basic concepts to practical usage, equipping you with the knowledge to effectively manage your projects using an SVN server. This guide is targeted towards beginners, but even experienced users might find some helpful reminders or clarifications.

Table of Contents

  1. Introduction to Version Control and SVN

    • What is Version Control?
    • Why Use Version Control?
    • What is Subversion (SVN)?
    • SVN vs. Git (and other VCS)
    • Centralized vs. Distributed Version Control

  2. Core SVN Concepts

    • Repository
    • Working Copy
    • Revisions (and Revision Numbers)
    • Trunk, Branches, and Tags
      • Trunk (Mainline Development)
      • Branches (Parallel Development)
      • Tags (Snapshots)
    • Checkout
    • Commit
    • Update
    • Merge
    • Conflict Resolution
    • Log/History

  3. Setting Up Your SVN Environment

    • Choosing an SVN Server
      • Self-Hosted (Apache + SVN, VisualSVN Server, etc.)
      • Cloud-Based (Assembla, Beanstalk, etc.)
      • Considerations (Cost, Security, Accessibility)
    • Installing an SVN Client
      • TortoiseSVN (Windows)
      • Command-Line Client (svn)
      • IDE Integrations (Eclipse, Visual Studio, etc.)
    • Creating a Repository (Server-Side)

  4. Basic SVN Operations

    • Checkout: Obtaining a Working Copy
    • Adding Files and Directories: svn add
    • Committing Changes: svn commit
      • Writing Good Commit Messages
    • Updating Your Working Copy: svn update
    • Viewing the Log/History: svn log
    • Reverting Changes: svn revert
    • Checking Status: svn status
    • Ignoring Files: svn propset svn:ignore

  5. Branching and Merging

    • Creating a Branch: svn copy
    • Switching Between Branches: svn switch
    • Merging Changes: svn merge
      • Merge Strategies (Two-way, Three-way)
    • Resolving Merge Conflicts
      • Identifying Conflicts
      • Manual Conflict Resolution
      • Using Merge Tools
    • Deleting a Branch: svn delete

  6. Tagging

    • Creating a Tag: svn copy
    • Best Practices for Tagging

  7. Advanced SVN Concepts

    • Properties: svn propset, svn propget, svn proplist
      • svn:externals
      • svn:eol-style
      • svn:keywords
    • Hooks:
      • Pre-Commit Hooks
      • Post-Commit Hooks
    • Locking: svn lock, svn unlock (Generally Discouraged)
    • Sparse Directories
    • Repository Maintenance: svnadmin commands

  8. Best Practices for Using SVN

    • Commit Frequently
    • Update Regularly
    • Write Meaningful Commit Messages
    • Use Branches for Features and Bug Fixes
    • Test Before Committing
    • Plan Your Repository Structure
    • Use Tags for Releases
    • Back Up Your Repository

  9. Troubleshooting Common SVN Issues

    • “Working Copy Locked”
    • “Out of Date” Errors
    • Merge Conflicts
    • Tree Conflicts
    • Connection Issues

  10. SVN Clients: A Closer Look

    • TortoiseSVN (Windows)
      • Context Menu Integration
      • Overlay Icons
      • TortoiseMerge
    • Command-Line Client (svn)
      • Common Commands and Options
      • Scripting and Automation
    • IDE Integrations
      • Benefits of Integration
      • Examples (Eclipse, Visual Studio)

  11. Conclusion

1. Introduction to Version Control and SVN

  • What is Version Control?

    Version control, also known as source control or revision control, is a system that records changes to a file or set of files over time so that you can recall specific versions later. It’s like having an unlimited “undo” button for your entire project. It allows you to track every modification, who made it, and why.

  • Why Use Version Control?

    Version control is essential for any project involving multiple contributors, or even for solo projects that evolve over time. Here are some key benefits:

    • Collaboration: Multiple people can work on the same files simultaneously without overwriting each other’s changes.
    • History Tracking: You can see the entire history of changes, including who made them and when.
    • Reverting to Previous Versions: Easily go back to any previous state of your project if a mistake is made or a new feature introduces bugs.
    • Branching and Merging: Create separate lines of development (branches) for new features or experiments, and then merge them back into the main project when ready.
    • Backup and Recovery: Your repository acts as a central backup of your project.
    • Auditing and Accountability: Version control provides a clear audit trail of changes, making it easier to track down bugs and understand the evolution of the project.
    • Experimentation: Safely experiment with new ideas without fear of breaking the main project.

  • What is Subversion (SVN)?

    Subversion (SVN) is a centralized version control system (CVCS). It’s a widely used and mature system that provides a robust and reliable way to manage your project’s history. SVN uses a central repository to store all the files and their history. Developers check out working copies of the files from this repository, make changes, and then commit those changes back to the repository.

  • SVN vs. Git (and other VCS)

    The most popular alternative to SVN is Git, a distributed version control system (DVCS). Here’s a comparison:

    Feature SVN (Centralized) Git (Distributed)
    Repository Single, central repository Each developer has a full copy
    Offline Work Limited (need connection to commit) Full offline functionality
    Branching/Merging Generally slower and more complex Very fast and flexible
    Performance Can be slower for large repositories Generally faster, especially for branching
    Complexity Simpler to learn initially Steeper learning curve
    History Linear history Non-linear history (DAG)
    Disk Space Less disk space on client side More disk space on client side
    Security Centralized access control Distributed, more flexible access control
    Backup Single point of failure (repository) Multiple backups (each clone)

    Other version control systems include Mercurial (similar to Git), Perforce (often used in game development), and CVS (an older system, largely superseded by SVN).

    The choice between SVN and Git depends on your project’s needs and your team’s preferences. SVN is often preferred for its simplicity and centralized control, while Git is favored for its speed, flexibility, and offline capabilities. For many smaller projects, SVN’s simplicity makes it an excellent choice.

  • Centralized vs. Distributed Version Control

    This is a fundamental difference between SVN and Git:

    • Centralized (SVN): There’s a single, central repository that acts as the “source of truth.” Developers must connect to this central repository to commit changes, update their working copies, and perform other operations. This simplifies administration and access control, but it also creates a single point of failure.

    • Distributed (Git): Every developer has a complete copy of the repository, including the entire history. This allows for offline work, faster operations, and greater resilience. Developers can commit changes locally and then synchronize their changes with other developers later.

2. Core SVN Concepts

Understanding these core concepts is crucial for using SVN effectively:

  • Repository: The central database that stores all your project’s files, directories, and their entire revision history. It’s the heart of the SVN system. The repository is typically hosted on a server. It’s often accessed via a URL (e.g., svn://example.com/repo or https://example.com/svn/repo).

  • Working Copy: A local copy of a specific version of the files from the repository. This is where you make your changes. The working copy also contains hidden metadata (in a .svn directory in each folder) that SVN uses to track changes and communicate with the repository. Do not manually modify the .svn directories.

  • Revisions (and Revision Numbers): Every time you commit a set of changes to the repository, SVN creates a new revision. Each revision is assigned a unique, sequential revision number (e.g., 1, 2, 3, …). These numbers represent snapshots of the entire repository at a specific point in time.

  • Trunk, Branches, and Tags: These are conventions for organizing your project within the repository. They are implemented as directories within the repository, but SVN treats them specially.

    • Trunk (Mainline Development): This is the main line of development for your project. It typically contains the most stable and up-to-date code. Most development work happens on the trunk. It’s usually located at /trunk in the repository.

    • Branches (Parallel Development): Branches are used to create separate lines of development. This is useful for working on new features, bug fixes, or experimental changes without affecting the stability of the trunk. Branches are typically created from the trunk (or another branch) and can be merged back later. They are usually located at /branches in the repository.

    • Tags (Snapshots): Tags are used to create read-only snapshots of the project at a specific point in time. They are commonly used to mark releases (e.g., version 1.0, 2.0). Tags should not be modified after they are created. They are usually located at /tags in the repository.

  • Checkout: The process of obtaining a working copy from the repository. You specify the repository URL and the revision you want to check out (usually the latest revision). This creates a local directory with the files and the .svn metadata.

  • Commit: The process of sending your changes from your working copy to the repository. This creates a new revision in the repository. You should always include a commit message that describes the changes you made.

  • Update: The process of synchronizing your working copy with the latest changes from the repository. This downloads any changes that have been committed by other developers since your last update.

  • Merge: The process of combining changes from one branch (or the trunk) into another. This is typically done to integrate a feature branch back into the trunk after development is complete.

  • Conflict Resolution: If two or more developers have modified the same lines of a file, SVN will detect a conflict during an update or merge. You will need to manually resolve these conflicts by choosing which changes to keep or by modifying the file to combine the changes.

  • Log/History: SVN provides a log or history of all the changes that have been made to the repository. You can view the log to see who made changes, when they were made, and what the commit messages were.

3. Setting Up Your SVN Environment

  • Choosing an SVN Server

    You have two main options for setting up an SVN server:

    • Self-Hosted: You install and manage the SVN server software on your own server.

      • Apache + SVN: A common and flexible approach. You use the Apache web server with the mod_dav_svn module to provide access to the SVN repository. This offers good control and customization.
      • VisualSVN Server (Windows): A popular and easy-to-use option for Windows servers. It provides a graphical interface for managing repositories and users.
      • svnserve: A lightweight, standalone SVN server. Good for smaller projects or testing.

    • Cloud-Based: You use a third-party service to host your SVN repository.

      • Assembla: A popular platform offering SVN, Git, and other project management tools.
      • Beanstalk: Another platform providing SVN and Git hosting.
      • Many other providers: Search for “SVN hosting” to find more options.

    • Considerations:

      • Cost: Self-hosting can be cheaper in the long run, but requires more technical expertise. Cloud-based services typically charge a monthly or annual fee.
      • Security: Ensure your server is secure, whether it’s self-hosted or cloud-based. Use strong passwords and consider using HTTPS for secure communication.
      • Accessibility: Make sure your server is accessible to all your team members.

  • Installing an SVN Client

    You need an SVN client to interact with the SVN server. Here are some popular options:

    • TortoiseSVN (Windows): A very popular and user-friendly client that integrates directly into the Windows Explorer shell. It provides context menu options and overlay icons to show the status of your files. Highly recommended for Windows users.

    • Command-Line Client (svn): The official SVN client, available on most operating systems (including Windows, macOS, and Linux). It provides a set of commands for interacting with the repository. This is a good option for scripting and automation. To check if it’s installed, open a terminal or command prompt and type svn --version.

    • IDE Integrations: Many Integrated Development Environments (IDEs) have built-in support for SVN or offer plugins. Examples include Eclipse (Subclipse or Subversive), Visual Studio, IntelliJ IDEA, and others. These integrations provide a convenient way to manage your version control within your development environment.

  • Creating a Repository (Server-Side)

    The process of creating a repository depends on your chosen server setup. Here are examples for common scenarios:

    • VisualSVN Server:

      1. Open VisualSVN Server Manager.
      2. Right-click on “Repositories” and select “Create New Repository…”.
      3. Choose a name for your repository (e.g., “MyProject”).
      4. Select the repository structure (recommended: “Single-project repository (trunk, branches, tags)”).
      5. Set permissions (who can access the repository).
      6. Click “Create”.

    • Apache + SVN (svnadmin create):

      1. Log in to your server.
      2. Choose a location for your repository (e.g., /var/svn/repos).
      3. Use the svnadmin create command: svnadmin create /var/svn/repos/MyProject
      4. Configure Apache to serve the repository (using mod_dav_svn). This involves editing Apache configuration files (e.g., httpd.conf or a separate SVN configuration file) and adding a <Location> block that specifies the repository path and access control.
        apache
        <Location /svn>
        DAV svn
        SVNParentPath /var/svn/repos
        AuthType Basic
        AuthName "Subversion Repository"
        AuthUserFile /etc/svn-auth-file
        Require valid-user
        </Location>
      5. Create a user authentication file (e.g., htpasswd -c /etc/svn-auth-file username).
      6. Restart Apache.

    • svnserve:

      1. Log in to your server.
      2. Choose a location for your repository.
      3. Use the svnadmin create command: svnadmin create /path/to/repo
      4. Start the svnserve daemon: svnserve -d -r /path/to/repo
        (You can customize the port using the -p option, and add other options as needed.)

    • Cloud-Based Services: Follow the instructions provided by your chosen service (e.g., Assembla, Beanstalk). Typically, this involves creating an account and then creating a new repository through a web interface.

4. Basic SVN Operations

These are the fundamental commands you’ll use most often:

  • Checkout: Obtaining a Working Copy

    bash
    svn checkout <repository_url> <local_directory>

    • <repository_url>: The URL of the repository you want to check out (e.g., https://example.com/svn/MyProject/trunk).
    • <local_directory>: The local directory where you want to create the working copy (optional; if omitted, it will use the repository name).

    Example:

    bash
    svn checkout https://example.com/svn/MyProject/trunk MyProject
    This command will check out the trunk of the MyProject repository into a local directory named MyProject.

    With TortoiseSVN:
    1. Right-click in an empty folder where you want to create the working copy.
    2. Select “SVN Checkout…”.
    3. Enter the repository URL.
    4. Specify the local directory (optional).
    5. Click “OK”.

  • Adding Files and Directories: svn add

    Before you can commit new files or directories to the repository, you need to add them to SVN’s tracking system.

    bash
    svn add <path>

    • <path>: The file or directory you want to add.

    Example:

    bash
    svn add newfile.txt
    svn add new_directory
    This command schedules newfile.txt and new_directory to be added to the repository on the next commit. It does not immediately send the files to the repository.

    With TortoiseSVN:
    1. Right-click on the new file or directory.
    2. Select “TortoiseSVN” -> “Add”.

  • Committing Changes: svn commit

    This sends your local changes (added files, modified files, deleted files) to the repository, creating a new revision.

    bash
    svn commit -m "Your commit message here" <path>
    * -m "Your commit message here": This is crucial. Always provide a clear and concise description of your changes.
    * <path> (optional): You can specify specific files or directories to commit. If omitted, it will commit all changes in the working copy.
    Example:

    bash
    svn commit -m "Added new feature to handle user input"

    With TortoiseSVN:
    1. Right-click on the modified files or directory, or on the root of the working copy.
    2. Select “SVN Commit…”.
    3. Enter your commit message.
    4. Select the files you want to commit (if necessary).
    5. Click “OK”.

    • Writing Good Commit Messages:

      • Be descriptive: Explain what you changed and why.
      • Be concise: Keep it relatively short, but informative.
      • Use the imperative mood (e.g., “Add feature”, “Fix bug”, not “Added feature”, “Fixed bug”).
      • Reference issue numbers or bug trackers if applicable.
      • Avoid vague messages like “Updated files” or “Changes”.

      Good Example: Fix: Corrected typo in login error message (issue #123)
      Bad Example: Changes

  • Updating Your Working Copy: svn update

    This synchronizes your working copy with the latest changes from the repository.

    bash
    svn update <path>
    * <path> (optional): You can update specific files or directories. If omitted it will update the entire working copy.

    Example:

    bash
    svn update

    With TortoiseSVN:
    1. Right-click on the working copy (or a specific file/directory).
    2. Select “SVN Update”.

    It’s a good practice to update your working copy frequently (e.g., before starting work each day, and before committing) to minimize the risk of conflicts.

  • Viewing the Log/History: svn log

    This displays the revision history of a file or directory.

    bash
    svn log <path>

    • <path>: The file or directory you want to see the log for. If omitted, it shows the log for the current directory.

    Example:

    bash
    svn log myfile.txt
    svn log
    You can use options like -r to specify a revision range, -l to limit the number of log entries, and -v for verbose output.

    With TortoiseSVN:
    1. Right-click on the file/directory, or the root of the working copy.
    2. Select “TortoiseSVN” -> “Show log”.

  • Reverting Changes: svn revert

    This discards local modifications and restores a file or directory to its state in the repository. Be careful, as this is irreversible.

    bash
    svn revert <path>

    • <path>: The file or directory you want to revert.

    Example:

    bash
    svn revert myfile.txt

    With TortoiseSVN:
    1. Right-click on the modified file or directory.
    2. Select “TortoiseSVN” -> “Revert…”.
    3. Confirm that you want to revert the changes.

  • Checking Status: svn status

    This shows the status of your working copy, indicating which files have been modified, added, deleted, etc.

    bash
    svn status <path>
    * <path>(optional): Check status for a particular file.

    Example:

    bash
    svn status

    The output of svn status uses single-letter codes to indicate the status of each file:

    • ?: The file is not under version control.
    • A: The file has been added.
    • M: The file has been modified.
    • D: The file has been deleted (scheduled for removal on the next commit).
    • C: The file has a conflict.
    • !: The file is missing
    • I: The file is ignored (using svn:ignore).
    • : The file is unchanged.

    With TortoiseSVN, file status is usually indicated by overlay icons in Windows Explorer.

  • Ignoring Files: svn propset svn:ignore

    You can tell SVN to ignore certain files or directories that you don’t want to track (e.g., build artifacts, temporary files, editor backups). This is done using the svn:ignore property.

    bash
    svn propset svn:ignore "<pattern>" <directory>

    • <pattern>: A pattern matching the files or directories you want to ignore (e.g., *.o, *.log, build/). You can specify multiple patterns separated by newlines.
    • <directory> The directory to which the ignore should apply.

    Example:

    bash
    svn propset svn:ignore "*.o" .
    svn propset svn:ignore "build
    *.log" .
    svn commit -m "Ignore build artifacts and log files"
    This will ignore all files ending in .o, a directory called build, and all files ending with .log in the current directory. The ignore pattern is stored in the directory’s properties and affects that directory and its subdirectories (unless overridden by a more specific svn:ignore property in a subdirectory).

    With TortoiseSVN:
    1. Right-click on the directory where you want to set the ignore pattern.
    2. Select “TortoiseSVN” -> “Properties”.
    3. Click “New…” and choose “ignore”.
    4. Enter the patterns (one per line) in the “Property value” box.
    5. Click “OK”.

5. Branching and Merging

Branching and merging are essential for managing parallel development in SVN.

  • Creating a Branch: svn copy

    You create a branch by copying a directory (usually the trunk) to a new location within the repository (usually under /branches). This is a “cheap copy” in SVN; it doesn’t duplicate all the files, but rather creates a link to the original.

    bash
    svn copy <source_url> <destination_url> -m "Creating branch for feature X"

    • <source_url>: The URL of the directory you want to branch (e.g., https://example.com/svn/MyProject/trunk).
    • <destination_url>: The URL where you want to create the branch (e.g., https://example.com/svn/MyProject/branches/feature-x).

    Example:

    bash
    svn copy https://example.com/svn/MyProject/trunk https://example.com/svn/MyProject/branches/feature-x -m "Creating branch for feature X"

    With TortoiseSVN:
    1. Right-click on the directory you want to branch (e.g., the trunk in your working copy).
    2. Select “TortoiseSVN” -> “Branch/tag…”.
    3. In the “To URL” field, enter the URL for the new branch.
    4. Enter a commit message.
    5. Click “OK”.

  • Switching Between Branches: svn switch

To work on a branch, you need to switch your working copy to that branch.

```bash
svn switch <branch_url> <working_copy_path>
```

*    `<branch_url>`: The URL for the branch.
*   `<working_copy_path>`: The path to your working copy (often omitted if you're already in the working copy directory).

Example:

```bash
svn switch https://example.com/svn/MyProject/branches/feature-x
```

This will update your working copy to reflect the contents of the `feature-x` branch. Any changes you make and commit will now be committed to the branch.

With TortoiseSVN:
1. Right-click on the root of your working copy.
2. Select "TortoiseSVN" -> "Switch...".
3. Enter the URL of the branch you want to switch to.
4. Click "OK".

  • Merging Changes: svn merge

    Merging combines changes from one branch (or the trunk) into another. This is typically used to integrate a feature branch back into the trunk after development is complete.

    bash
    svn merge <source_url_1> <source_url_2> <working_copy_path>

    • <source_url_1> and <source_url_2>: These specify the revisions or URLs to be merged. The most common use-case involves only <source_url_1>.
    • <working_copy_path>: The working copy where you want to apply the merge (usually the trunk or the target branch).

    There are several ways to use svn merge:

    • Merging a range of revisions from a branch:

      bash
      svn merge -r <start_revision>:<end_revision> <branch_url>
      This merges all changes from the specified revision range on the branch into your working copy.

    • Merging all changes from a branch (reintegrate merge):
      bash
      svn merge <branch_url>
      This is the reintegrate method. Your working copy must be a clean, updated copy of the target branch.

    • Two-URL merge:
      bash
      svn merge <url1> <url2>
      This compares url1 and url2 and applies the differences to your working copy.

    Example (Reintegrate Merge – most common):

    1. Update your working copy of the trunk to the latest revision: svn update
    2. Switch to the trunk if you aren’t already there.
    3. Merge the changes from the branch: svn merge https://example.com/svn/MyProject/branches/feature-x
    4. Resolve any conflicts (see below).
    5. Test the merged code.
    6. Commit the changes: svn commit -m "Merged feature-x branch into trunk"

    With TortoiseSVN:

    1. Update your working copy of the target branch (e.g., the trunk).
    2. Right-click on the root of your working copy (of the target branch).
    3. Select “TortoiseSVN” -> “Merge…”.
    4. Choose “Merge a range of revisions”.
    5. Enter the URL of the branch you want to merge from.
    6. Usually leave “From:” and “To:” blank, which means merge all revisions.
    7. Click “Next” and follow the prompts.
    8. Resolve any conflicts.

    9. Test and commit.

    10. Merge Strategies (Two-way, Three-way):

      • Two-way merge: Compares two versions of a file and identifies the differences. This is less sophisticated and can lead to more conflicts.

      • Three-way merge: Compares three versions of a file: the common ancestor, the source version, and the target version. This is the standard merge approach in SVN (and most modern VCS). It’s more intelligent and can automatically resolve many changes that would be conflicts in a two-way merge. SVN automatically performs three-way merges.

  • Resolving Merge Conflicts

    Conflicts occur when two or more developers have modified the same lines of a file. SVN cannot automatically determine which changes to keep, so you need to resolve the conflicts manually.

    • Identifying Conflicts:

      During an svn update or svn merge, SVN will indicate conflicts with a “C” status. The conflicted file will contain conflict markers:

      “`
      <<<<<<< .mine
      This is my change.
      =======
      This is the change from the repository.

      .r123
      “`

      • <<<<<<< .mine: Marks the beginning of your local changes.
      • =======: Separates your changes from the changes from the repository.
      • >>>>>>> .r123: Marks the end of the changes from the repository (and indicates the revision number).

    • Manual Conflict Resolution:

      1. Edit the file: Open the conflicted file in a text editor.
      2. Choose the correct changes: Decide which version of the conflicting lines to keep, or modify the lines to combine the changes.
      3. Remove the conflict markers: Delete the <<<<<<<, =======, and >>>>>>> lines.
      4. Save the file.
      5. Mark the conflict as resolved: svn resolved <filename>

      Example:
      After editing the file, it might look like this:

      This is the combined change, incorporating both versions.

    • Using Merge Tools:

      Text editors designed for merging, or merge tools integrated into IDEs, greatly simplify resolving merge conflicts. TortoiseSVN includes TortoiseMerge, a visual diff and merge tool. These tools typically show the three versions of the file (base, mine, theirs) side-by-side, allowing you to easily choose which changes to keep or create a merged version. They automatically remove conflict markers.

    • svn resolved:

    After resolving the conflict and editing the file, you must tell SVN that the conflict is resolved using the svn resolved command.

    ```bash
svn resolved <filename>
```

This removes the conflict status and allows you to commit the changes.

  • Deleting a Branch: svn delete

    Once a branch is no longer needed (e.g., after it has been merged into the trunk), you can delete it. This doesn’t actually delete the files, but rather removes the branch from the latest revision of the repository. The branch and its history remain accessible in earlier revisions.

    bash
    svn delete <branch_url> -m "Deleting feature-x branch after merge"

    Example:
    bash
    svn delete https://example.com/svn/MyProject/branches/feature-x -m "Deleting feature-x branch after merge"

    With TortoiseSVN:
    1. You would typically use the Repository Browser. Right-click on your working copy, and choose TortoiseSVN -> Repo-browser.
    2. Navigate to the branch you want to delete.
    3. Right-click on the branch and select “Delete”.
    4. Enter a commit message.

6. Tagging

  • Creating a Tag: svn copy

    Creating a tag is similar to creating a branch; you use svn copy to create a “cheap copy” of a directory (usually the trunk or a branch) to a new location under /tags.

    bash
    svn copy <source_url> <destination_url> -m "Tagging release 1.0"

    • <source_url>: The URL of the directory you want to tag (e.g., https://example.com/svn/MyProject/trunk).
    • <destination_url>: The URL where you want to create the tag (e.g., https://example.com/svn/MyProject/tags/release-1.0).

    Example:

    bash
    svn copy https://example.com/svn/MyProject/trunk https://example.com/svn/MyProject/tags/release-1.0 -m "Tagging release 1.0"

    With TortoiseSVN:
    1. Right-click on the directory you want to tag (in your working copy).
    2. Select “TortoiseSVN” -> “Branch/tag…”.
    3. In the “To URL” field, enter the URL for the new tag.
    4. Enter a commit message.
    5. Click “OK

Leave a Comment

Your email address will not be published. Required fields are marked *

Scroll to Top