[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: experiment to get Mac resource-forks under version control [with PATCH]

From: Nicholas Riley <njriley_at_uiuc.edu>
Date: 2003-05-14 08:38:03 CEST

On Tue, May 13, 2003 at 09:43:29PM -0400, Scott Collins wrote:
> I wanted to get general opinions on whether I'm on the right track.
> This code is in no way ready for prime-time. Checkout doesn't work,
> because I don't have sufficient grasp of the order of operations in a
> checkout (or, I guess, file installation in general) to make sure my
> reflection code is hooked up in the right place. I use the properties
>
> svn:resource-fork
> svn:wc:last-resource-reflect-time
>
> My tests aren't really tests yet, I just wanted to make sure I could
> build tests and get them executed.
>
> Is this approach a fit for subversion's architecture? Is there a
> better way?
>
> Am I hooking in in the right place?
>
> Should I be using properties like this? Is it right to use a wcprop
> here?

I'm doing the same thing with a shell script wrapping svn (using a
slightly different property since I didn't feel I could usurp the svn:
prefix). Your changes look a lot more, uh, robust. I also save and
restore type and creator in properties, but none of the Finder flags.

But going forward, I think Subversion's lack of support for opaque
collections (*duck*) will be a bigger problem on OS X. It's been on
my long-term list to do something about this, but I doubt it will
happen any time soon.

-- 
=Nicholas Riley <njriley_at_uiuc.edu> | <http://www.uiuc.edu/ph/www/njriley>
        Pablo Research Group, Department of Computer Science and
  Medical Scholars Program, University of Illinois at Urbana-Champaign
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed May 14 08:38:56 2003

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.