Set SVN Property Ignore with TortoiseSVN

Objects that are not checked in, were marked with questionmarks by TortoiseSVN, if icon overlay is active and functional.

If you are performing a "SVN Commit..." and "Show unversioned files" is checked, then this files will be shown.

Over time the number of files and folders can be grown and you can easily lose the overview so that needed files are not checked in. Also the risk increases that files are checked in that shouldn't (like compiled code).

For example, Visual Studio creates the folder "bin" and "obj" automatically for the compiled code. But you never want to check in the folders and their content. You can ignore the folders and their content so that they will not shown, again. To do so right click on the object to ignore and then go to "TortoiseSVN→Add to ignore list". If you choose "(recursively)" the item will be ignored in this folder and all subfolders. For files you have the choice whether all files with the same extension (*.extension) or just this particular file (file.extension) is to be ignored.

Objects that are ignored, were marked by TortoiseSVN, if icon overlay is active and functional.

Set SVN Property External with TortoiseSVN

An already existing project can be integrated into a new main project with the help of Subversion. This has several advantages:

• No need to make a local copy (but be carefull with changes)
• You can choose the version of the existing project, always the newest or fixed at some revision
• You can use relative paths that can be predefined by the structure of the main project

If you are using a certain revision, then you prevent that changes in external project affect negatively on your project.

You can include an existing project with the property "svn:externals". This can be done at the root of the new main project.

In the context menu go to "TortoiseSVN → Properties→New...→Externals→New...". Then you have to set the "Local path" to which the external project should be checked out and the URL of the external project. If you always want to have the newest version of the external project choose "HEAD revision", otherwise choose "Revision" and set the "Peg" revision. Furthermore you can also set the "Operative" revision, if it differs.

With "SVN Update" the external projects will be checked out to the defined path.

Edit Subversion Properties with TortoiseSVN

In subversion you can set properties for versioned files and folders. There are some pre-defined properties that start e.g. with "svn:". To read and write properties in TortoiseSVN, you can use the context menu. Right click on some file or folder and then go to "TortoiseSVN → Properties".

In the upcoming diolog you can see and modify the properties that exist already. With "New..." you can set new properties. Some properties can then be selected and configured directly. To obtain all properties choose "Other".

A new dialog appears. Here you can select the "Property name". In "Property value" you can set the needed value.

You can set the properties either for a folder or for one or more files. If you set it for a folder you can set the properties optionally to all subfolders and containing files. To do that check "Apply property recursively".

Revision Control

I'm surprised again and again, when people do not use revision control systems in software development. Also I cannot understand not making frequently use of it. There are so many advantages when using it. Withal it does not matter which system is used, as long as one is used. I personally like to use subversion, but there are some others that can be used as well. Best known revision control systems are

• Concurrent Versions System (CVS)
• Git
• Mercurial
• Subversion (SVN)

But there are many others that could be mentioned, too.

There are many advantages using revision control systems. Usually called are

• Backup functionality
• Marked software revisions
• History of changes
• Concurrent software development

Some count backup functionality to the greatest advantage. But for me this is not the main feature of revision control. The main feature is the history of changes. All changes can be traced. Therefor you have to check in your code with significant comment. This is a point that is also not always done, but this should be a matter of course. Only with a significant comment you can identify the changes that are made. The checked in code with comment should reflect the added functionality. So it is easy to find the location at that the changes or added functionalities take place. It is also easy to revert changes that made the code worse. There are also other great features of revision control, but the main feature for me is history of changes.