Monday, August 20, 2018

Close/abandon projects/branches strategy on SVN?

I was wondering what's the recommended strategy when a project or branch gets finished (will never ever be changed again) or abandoned.

In case of the projects, should I:

  • Leave it as it is
  • Have a repository root folder where all the projects get moved to when they are finished/abandoned
  • Just rename the folder to something like "CLOSED - Project Name"
  • Move it to a new repository that contains all the closed projects (I think this isn't a very good idea since I would lose all the history)
  • Another solution?

In case of the branches, should I:

  • Leave it as it is
  • Move it to a folder inside the branches named CLOSED or ABANDONED
  • Rename the branch to "Closed - Branch Name"
  • Another solution?

Solved

You can just delete it. All the history will be retained inside the repository - the repository (almost) never forgets.

You can access it using the command line tools by specifying a peg revision:

svn command item@PEG-REV

In TortoiseSVN you can go back in time by setting the peg revision using this button:

Repo-Browser

If you don't know the correct peg revision, use the log to find it.


I would recommend using proper tagging approach for the purpose of tracking latest project/branch state. Even though branch history is kept in a repository after it has been deleted, sometimes it is difficult (or just takes a long time) to find latest branch state of the deleted branch using peg revisions.

As for me, I use fine-grained tagging approach which can be illustrated by the following diagram (here you can find more detailed diagram representing the same principles):

tagging approach

As you can see, it uses specific convention of structuring your repository. Tags directory will have following subdirectories:

/tags
    /builds
        /PA
        /A
        /B
    /releases
        /AR
        /BR
        /RC
        /ST

PA means pre-alpha A means alpha B means beta AR means alpha-release BR means beta-release RC means release candidate ST means stable

Following described convention, you will have specific directories structure in your repository:

/tags
        /builds
            /PA
                /1.x.0
                /1.x.3
                /2.x.0
            /A
                /1.x.1
                /1.x.4
                /2.x.1
            /B
                /1.x.2
                /1.x.5
             -> /2.x.2 <-
        /releases
            /AR
                /1.0.0
            /BR
                /1.0.1
            /RC
                /1.0.2
                /1.0.3
            /ST
             -> /1.0.4 <-

It is expected that before you delete branch, you create tag in corresponding directory. And then you can easily find latest states of your deleted branches in, for example, tags/builds/B or tags/releases/ST directories.


I have a dislike for deleting old projects from Subversion. Although many people say that they will always exist in the history, the fact is that it's really not discoverable, as you have to start picking random dates in the past to find out where the project was and then when it was deleted. If you don't know the exact name of what you're looking for then finding deleted items in Subversion is really non-trivial.

I prefer a different strategy of creating a top-level directory in SVN called 'archive'. Any old projects are moved there so that you retain the advantage that old projects no longer appear in the trunk, but if you need to consult the source for the old project then it's very easy to find, and it keeps the old defunct projects in one place.

In my case the repository structure is something like this:

/trunk
/tags
/branches
/archive
  /projects

No comments:

Post a Comment