Kevin Ballard wrote:
> >>> So what you're asking for is purely client-side stuff... therefore
> >>> maybe
> >>> this could all be done in a wrapper script around the "svn" command.
> >
> > Well, it sounds like you're asking for 'svn' to implement what is
> > essentialy that exact same functionality, just within the 'svn'
> > binary itself instead of in a wrapper script... not sure that would
> > make it any less "hackish"...
>
> What you're asking me to do is write a wrapper that recurses into every
> directory tree rooted at the modified files/dirs and write to each
> affected property, do the action, then recurse back into every one and
> reverse that property modification. That's a lot of work and seems like
> it would extremely slow. What I'm asking is for a certain prefixed
> property to simply not be committed to the repo, as well as when using
> the special svn: properties to simply take a look at the relevant
> local:svn: property as well. It would be a lot more efficient and
> probably easier to do than what you're asking.
Yes, you are right about all that.. I'm just asking the underlying
question: where does "core" svn functionality stop and "custom"
client side functionality start? Not that my opinion counts for much,
but this feature seems like a good example of being on the "borderline".
I.e., it's a useful idea, but does it belong in the "stock" svn
binary? After all, there's nothing stopping somebody from writing
a "super-svn" binary based on "svn" that includes extra features
like this... it would be nice to see people doing creative stuff like
that, so we'd get some good "feature competition"...
-Archie
__________________________________________________________________________
Archie Cobbs * CTO, Awarix * http://www.awarix.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Sep 29 18:01:18 2004