subversion "out-of-date" question

Question

I'm using subversion so that I can have two checkouts, one for testing to make sure things work and another which is public live site. I made some changes in the test site but also made some updates to a wordpress install. Now I can't commit the changes on my live site.

[phil@sessions public_html]$ svn commit -m "this time, it's personal"
svn: Commit failed (details follow):
svn: Working copy
'/usr/local/apache/sites/nextadvisor_admin/blog/wp-content/plugins' is
missing or not locked

so I...

[phil@sessions public_html]$svn rm blog/wp-content/plugins --force
[phil@sessions public_html]$svn rm blog/wp-content/plugins --force
[phil@sessions public_html]$svn add blog/wp-content/plugins --force

and all the files got re-added, then I

[phil@sessions public_html]$ svn commit -m "this time really"
Sending        blog/.htaccess
Replacing      blog/wp-content
svn: Commit failed (details follow):
svn: Out of date: '/trunk/blog/wp-content/plugins' in transaction '186-1'

Okay so when I look online it tells me to do svn update but I tried that once before and it just erases all my local changes because the "blog/" folder doesn't exist in my test checkout.

My question is, how can I make this commit work without losing the local edits?

Update:

When I run svnupdate, it tells me:

svn: Working copy path 'blog/wp-content/plugins' does not exist in repository

Answer 1

If things are out of date, you first have to do a svn update before you can commit. svn update won't overwrite any files that have changed locally. Although you claim that this is the case, it's not, because subversion doesn't do that.

However, your workflow is going to be always causing problems because you're always going to be working against the way subversion was designed to work. Any time you find yourself using the --force flag during the normal course of events, it's a sign that you're not working with the tool, you're fighting the tool.

For what you want to do, you're much better off creating a branch and doing your dev work on the branch. Then, when you're ready to go live, merge the dev branch onto the trunk and update your live checkout.

In addition, you should never be committing changes on the live site. That's what your test site is for. The live site should be considered to be a read-only checkout.

Answer 2

• Save your locally modified files to a copy.

• perform an svn update

• Copy your changed files back over the 'svn updated' versions

• do the commit.