Automated Build and Locking The Repository

[Jim Clark]

We use NANT to automate our builds and currently users can check in changes during a build. We would like to prevent this by locking the repository or switching the repository to single-user mode during builds. Is there a way to do this?

If not, can any automated-building Vault users tell me how they deal with this problem?

Thanks,
Jim

[ian_sg]

We use CruiseControl.NET (which interacts with Vault via the command-line client) and NAnt to build Vault and Fortress. We don't care if people check in during a build, because CruiseControl.NET and Vault work together to make sure it doesn't matter. Here's what happens (and you could do the same thing without CruiseControl.NET, if you wanted to):

• CruiseControl.NET notices that there's been a check-in beneath the folder it's watching: $/project. It records that $/project is now at version 105.
• CruiseControl.NET retrieves version 105 of $/project into a local folder for building. (If someone had checked in and created version 106, it wouldn't matter.)
• CruiseControl.NET kicks off our NAnt script which does all the building and testing.
• If everything succeeds, CruiseControl.NET applies a label to version 105 of $/project. (So again, it wouldn't matter if there had been check-ins in the mean time.)
• Start over at the beginning. If there's been a check-in, we start again with the new folder version number.

If you wanted to implement something like this yourself using the command-line client, the relevant commands would be:

Code: Select all

VersionHistory (to record the latest folder version when the build starts)
GetVersion (to retrieve that version)
Label (with a version specified, to apply a label to the correct version)

There are probably NAnt task equivalents, if you wanted to go that route. I'm less familiar with the NAnt tasks, so that's left as an exercise for the reader.

[Jim Clark]

Thank you for replying.

I've heard of CuiseControl.NET but I haven't used it, so let me see if I understand the interaction.

Does CCNET basically keep a "project" version every time a check-in is performed in Vault and knows the version of each file in that "Project" version?

[ian_sg]

You can think of it that way, but strictly speaking, CCNet is just remembering the version of the Vault folder. Any time anything under a folder (recursively) changes, a Vault repository folder gets a new version. This applies to every folder in the repository, including the root.

Here's an example, starting with an empty repository:

Code: Select all

$/  (version 1)

Someone adds a folder called project:

Code: Select all

$/         (version 2)
$/project  (version 1)

Now somebody adds some source to $/project in one transaction:

Code: Select all

$/                       (version 3)
$/project                (version 2)
$/project/project.csproj (version 1)
$/project/project.cs     (version 1)

Now somebody checks in a change to project.cs:

Code: Select all

$/                       (version 4)
$/project                (version 3)
$/project/project.csproj (version 1)
$/project/project.cs     (version 2)

[Jim Clark]

Sorry, I was viewing the folder history by item rather than version and thus no seeing that this was the case. Doh!

I think that little tip is all I needed.

Thank You.

[Jim Clark]

In our build process NANT updates the versions numbers for assemblies that have changed (we have many assemblies) after it has gotten the code. If we could lock the database we would do so between getting the source and checking in and labeling the release to prevent anything from getting checked in other than the assembly.info files during the build.

Since we can't do this I think we will go to nightly builds while everyone is at home.

Thanks for all your help.

[lbauer]

Let us know if we can be of further assistance.