(This is now a History Post – Information is now depreciated)

The DasBlog project on SourceForge has migrated to SubVersion.

To browse the project on the web, go to:

http://svn.sourceforge.net/viewcvs.cgi/dasblogce/

You can use the command-line client:

Or you can use the TortoiseSVN Windows shell

extension:

In either case, you must enable the ASP.NET "hack". It simply requires you set an environment variable before working with SubVersion:

set SVN_ASP_DOT_NET_HACK=1

The rest of this document will assume the command-line client. The equivalent actions with TortoiseSVN should be fairly obvious.

The first thing you will notice is that the project root folder (dasblogce), has 3 subfolders:

[branches]

[tags]

[trunk]

*TRUNK

All work is done from the trunk folder. All checkins/commits should be to the trunk folder. In fact, when working with the code, you should treat /dasblogce/trunk as the root folder (as opposed to /dasblogce).

For example, to checkout a working copy of the entire codebase, you would use the following command:

svn checkout

dasblogce

This will create a new folder on your filesystem named dasblogce which contains all of the data under the trunk folder. Nothing from branches or tags will be retrieved.

*TAGS

The tags folder is used to hold milestone snapshots of the repository. Typically, after each release, you will create a new "tag", so that it is easy to retrieve the codebase corresponding to that release.

You create a new tag by copying the trunk folder to a new named subfolder of the tags folder.

For example, to take a snapshot of the codebase after making the 1.9.6180.1 release, you would run:

svn copy

If you forget to tag after a release, you can always reference the previous state if you know the revision number.

For example, I created a tag for the state of the codebase after the CVS migration (revision 410), even though the code had been modified since.

svn copy -r 410

Note: There is nothing that technically limits you from checking out a working copy from the tags folder, and then committing changes. However, it is a VERY BAD IDEA. The tags folder should just contain snapshots in time. Make all changes to the trunk or a branch.

*BRANCHES

The branches folder is used to create alternate branches of the source base. The process for creating a branch is the same as creating a new tag. Just copy the trunk folder to a new subfolder of the branches folder. You can then checkout and commit your changes to the branched folder, and then merge it back into the trunk when appropriate.

*DasBlog Specifics

The DasBlog trunk folder has the following layout:

[docs]

[lib]

[source]

[tools]

package.bat

The source folder contains only the source code and automated unit tests created by the DasBlog development team. Under CVS, this folder held all files related to the project. The following sections will describe the new location for files that are not considered part of the DasBlog source code, but are still kept with the project.

The docs folder contains all documention and reference material (URL links). This includes the readme, license, and release notes.

The lib folder contains all compiled 3rd party assemblies referenced by the source code projects.

These files used to be in the source\Assemblies folder. The projects under the source folder have been updated to reference the files in the lib folder (which is why it is important to checkout the entire trunk, and not just the source subfolder, when working on code).

The tools folder contains all of the executables needed to support the development and packaging of DasBlog (not including the .NET Framework itself). For example, the tools\nunit folder contains all of the nunit executables required to run the DasBlog unit tests. Note that the nunit.framework.dll referenced by the test projects is copied to the lib folder - source code should not reference files in the tools folder directly. Keeping the tools stored with the project helps ensure that all developers on the project always use the same version. (You will want to remove NUnit from your GAC to avoid overriding the project copies.) For more information about this strategy, check out Mike Robert's excellent article "How to setup a .NET Development Tree":

The CreateDasBlogVdir.vbs file is also in the tools folder, and has been updated so that it works properly from that location.

package.bat is the sole file in the root of the project (arguably, it could have been placed in the tools folder). It is used to create the release files to post on SourceForge. A number of changes have been made to the script, although the resulting release files are equivalent to files created with the previous version.

Most importantly, the script will now automatically determine the release version number based on the AssemblyVersion attribute in the source\AssemblyInfo.cs file. While you still have to manually update AssemblyInfo.cs when the time comes, you no longer need to modify package.bat for each release.

package.bat now takes an optional command-line argument. You can specify ALL (the default), WEB, or SOURCE. If you specify WEB or SOURCE, it will only create the one zip file.

All release files are created in the build subfolder.

The build subfolder is considered a temporary folder, so it is wiped out every time package.bat is executed, and Subversion has been set to ignore the folder (via the svn:ignore property).