Something seems wrong that it’s possible to drop an MSI that includes a file that the sources doesn’t include. It tells me that two different paths are being taken.

I also know that Rob has specifically posted in the past that SF being a pain is the reason for relying on weekly builds and very, very rarely pushing an SF release.

Also I don’t believe in relying on a txt file to keep track of changes. I use systems like TFS that allow me link source control changesets to work items. Checkin policies help enforce the business rules to make sure valid data is avaialable.

When doing a build, I can fully automate a report to include the descriptions of work items included since a previous build and to be able to get, zip and drop all files that corrospond to the changeset used to do the build.

I know your an agile guy and know all this, it’s probably just a matter of finding the time to do it and something better then SVN to try to integrate with.

You appear to be confusing the build system with the hosting site.

1. On the rare occasion a file is “missing,” it’s because a developer forgot to update the publish project to include a new file.
2. Even if it were easier to publish release on SF, we’d continue to publish weekly builds and push known-good ones as SF releases.
3. The “what’s in a release” is covered by history.txt, which is automatically tagged during the build.

It manifests itself in many ways such as files routinely missing from drops, relying on weekly release mechanism instead of v3 release because it’s easier that way, difficulty in being able to communicate what’s in a release and so on.

Even Rob is publically expressing frustration with SVN.

http://twitter.com/robmen/statuses/841808073