Re: updating rmcl via svn

Gary,

I renamed my old RMCL directory before starting the svn, but I still
got the post-checkout errors described.

Henry

On Mon, Sep 14, 2009 at 5:24 PM, Gary Byers <[email protected]> wrote:
> Until about a week ago, the mechanism that the "post-checkout.sh" and
> "pre-commit.sh" scripts used to join/split resource forks was based
> on some obscurely-named Apple utilities; the utility that joined forks
> together just recursively walks a directory, looking to join ._foo and
> foo into a single file with a resource fork and HFS metainfo.
>
> That utility descended into .svn directories and got confused by
> what it found there; it printed a bunch of confusing messages, but
> didn't seem to actually modify the files in **/.svn.
>
> While working on RMCL under Snow Leopard, I noticed that svn started
> claiming that I'd changed some of the files that have resource forks
> when I hadn't; apparently, the Snow Leopard version of that utility's
> been improved to clobber things in .svn directories.
>
> I changed the scheme used to maintain resource forks in SVN to avoid
> this problem; unfortunately, I missed the fact that the old scheme
> uses "extended (file) attributes" in a way that the new scheme doesn't
> deal with correctly.  If your working directory was initially checked
> out before this change and then updated, you'll get the kind of
> diagnostic messages that you described.
>
> If you do a fresh checkout (so that the old extended attributes aren't
> involved), things seem to work correctly.  If you have a working directory
> that contains the old-style attributes, then it seems to work to remove
> them before invoking the post-checkout.sh script:
>
> $ xattr -r -d com.apple.ResourceFork *
>
> (And watch in mild horror as another Apple utility wanders around .svn
> directories and complains about what it finds there.)
>
> This change in the scheme used to maintain resource forks was made to
> both the trunk ("5.1b1") and 5.2 versions and may affect anyone who had
> a working copy of either version.
>
>
> _______________________________________________
> info-mcl mailing list
> [email protected]
> http://clozure.com/mailman/listinfo/info-mcl
>
_______________________________________________
info-mcl mailing list
[email protected]
http://clozure.com/mailman/listinfo/info-mcl