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

Re: Proposal: generic svn:encoding mechanism

From: David Anderson <david.anderson_at_calixo.net>
Date: 2005-08-03 23:37:19 CEST

> [snip explanation]

Thanks for taking the time to explain this to me. Okay, so now I can
somewhat see the issue you are trying to address in your proposal.

In the light of this, I see your proposal as actually being a specific
case of the elusive client-side hooks. I for one would prefer to have
client-side hooks, which have approximately the same problems to solve
as your proposal, but allow for much greater flexibility. The MacOS fork
problem would then be handled by a single script, that works by
consulting svn properties. This would avoid entering code in the
subversion codebase that is *really* specifically geared towards the
support of a specific MacOS fs feature.

> Well, today I can't store such files in SVN at all. I see that as a
> much more serious problem.

Point taken. In the light of your explanation of resource forks, I can
understand this.

> Because I have files that are >1GB uncompressed and less than 1MB
> compressed. (In my case, these are test files that consist primarily of
> zero bytes.)

Can't you store the script that generates these files, rather than the
generatees? (not related to the actual discussion of the proposal, I'm
just thinking aloud)

So, overral, I think this is a recurring problem in the svn development
(resource forks that is). The classic solution to this is client-side
hooks, which were always shunned (can devs who took part in those
discussions elaborate?). Although your solution is interesting, I still
find it of relatively little interest to users of systems other than
MacOS, whereas client-side hooks could be used for things beyond this
scope (I can remember people wanting to run automagic code munging on
commit?). But that's just me, perhaps the implementation of this
property handling would be less time and resource consuming in the eyes
of the devs.

- Dave.

To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Aug 3 23:39:32 2005

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

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