My apologies for another batch response:
On Aug 11, 2008, at 2:09 AM, Karl Fogel wrote:
> The sole and only issue here, as far as I can see, is the additional
> complexity this would put in the Subversion core code.
>
> I do wonder if, instead of maintaining a custom patch, it might make
> more sense to maintain a script that wraps svn and DTRT with such
> bundled directories.
When I wrote the first implementation a while back, I looked at the
pre- and post-commit hooks, as well as the asvn script to see if it
would be possible to manages resource forks outside of the svn code
base. However, they would rely on tools (SplitForks) that are not
installed by default on the system before 10.5, and the svn-book warns
not to modify the transaction from hook scripts -- such as setting
properties during the commit.
On Aug 11, 2008, at 10:28 AM, Julian Foad wrote:
> Good question. My personal feeling is that we SHOULD be willing to
> have
> some features like this that support OS filesystem features, and also
> that each addition of such a feature should improve the modularity of
> the implementation for such features. I expect the existing support
> for
> svn:executable and symlinks is rather tightly tied in to low-level
> code,
> and we should endeavour to uncouple it a bit and make sure that any
> new
> code like this AppleDouble feature is not too tightly mixed in with
> everything else, as far as we can. If we decide that the best
> (maintainable) way to do this is to have a wrapper layer around
> Subversion, then
I used the svn:executable implementation as the model for mine, which
indeed required touching the source base in many places. If the core
were updated to better support such platform-specific features in a
single place, it would definitely make such changes easier in the
future. However, that discussion is beyond my pay-grade. :)
On Aug 11, 2008, at 11:24 AM, Peter Samuelson wrote:
> OTOH, this file is purely "interfaces", which, being pure factual
> information, can't be copyrighted at all in some jurisdictions as
> there
> is no creative input. Therefore it _may_ be acceptable to simply file
> off the serial numbers (i.e., rewrite the comments and change the
> #define constants) and call it good.
Definitely. We don't need 90% of the data in that header for the
conversion, so declaring a couple structs and constants may just be
simpler overall.
Matt Slot / Bitwise Operator / Ambrosia Software, Inc. -- http://www.AmbrosiaSW.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-08-11 21:21:33 CEST