[SalesForce] Migration Tool: “Concurrent modification from setup pages”

Sense Check. If I have understood correctly you have reached a point where all your metadata and code for your solution is in SVN, nice! Then I assume you have developers deploying from that into orgs to perform development. Such as adding custom fields to Account and then downloading the Account.object file to commit back into SVN. Here you are finding additional information and metadata which is causing problems. If so maybe this will help to ensure only custom fields are committed in your Account.object files.

Downloading only Account Custom Fields via Eclipse. When your developing in your DE orgs you can open up the Project settings and under Force.com, use Project Contents to select only the custom fields for the Account object. This will result in a .object file with only custom fields in it. If your developers ensure they follow this practice, your deployment scripts should have less issues around this object.

As you can also see, only your custom WebLinks and ListViews can also be downloaded in the same way.

NOTE: The package.xml generated by Eclipse uses the CustomField metadata type to list the individual fields being added to account. This is not needed and would cause additional overhead for your developers to keep this in sync. Simply ensuring that the package.xml that gets used by your build scripts includes the Account.object file will be enough.

Hope this helps!

Moving out of your Packaging Org. You will eventually reach a point where what you have extract is a unmanaged version of your package contents, which can be made to be compatible with a subsequent deployment back to your packaging org, which i'm guessing is what you have later in mind? I have done this before, when I've out grown developing in a packaging org, but rather I've done it with a view to populating a source control system and using that as the central definition of truth for my app.

Developer Workflow from Source Control. You can still use your sandbox orgs for your developers, but have them deploy using the Salesforce Migration Toolkit from your source control system. When your ready you can do a deploy to your packaging org from source control.

Validating Source Control Contents. Note that you can extend this to a continue integration build approach and effectively use the test deploy aspect of the toolkit to confirm your current state of source control is compatible with your packaging org (without actually committing to it until your ready).