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
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.