JNRowe

How do you enable HTTP repository hosting?

HTTP based repository hosting has never been a default, or even suggested option for repository hosting. If you require anonymous hosting the preferred method is still using OpenSSH.

With that said if you wish to enable HTTP hosting, the simplest method is to use dforce-http.so which is enabled using the HTTP option in the admin graphical user interface or by adding dforce-http.so to the plug-ins section of either the user configuration file ~/.dforce/host/options or /etc/dforce/host/options.

Since version 2.0.0 was released the host configuration files have been renamed to server to remove some of the ambiguity. There is no need to manually change the config files if you are upgrading it will be done automatically the first time DForce is run.

I'm already running a HTTP server, and I wish to host my repository using that server instead?

Currently this is only possible with Apache, however if you are a corporate customer who wishes to use a different server then please contact us. It is possible to write your own plug-in to accomplish this using the scripting interface, please be aware of the security implications of your plug-in though.

To see how to enable HTTP hosting under Apache refer to the reference manual appendix 4.

Apache 2.x support is only available since v2.0.0.

How do I create an empty project repository?

The answer is exactly the same way you create a project repository from a pre-seeded source tree. The only difference is you do not need to supply a ChangeLog entry:

TEST$ dforce --init my_new_project
ChangeLog entry:
.

TEST$ dforce --init --version "Initiating project" my_new_project
ChangeLog entry:
Empty project tree in preparation for my_new_project.
.

TEST$ dforce --init --public no --force-sign HMAC my_new_project
ChangeLog entry:
.

Can I use libtcrypt in my own projects?

libtcrypt is dual licensed, the licenses available are the APL and the GPL. This means you can link libtcrypt in to any software that is itself licensed under the GPL, however if you are developing a application that will be released without source you must abide by the APL.

The restrictions under the APL are covered in depth in the APL documentation that comes with the DForce SDK and the libtcrypt source archive.

How do you export a ChangeSet in a format that can be applied using GNU patch?

This simplest way to achieve this is to use the --gnu-export command, however you can convert previously exported ChangeSets in to a GNU diff format using cset2diff which is installed as /usr/share/dforce/support/cset2diff.:

TEST$ dforce --gnu-export --branch DEVEL --cset 24 --output-file cset24.patch
Output has been left in cset24.patch

TEST$ dforce --gnu-export --cset 24-30,46 --output-file cset%s.patch
ChangeSet 24 output has been left in cset24.patch
ChangeSet 25 output has been left in cset25.patch
ChangeSet 26 output has been left in cset26.patch
ChangeSet 27 output has been left in cset27.patch
ChangeSet 28 output has been left in cset28.patch
ChangeSet 29 output has been left in cset29.patch
ChangeSet 30 output has been left in cset30.patch
ChangeSet 46 output has been left in cset46.patch

support$ ./cset2diff cset12.xdf cset12.patch
Converting to GNU diff format.........

I read it was possible to export the merge of two branches using a GNU patch style --ifdef format, how does that work?

Well, implementation details aside the options --merge --ifdef <branch1> <branch2> <ifdef name> are what you require. It is important to note that although DForce knows how to produce correct output for C/C++/m4/shell scripts/ruby/perl it is up to the user to make sure they are handled correctly. With C/C++ this is simple, just adding -D<ifdef name> to CFLAGS should always produce the desired results. With, for example, shell scripts you must choose how to define the variable.

TEST$ dforce --merge --ifdef DEVEL MAIN DEVEL
Merging branches DEVEL and MAIN.

# Set from make based on the configure substituted variable DEVEL
# I often just use @DEVEL@ everywhere that is required, but many people
# seem to prefer the approach of setting a shell variable in the script
# and testing that.  I guess it makes it simpler to test both versions,
# but it is also makes it too easy to have a script that is running
# a different version to what the rest of the tree expects.
DEVEL=@DEVEL@

if [ ! -z "${DEVEL}" ]; then
count() {
    # Now returns 0 if $1 is unset
    echo $(( 2 * ${1:-0} ))
}
else
count() {
    echo $(( 2 * $1 ))
}
fi

How do I use the bash completion to complete on the names of remote repositories?

When the bash completion code was in beta testing the majority of users did not believe default completion on remote repositories was a good idea(mainly due to the number of remote repositories that are known by the users DForce configuration file). This will be changing in a future release as many users consider this usage to be non-intuitive.

However there has always been a method for completing on remote repositories, and the easiest way to enable support for it is to set the DFORCE_COMPLETE_REMOTE environmental variable.:

TEST$ export DFORCE_COMPLETE_REMOTE=true

I have a question that isn't covered in the documentation, where can I get it answered?

If you are corporate customer then you are given free telephone and email support from the DForce development team, who will be more than happy to answer any questions you have about the product and its supporting environment.

If you are a user of the "free" product then you should use the mailing lists.