Hello,
we're currently evaluating the QuickBuild 2.0 with 30 day trial key recently received to determine whether renewing support subscription and migrating from our current QuickBuild 1.2.13 to new QuickBuild 2.0 would be an useful option for us.

So yesterday I started with test migration of data from QuickBuild 1.2 and have noticed few issues where the following one is the most important.

The migration procedure seems to take all storage data from QuickBuild 1.2 and copy them under new hierarchy into the specified storage directory.

The first ugly thing is that all the contents in the new storage directory is created as directories with just numbers as their names which makes the whole directory structure hard to review.

But the biggest problem is that all the migrated content is put just into the <new-storage-directory>/builds/ directory which can result in tens of thousands directories (with just numbers as their names) to be created in that single directory.

For example on ext3 filesystem (probably the most common filesystem on Linux OS at this time) there's a limit of 32000 inodes (31998 subdirectories) per directory so it's pretty easy to reach this limit and end up with migration failure.
Some other filesystems such as XFS or JFS have virtually no limit here, but tt may be difficult to migrate to them in some cases so taking such filesystem limits into account during the migration procedure would be essential.

Check http://www.inthelight.co.nz/techo/pcfilesystem.htm for rpetty good overview of some filesystems limit.

It would be also great to have an option to migrate just the configuration stuff excluding the builds, logs, etc from previous version so that these data won't be duplicated. Then we'll be able to leave the older builds in the old storage directories and only new builds will be created in the new one.