SVN?

Yes, the tendency of some applications, even those notionally Subversion-aware like Xcode, to not preserve Subversion's working copy administration area directories .svn , is well known. It should not be beyond the wit of man to write a script to back these up after a fresh svn checkout or commit...



This email, including any attachments, is confidential and intended solely for 
the person or organisation to whom it is addressed. If you are not the intended 
recipient you must not disseminate, distribute or copy any part of this email 
nor take any action in reliance on it.

If you have received this in error please notify the sender immediately by 
email or phone +44 (0)1702 426400 and delete this email and any attachments 
from your system.

Email transmission cannot be guaranteed to be secure or error-free as 
information could be intercepted, corrupted, lost, destroyed, arrive late or 
incomplete, or contain viruses. The sender therefore does not accept liability 
for any errors or omissions in the contents of this message which arise as a 
result of email transmission. If verification is required please request a 
hard-copy version.

OneStep Solutions LLP is registered in England and Wales under registration 
number OC337173 and has its registered office at 457 Southchurch Road, 
Southend-on-Sea, Essex SS1 2PH.

Attachment: wcaa.sh
Description: application/applefile

Attachment: wcaa.sh
Description: Binary data



Our experiences here are mostly that Subversion will initially report files managed via a missing .svn directory as obstructed (~), then subsequently reconstruct that .svn directory's contents, but reconstruct it wrongly. Once this has happened, it can be difficult to establish which directories have been damaged, and which haven't. If you need to resort to repair damaged Subversion metadata in a working copy, a sensible procedure might be:

check out another entirely separate copy
run wcaa.sh against that new copy (or a better script you have written to do the same job) to generate a backup of all .svn directories wipe out all .svn directories in your working copy: find . -name .svn -type d -print -prune -exec rm -rf {} \; use the backup made against the new copy to regenerate the .svn directories and contents

At this point, you will have all the managed files in your working copy, untouched, with any any additions, deletions and modifications preserved Any uncommitted changes such as marking a file as added or deleted will have been lost and will need to be done again
But the 'hosed' condition will have gone away.

On 8 Jun 2011, at 05:12, Q wrote:


On 08/06/2011, at 9:09 AM, David Avendasora wrote:

Hi,

I just renamed a component's .wo directory in the Mac OS X Finder, and Eclipse renamed all the component files inside while I watched in the Finder! Wow! When did that happen? Very cool.

I added this a few years ago. :)

I've always used Wolips' Refactor -> Rename WOComponent function.... which is now broken because the files are getting renamed automatically while the refactor is trying to do the same.

Hmm, if it doesn't work then it hasn't worked for a very long time. I will have a look at it and if it it's not a simple fix I might just remove the refactor menu item because a regular eclipse "Rename..." should just work.

I like the finder rename feature better!

Cool hey :) But don't do that if you are using SVN or you will screw up your svn metadata... but you worked that out already didn't you. Git on the other hand... ;)

---
Regards Patrick
OneStep Solutions (Research) LLP
www.onestep.co.uk




This email, including any attachments, is confidential and intended solely for 
the person or organisation to whom it is addressed. If you are not the intended 
recipient you must not disseminate, distribute or copy any part of this email 
nor take any action in reliance on it.

If you have received this in error please notify the sender immediately by 
email or phone +44 (0)1702 426400 and delete this email and any attachments 
from your system.

Email transmission cannot be guaranteed to be secure or error-free as 
information could be intercepted, corrupted, lost, destroyed, arrive late or 
incomplete, or contain viruses. The sender therefore does not accept liability 
for any errors or omissions in the contents of this message which arise as a 
result of email transmission. If verification is required please request a 
hard-copy version.

OneStep Solutions LLP is registered in England and Wales under registration 
number OC337173 and has its registered office at 457 Southchurch Road, 
Southend-on-Sea, Essex SS1 2PH.
 _______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list      (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Reply via email to