That is extremely interesting... I wouldn't have any idea why it's complaining about the file already existing. Are you branching with an option-drag inside Versions? Does the same thing happen if you try it from the command line?

 - Quinn


On Jun 4, 2009, at 6:57 AM, Robin Charlton wrote:

Interesting.

If I branch and then attempt to commit the new revisions the following error is reported: Commit failed (details follow): File '/demos/branches/ Galactica_Maintenance/Source/Applications/DiceMan/DiceMan.xcodeproj/ project.pbxproj' already exists

Since this is a new branch there's no possible way that file could exist.

All advice gratefully received!
~
Robin | [email protected] | twitter: robincharlton


2009/6/4 Quinn Taylor <[email protected]>
Actually, probably not. Xcode is "SVN-aware", so it doesn't clobber the .xcodeproj directory at all, only update the files therein. The only file in that bundle that I store in the repository is project.pbxproj — any other file starts with a username and is specific to that user, and should usually be excluded. (Such files frequently change, have no bearing on the actual project, and tend to crud up the repository and commits with irrelevant files and changes.)

What specific problem is being reported? What are the filenames that are claimed to already exist, and do they in fact exist?

 - Quinn


On Jun 4, 2009, at 2:22 AM, Robin Charlton wrote:

I suspect this explains the weird problems I've experienced with XCode project files (which are also bundles). Versions (or rather SVN) often doesn't recognise them as being in the repository and/or complains that 'they already exist' when trying to submit.
~
Robin | [email protected] | twitter: robincharlton


2009/5/22 Quinn Taylor <[email protected]>
This is a common problem with bundle directories, and one that is still unsolved (at least, in the ideal way) for Subversion. The workaround is to archive the app bundle in a ZIP or similar file and store that in the repository, unfortunate as that is. However, storing app executables in Subversion is generally not the best idea. If you can build it from source, any revision is sufficient to reconstruct the binary at any point in time. This may not fit every scenario, but it's a good rule of thumb.

 - Quinn

Attachment: smime.p7s
Description: S/MIME cryptographic signature

Reply via email to