Editing Apache Subversion (section)

==Limitations and problems==
A known problem in Subversion affects the implementation of the file and directory rename operation. {{As of|2014}}, Subversion implements the renaming of files and directories as a "copy" to the new name followed by a "delete" of the old name. Only the names change, all data relating to the edit history remains the same, and Subversion will still use the old name in older revisions of the "tree". However, Subversion may become confused when a move conflicts with edits made elsewhere,<ref>{{Cite web |url=http://subversion.tigris.org/issues/show_bug.cgi?id=898 |title=Implement true renames |access-date=2007-05-11 |archive-date=2002-12-01 |archive-url=https://web.archive.org/web/20021201064344/http://subversion.tigris.org/issues/show_bug.cgi?id=898 |url-status=dead }}</ref> both for regular commits and when merging branches.<ref>[https://svnbook.red-bean.com/en/1.7/svn.branchmerge.advanced.html#svn.branchmerge.advanced.moves Advanced Merging]</ref> The Subversion 1.5 release addressed some of these scenarios while others remained problematic.<ref>[https://subversion.apache.org/docs/release-notes/1.5.html#copy-move-improvements Copy/move-related improvements in Subversion 1.5]</ref> The Subversion 1.8 release addressed some of these problems by making moves a first-class operation on the client, but it is still treated as copy+delete in the repository.<ref>[https://subversion.apache.org/docs/release-notes/1.8.html#moves Working copy records moves as first-class operation in Subversion 1.8]</ref>

{{As of | 2013}}, Subversion lacks some repository-administration and management features. For instance, someone may wish to edit the repository to permanently remove all historical records of certain data. Subversion does not have built-in support to achieve this simply.<ref>{{Cite web |url=https://issues.apache.org/jira/browse/SVN-516 |title=[SVN-516] svn obliterate |access-date=2023-09-04 }}</ref>

Subversion stores additional copies of data on the local machine, which can become an issue with very large projects or files, or if developers work on multiple branches simultaneously. In versions prior to 1.7 these <code>.svn</code> directories on the client side could become corrupted by ill-advised user activity like global search/replace operations.<ref>{{Cite web|url=https://stackoverflow.com/a/579442|title=Subclipse - Repair SVN Checksum}}</ref> Starting with version 1.7 Subversion uses a single centralized {{mono|.svn}} folder per working area.<ref>[https://subversion.apache.org/docs/release-notes/1.7.html#wc-ng Working Copy Metadata Storage Improvements (client)]</ref>

Subversion does not store the modification times of files. As such, a file checked out of a Subversion repository will have the 'current' date (instead of the modification time in the repository), and a file checked into the repository will have the date of the check-in (instead of the modification time of the file being checked in). This might not always be what is wanted.<ref>{{Cite web |url=https://issues.apache.org/jira/browse/SVN-1256 |title=[SVN-1256] Ability to preserve last modification time (mtime) of files under version control |access-date=2023-09-04 }}</ref>
To mitigate this, third-party tools exist that allow for preserving modification time and other filesystem meta-data.<ref>[https://sourceforge.net/projects/freezeattrib/files/ FreezeAttrib (saves/restores file attributes using properties)]</ref><ref>{{GitHub|phmarek/fsvs|fsvs – Full System Versioning System}}<!-- previously "FSVS (Fast System VerSioning)" archived at https://web.archive.org/web/20100825094540/http://fsvs.tigris.org/ --></ref>
However, giving checked out files a current date is important as well — this is how tools like [[make (software)|make(1)]] will take notice of a changed file for rebuilding it.

Subversion uses a centralized [[revision control]] model. [[Ben Collins-Sussman]], one of the designers of Subversion, believes a centralised model would help prevent "insecure programmers" from hiding their work from other team members during development.<ref>[http://blog.red-bean.com/sussman/?p=96 Programmer Insecurity @ iBanjo<!-- Bot generated title -->]</ref> Some users of version control systems see the centralised model as detrimental; famously, [[Linus Torvalds]] attacked Subversion's model and its developers.<ref>[https://www.youtube.com/watch?v=4XpnKHJAok8 Google Tech Talk video] and its [https://web.archive.org/web/20110725034129/https://git.wiki.kernel.org/index.php/LinusTalk200705Transcript transcript]</ref>

Subversion often does not deal well with the [[Unicode equivalence#Normalization|filename normalization]] performed by the [[HFS+]] filesystem. This can cause problems when files with accented characters in their names are added to the repository on a non-HFS+ filesystem and the repository is then used with HFS+.<ref>{{Cite web |url=https://issues.apache.org/jira/browse/SVN-2464 |title=[SVN-2464] Canonicalize / stringprep UTF-8 filenames to handle composed / decomposed differences shown by e.g. Mac OS X HFS+ |access-date=2023-09-04 }}</ref>

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