How do I ignore files in Subversion?
Also, how do I find files which are not under version control?
commandsvn
How do I ignore files in Subversion?
Also, how do I find files which are not under version control?
Git is not better than Subversion. But is also not worse. It's different.
The key difference is that it is decentralized. Imagine you are a developer on the road, you develop on your laptop and you want to have source control so that you can go back 3 hours.
With Subversion, you have a Problem: The SVN Repository may be in a location you can't reach (in your company, and you don't have internet at the moment), you cannot commit. If you want to make a copy of your code, you have to literally copy/paste it.
With Git, you do not have this problem. Your local copy is a repository, and you can commit to it and get all benefits of source control. When you regain connectivity to the main repository, you can commit against it.
This looks good at first, but just keep in mind the added complexity to this approach.
Git seems to be the "new, shiny, cool" thing. It's by no means bad (there is a reason Linus wrote it for the Linux Kernel development after all), but I feel that many people jump on the "Distributed Source Control" train just because it's new and is written by Linus Torvalds, without actually knowing why/if it's better.
Subversion has Problems, but so does Git, Mercurial, CVS, TFS or whatever.
Edit: So this answer is now a year old and still generates many upvotes, so I thought I'll add some more explanations. In the last year since writing this, Git has gained a lot of momentum and support, particularly since sites like GitHub really took off. I'm using both Git and Subversion nowadays and I'd like to share some personal insight.
First of all, Git can be really confusing at first when working decentralized. What is a remote? and How to properly set up the initial repository? are two questions that come up at the beginning, especially compared to SVN's simple "svnadmin create", Git's "git init" can take the parameters --bare and --shared which seems to be the "proper" way to set up a centralized repository. There are reasons for this, but it adds complexity. The documentation of the "checkout" command is very confusing to people changing over - the "proper" way seems to be "git clone", while "git checkout" seems to switch branches.
Git REALLY shines when you are decentralized. I have a server at home and a Laptop on the road, and SVN simply doesn't work well here. With SVN, I can't have local source control if I'm not connected to the repository (Yes, I know about SVK or about ways to copy the repo). With Git, that's the default mode anyway. It's an extra command though (git commit commits locally, whereas git push origin master pushes the master branch to the remote named "origin").
As said above: Git adds complexity. Two modes of creating repositories, checkout vs. clone, commit vs. push... You have to know which commands work locally and which work with "the server" (I'm assuming most people still like a central "master-repository").
Also, the tooling is still insufficient, at least on Windows. Yes, there is a Visual Studio AddIn, but I still use git bash with msysgit.
SVN has the advantage that it's MUCH simpler to learn: There is your repository, all changes to towards it, if you know how to create, commit and checkout and you're ready to go and can pickup stuff like branching, update etc. later on.
Git has the advantage that it's MUCH better suited if some developers are not always connected to the master repository. Also, it's much faster than SVN. And from what I hear, branching and merging support is a lot better (which is to be expected, as these are the core reasons it was written).
This also explains why it gains so much buzz on the Internet, as Git is perfectly suited for Open Source projects: Just Fork it, commit your changes to your own Fork, and then ask the original project maintainer to pull your changes. With Git, this just works. Really, try it on Github, it's magic.
What I also see are Git-SVN Bridges: The central repository is a Subversion repo, but developers locally work with Git and the bridge then pushes their changes to SVN.
But even with this lengthy addition, I still stand by my core message: Git is not better or worse, it's just different. If you have the need for "Offline Source Control" and the willingness to spend some extra time learning it, it's fantastic. But if you have a strictly centralized Source Control and/or are struggling to introduce Source Control in the first place because your co-workers are not interested, then the simplicity and excellent tooling (at least on Windows) of SVN shine.
Hmm, not sure I agree with Nick re tag being similar to a branch. A tag is just a marker
Trunk would be the main body of development, originating from the start of the project until the present.
Branch will be a copy of code derived from a certain point in the trunk that is used for applying major changes to the code while preserving the integrity of the code in the trunk. If the major changes work according to plan, they are usually merged back into the trunk.
Tag will be a point in time on the trunk or a branch that you wish to preserve. The two main reasons for preservation would be that either this is a major release of the software, whether alpha, beta, RC or RTM, or this is the most stable point of the software before major revisions on the trunk were applied.
In open source projects, major branches that are not accepted into the trunk by the project stakeholders can become the bases for forks -- e.g., totally separate projects that share a common origin with other source code.
The branch and tag subtrees are distinguished from the trunk in the following ways:
Subversion allows sysadmins to create hook scripts which are triggered for execution when certain events occur; for instance, committing a change to the repository. It is very common for a typical Subversion repository implementation to treat any path containing "/tag/" to be write-protected after creation; the net result is that tags, once created, are immutable (at least to "ordinary" users). This is done via the hook scripts, which enforce the immutability by preventing further changes if tag is a parent node of the changed object.
Subversion also has added features, since version 1.5, relating to "branch merge tracking" so that changes committed to a branch can be merged back into the trunk with support for incremental, "smart" merging.
Best Solution
(This answer has been updated to match SVN 1.8 and 1.9's behaviour)
You have 2 questions:
Marking files as ignored:
By "ignored file" I mean the file won't appear in lists even as "unversioned": your SVN client will pretend the file doesn't exist at all in the filesystem.
Ignored files are specified by a "file pattern". The syntax and format of file patterns is explained in SVN's online documentation: http://svnbook.red-bean.com/nightly/en/svn.advanced.props.special.ignore.html "File Patterns in Subversion".
Subversion, as of version 1.8 (June 2013) and later, supports 3 different ways of specifying file patterns. Here's a summary with examples:
1 - Runtime Configuration Area -
global-ignores
option:global-ignores
list won't be shared by other users, and it applies to all repos you checkout onto your computer.C:\Users\{you}\AppData\Roaming\Subversion\config
Software\Tigris.org\Subversion\Config\Miscellany\global-ignores
in bothHKLM
andHKCU
.~/.subversion/config
2 - The
svn:ignore
property, which is set on directories (not files):.gitignore
works.svn:ignore
is applied to directories and is non-recursive or inherited. Any file or immediate subdirectory of the parent directory that matches the File Pattern will be excluded.While SVN 1.8 adds the concept of "inherited properties", the
svn:ignore
property itself is ignored in non-immediate descendant directories:(So the file
./subdirectory/ignoreThis
is not ignored, even though "ignoreThis.txt
" is applied on the.
repo root).Therefore, to apply an ignore list recursively you must use
svn propset svn:ignore <filePattern> . --recursive
.<filePattern>
value is different in a child directory then the child's value completely overrides the parents, so there is no "additive" effect.<filePattern>
on the root.
, then you must change it with--recursive
to overwrite it on the child and descendant directories.I note that the command-line syntax is counter-intuitive.
svn ignore pathToFileToIgnore.txt
however this is not how SVN's ignore feature works.3- The
svn:global-ignores
property. Requires SVN 1.8 (June 2013):svn:ignore
, except it makes use of SVN 1.8's "inherited properties" feature.svn:ignore
, the file pattern is automatically applied in every descendant directory (not just immediate children).svn:global-ignores
with the--recursive
flag, as inherited ignore file patterns are automatically applied as they're inherited.Running the same set of commands as in the previous example, but using
svn:global-ignores
instead:For TortoiseSVN users:
This whole arrangement was confusing for me, because TortoiseSVN's terminology (as used in their Windows Explorer menu system) was initially misleading to me - I was unsure what the significance of the Ignore menu's "Add recursively", "Add *" and "Add " options. I hope this post explains how the Ignore feature ties-in to the SVN Properties feature. That said, I suggest using the command-line to set ignored files so you get a feel for how it works instead of using the GUI, and only using the GUI to manipulate properties after you're comfortable with the command-line.
Listing files that are ignored:
The command
svn status
will hide ignored files (that is, files that match an RGAglobal-ignores
pattern, or match an immediate parent directory'ssvn:ignore
pattern or match any ancesor directory'ssvn:global-ignores
pattern.Use the
--no-ignore
option to see those files listed. Ignored files have a status ofI
, then pipe the output togrep
to only show lines starting with "I".The command is:
For example:
ta-da!