Serious incompatibility between Subversion and Metrowerks CodeWarrior

This is on Mac OS X 10.4.2. I suspect I should post to the dev list,
but I thought I'd start here.

We just switched to Subversion source control. I just lost quite a
bit of work due to a serious problem using Subversion (svn) with
CodeWarrior. I'd like to describe what's happening, and get some info
about how Subversion commits files.

Follow these steps (mentally if you don't have CW installed):

1. Open a source file under Subversion control in CW 8.3 or 9.4.
2. Make a minor change to the file. Save, but do not close the window.
3. Commit it to the repo (svn commit).
4. Go back to CW and make another minor change.
5. Save. Note that no error indication occurs.
6. Close the window
7. Re-open the file. Not that your second set of changes is not present.

svn commit seems to delete the old file and create a new one, as
evidenced by the inode reported by ls -i changing.

CodeWarrior seems to keep a file open via it's file descriptor, and
so it doesn't notice that the old file went away. However, I'm not
sure why it doesn't report an error when one attempts to save (and
internally, why id doesn't get that error, find and re-open the file,
and save its current contents to the new file).

Note that performing the same steps above with TextWrangler results
in the file being properly handled, no lost data. It even notices
that the file's been modified and reads it back in. If you've made
changes, it even says "[The file] was changed on disk, but could not
be reloaded because it has unsaved changes.

Now, perhaps CodeWarrior needs to do a better job of keeping track of
files. Obviously, the problem can be dealt with, as demonstrated by
TextWrangler.

I checked out the subversion source and tried to figure out just
where it creates the new files during a commit. Mac OS X (Darwin)
supports exchangedata(), a way of doing safe saves of data and
keeping the same file ID, so that open file handles don't totally
disconnect (and all atomically). I don't think any other Unix does
this, but I suspect there's a workaround that would be good. I think
svn first puts the new pristine copy in the .svn directory, then
modifies the working copy by creating a new one and deleting the old
one. Maybe it could instead open the old wc, truncate it, and write
the new data out.

The next save in CW would immediately overwrite it, but at least it's
buffers wouldn't go into a black hole.

Any suggestions? Thanks!

-- 
Rick
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org