7

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.

  • 3
    To be provocative: the problem is not with svn tags, it is with svn itself. Even for personal projects I prefer git to svn; if possible, convert your svn repository to a git one. – Basile Starynkevitch Jul 16 '15 at 14:54
  • 1
    @BasileStarynkevitch: I have an impression (and the answer by gbjbaanb confirms that) that the same problem affects git as well. While git is a solution to multiple issues with centralized version control systems, this may not be the case here. – Arseni Mourzenko Jul 16 '15 at 15:22
  • 2
    Git stores repositories locally, organized by content (hash), with no duplication. The cost to store a tag is on the order of a file with a name and a SHA-1 hash of a commit. – user2313838 Jul 16 '15 at 15:49
  • 4
    @BasileStarynkevitch svn tags are cheap too, the difference is that git stores them in a "stacked" organisation, whereas svn stores them in a "flattened" organisation. With git you get all the history, whereas svn only gets you the last revision. Switching branches in git is quick but at a cost of increased disk space, switching in SVN is slow but uses less disk. Its all trade-offs depending what your requirements are, neither is "good or bad", just different. Enterprise I worked at had a 5Gb repo, git would not have worked well with that, but it works very well with small OSS projects, etc. – gbjbaanb Jul 16 '15 at 16:06
  • 3
    the Linux kernel tar.bz2 is about 100Mb... teeny. If I took the enterprise I mentioned and checked out the entire repo, it would be 30Gb on local disk, and that only counted the UK repo, not the American, European or Australian ones. Anyway, the tool is only inappropriate if you use it in the wrong circumstances instead of using the right tool. Remember, they're all just tools. – gbjbaanb Jul 16 '15 at 17:31
19

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.

  • You can clone a single branch with git. Other than that, I agree with your answer. – Andres F. Jul 16 '15 at 16:01
  • 4
    well said. So much disinformation in the original post and comments it reads almost like a religious rant by a fanatical git user... – jwenting Jul 16 '15 at 17:11
7

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.