Tagging working copy, Commit failed: File already exists

When attempting to create a tag of a working copy we receive the error, Commit failed: File '' already exists.

In attempting to diagnose the issue and have identified the following convoluted re-creation scenario.

We have a staging environment used for testing and QA rel开发者_Python百科eases. Development is never done on the staging environment and the builds are done from SVN checkouts.

A full checkout is done in the staging environment and it goes through a QA cycle. Bugs are resolved in dev environments and then single files are updated in the staging environment.

When the release is ready to be tagged in the staging environment the tag command fails with Commit failed: File already exists.

This issue can be resolved by completing an SVN update on the entire directory but this is not ideal when there is new code that is not intended to be tagged.

Has anyone else experienced or have a solution? Are we completely using SVN wrong?

We use Tortoise SVN for working in our repository but also have the command line tools

You are attempting to commit (tag) a mixed revision. You cannot do this.

See this SO question

When you do your staging server check out you should branch it into a "release" branch. Tag it as RC_version_1

Then you work on that branch to get it ready. Bugs are resolved in this branch (and merged back into trunk so you don't get any bugs creeping back in, very important that bit). Then you can do a SVN commit from your staging server (or infact any machine if its using this branch as its working copy).

Thats the way we do it anyway. Future bug fixes after the release have gone live can be done again to this branch, just tag each release (thats where your version number at the end of the tags comes in handy). We have just one release branch which we keep releasing off so don't really have a release candidate (RC) number just version numbers. Each time we upload a site we tag it with a new version number. We are working on automating this though to make it a bit more idiot proof.

Hope that helps

It sounds like more SVN-like way of doing what you're doing would be for your "staging environment" to be a separate branch. The QA team does their day-to-day work on that branch and developers do their day-to-day work on the trunk. As the developers fix bugs that need to be added to the QA cycle, they merge them into the QA team's branch.

This way, the QA team's working copy stays in sync with the repository, rather than drifting away. They don't need to fear the svn update command, because in order to integrate a change, someone has to explicitly merge it from the trunk to the QA branch.

Once the QA cycle is complete, you can just copy from the QA branch to the desired tag.

By the way, I would suggest you do your tags/branches directly on the repository, rather than on working copies. This way, you can avoid the overhead of copying all those files on the local filesystem.