Would it be possible to have the trigger that caused the build as object?
So it would be possible to label the builds (e.g. in the setup or version documents that get generated) of one configuration depending on the trigger that caused it.
Think of having one trigger for "nightly builds" and one for "continous integration on commit". Maybe an extra "description" field would make sense for triggers to hold this text.
Additionally, it would be great to have the linked repository of that trigger available, so you will be able to clone the configuration and switching the repository by just adjusting the trigger (well the triggers repository) because in the workspace rules you might have something like "$Trigger.Repository$ > Source" instead of "$Source.RepositoryName$ > Source" where "RepositoryName" needs to be modified manually during cloning.
an alternative of having the repository as property of the trigger object would be, having possibility to mark one of the assigned repositories of the current configuration as "default" or "master", so you can refer to this in the stages using "$Source.Default$ or "$Source.Master$ "without having to change anything else (like the repository rules of each stage) when cloning a configuration.
the problem is, weed need to clone the "trunk" configuration sometimes and want to have to change as less as possible during cloning.
I think you can do some of what you want already. $Build.StartedBy$ will tell you who started the build (username or trigger name). You can also set variables from triggers, which allows you to specify different information depending on how the build started. So for tagging the build, just use an If action and an expression, eg :
$Build.StartedBy$ equals NightlyTrigger
With regards to $Trigger object, we will have to take a look at that, currently the trigger isn’t exposed to the build. $Trigger.Repository may not work though, because what value would it have if $Trigger was actually a user.
Specifying which is the Master repository is something we have discussed here in the office many times, but never really reached agreement on how one should determine which is the Master repo, or what a use case would be for having that information. This might be something we can add, now that we have an idea how it might be used it’s something worth considering.
BTW, if you just have 1 repository, then $Source$ > \Source will clone ok.
$Source$ > \Source will clone it, thats right but it will clone it to \Source\RepositoyName, so having different continua repositories (that point the same svn repository but to different branches), you have to change all $Source.RepositoryName$ occurrences to $Source.OtherRespoitoryName$ and thats annoying.