Isn't there a substantial problem with SVN tags?

Question

A common practice for SVN tags is to tag different releases in order to be able to find them with ease later. As I understand it, tagging is the same thing as branching, that is in two cases, it just creates a copy of the trunk in a separate directory (would it be branches/something or tags/1.2.3), which means that:

• There is no impact on the amount of data stored by SVN itself (excluding a few bytes which indicate that a specific tag corresponds to a specific revision). If the dump was 800 MB without the tag, it will still be 800 MB plus a few bytes with the new tag.

• Files are duplicated on disk when checked out. A project which takes 30 MB on disk will take 60 MB once the tag is created.

It means that:

• Once I create a tag, every developer of my team will get a lot of data from SVN the next time he will update.

• With dozens or hundreds of tags (like it's usually the case when tagging every release), checkouts can take hours even for a small project.

Isn't that problematic? Couldn't it implemented differently, for instance through svn propedit? Are there valid cases where it makes sense to checkout every tag, instead of just one?

---

Note: as someone who uses continuous deployment consistently, I never used tags in practice, since every commit is potentially deployed in production if it passes the tests. This means that I may have missed something fundamental about tags or their internals, and I'm sorry if this is the case. My interest towards tags rises from the fact that I spent the last two hours checking out a third-party small project which has over two hundred tags.

Answer 1

Why would it be a problem over having trunk and branches? A tag is just another branch, but (and perhaps this is the important bit) you do not have to checkout the entire SVN repo.

Instead of calling svn co http://repo/ call svn co http://repo/trunk Then, if you want to see a particular branch use svn switch.

Everyone I know who uses the trunk/tags/branches repo setup will checkout trunk or a branch as the root. Doing this, they will never see the other branches or tags unless they use svn switch to swap the view of the repo to that root.

What you describe is even more a problem with git as it checks out the entire repo and then presents you with a view of it based on a single branch or master. All the files are present (but hidden 'underneath' the current view), so technically SVN is superior to git in this regard (ie being able to partially checkout a fraction of a repo is particularly good when you multi-gigabyte repositories).

You don't need to use tags if you don't want to, they are only a marker in the repo anyway, being a cheap copy of the trunk that you have tagged. You could, if you preferred, remember the revision number (as this is a globally unique value) for the revision you tagged, but there is no way in SVN to mark a revision number with some human-readable moniker.

Answer 2

Subversion's sparse directories is what you are looking for.

First time checkout, you should run:

svn checkout --depth immediates <URL>

This will only checkout the first level, thus only directories if you follow the branches/, tags/, trunk/ convention. Try it; it will not download much.

Then go into tags/, and run

svn update --set-depth immediates

Only the directories representing the tags now show up.

Change to 'trunk/', and run

svn update --set-depth infinity

All of your trunk/ will be checked out.

And for branches/, you can select which ones should have an infinity depth or not. Just use the proper commands from above against each branch, following your desires.