Implementation of SVN “branch”, “tag” and “trunk” with composer and config file

Question

I have read a lot of Q/A here about the meaning of the directories “branch”, “tag” and “trunk” in the SVN repos, and as now I think I understood, I'm trying to implement it.

I use Virtualmin to manage my server, and it creates repos for me through its web GUI. However, once created my repo is empty, so I guess I need to create the directory structure myself and commit it. Once done I put my project's files in trunk, and as I'm at a stable version state, I should branch it to branch/xxx (which will be a saving point in my development), and to tags/xxx (which will be my development version).

If I am right until here, then I switch with Tortoise to my new tag, and that's only it which will be changed in my next commits. By the way, with Tortoise, will I need to right click the current tag directory, or will I still be able to commit/revert directly from the root folder of my project?

My current project has a config file defining a couple of absolute path - maybe it's wrong but I haven't found any way to avoid it. As I want to be able to see my project running from any of those branches/trunk, does that mean I'll need a different config file for each version? If so, should I add this file to the ignore list? I mean what would be considered good practice?

Extra question: if I want to use Composer in this case, where should my composer.json and vendor directory be?

Thanks!

Answer 1

You're confusing tags and branches. Tags are not supposed to be modified. They're typically created (from the trunk or from a branch) each time you're doing a release of your applcation.

Branches are used to hold work in progress.

You should checkout the trunk directory to a working copy. To switch to a branch, use the switch command. There's no reason to have separate config files for each branch, sinc eyour working copy, at the same location, can point to whatever you want: thr trunk, a branch, or even a tag. The key point is that the working copy's root should be the root of your project:

So, suppose your project files contains the following files:

index.php
config.txt
some_folder
    foobar.php

Your repo would have the following layout:

trunk
    index.php
    config.txt
    some_folder
        foobar.php
branches
    maintenance_1.0
        index.php
        config.txt
        some_folder
            foobar.php
    feature_refactor_index_page
        index.php
        config.txt
        some_folder
            foobar.php
tags
    v1.0
        index.php
        config.txt
        some_folder
            foobar.php

And your working copy would be:

MyProject --> references trunk
    index.php
    config.txt
    some_folder
        foobar.php

If you want to work on the feature branch, switch to the branch, and your working copy will then be

MyProject --> references feature_refactor_index_page
    index.php
    config.txt
    some_folder
        foobar.php

So it would be exacttly the same, and there's no reason for the config file to contain different file paths.