Editing Apache Subversion (section)

===Subversion tags and branches===
Revision numbers are difficult to remember in any version-control system. For this reason, most systems offer symbolic ''tags'' as user-friendly references to them. Subversion does not have such a feature and what its documentation recommends to use instead is very different in nature. Instead of implementing tags as ''references'' to points in history, Subversion recommends making snapshot ''copies'' into a well-known subdirectory ("{{code|tags/}}") in the space of the repository tree. Only a few predefined ''references'' are available: {{code|HEAD}}, {{code|BASE}}, {{code|PREV}} and {{code|COMMITTED}}.

This history-to-space projection has multiple issues:

{{ordered list
| When a snapshot is taken, the system does not assign any special meaning to the name of the tag/snapshot. This is the difference between a ''copy'' and a ''reference''. The revision is recorded and the snapshot can be accessed by URL. This makes some operations less convenient and others impossible. For instance, a naive {{code|svn diff -r tag1:tag2 myfile}} does not work; it is slightly more complicated than that to achieve, requiring the user to know and input URL/paths to the snapshots instead of just the names: {{code|svn diff <URL-TO-TAG1>/myfile <URL-TO-TAG2>/myfile}}. Other operations like for instance {{code|svn log -r tag1:tag2 myfile}} are just impossible.

| When two (ideally independent) object types live in the repository tree, a "fight to the top" can ensue. In other words, it is often difficult to decide at which level to create the {{code|tags/}} subdirectory:

{{(!}}
{{!}}
 '''trunk'''/
      /component'''foo'''/
      /component'''bar'''/
 '''tags'''/
     /1.1/
         /component'''foo'''/
         /component'''bar'''/
{{!}} &nbsp;or&nbsp;
{{!}}
 component'''foo'''/
             /'''trunk'''/
             /'''tags'''/
                  /1.1/
 component'''bar'''/
             /'''trunk'''/
             /'''tags'''/
                  /1.1/
{{!)}}

| Tags, by their conventional definition, are both read-only and light-weight, on the repository and client. Subversion copies are not read-only, and while they are light-weight on the repository, they are incredibly heavy-weight on the client.}}

To address such issues, posters on the Subversion mailing lists have suggested a new feature called "labels" or "aliases".<ref>For example: {{cite mailing list |url=https://svn.haxx.se/dev/archive-2005-05/1095.shtml |title=Subversion 'labels' vs. 'tags' |date=23 May 2005 |access-date=5 May 2020 |mailing-list=SVN Dev |last=Weintraub |first=David }}</ref> SVN labels would more closely resemble the "tags" of other systems such as [[Concurrent Versions System|CVS]] or [[Git (software)|Git]]. The fact that Subversion has global revision numbers opens the way to a very simple label → revision implementation. Yet as of 2013, no progress has been made and symbolic tags are not in the list of the most wanted features.<ref>{{cite web |url=https://subversion.apache.org/roadmap.html |title=Apache Subversion Roadmap |publisher=Apache Project |access-date=5 May 2020}}</ref>