I am a mac user and I, like many of us, are struggling with Apple's
'bundles as directory' decision and working with svn to manage them.
I have read r707 and some other discussions on this, and I think I
understand the main issues. Most everyone seems to be focused on
getting opaque items to be treated as a single object under SVN. Of
course, this brings lots of work, since that approach is fundamentally
changing parts of the SVN design.
I am curious if folks would find a different path acceptable. My big
problem is that several of my applications do not like the addition of
files within their bundles, notably the .svn file is a big issue, and
I think by solving that, we may be able to also get something like
transaction-like commits, updates, etc for the bundles as part of the
solution.
So, my basic idea is to change SVN on the client side to allow for an
alternative path to the meta data (apmd) for specific files. A
directory can have APMD enabled by creating a property svn-apmd: for
that directory. When a bundle is added under a directory with APMD
enabled, the the .svn file for the directory is put in the .svn
directory of the parent. This behavior is followed for files and
directories under the APMD path, so the
So, for a directory that looks like
./dir
./dir/bundle
./dir/bundle/part-1
./dir/bundle/part-2
./dir/bundle/sub-bundle
./dir/bundle/sub-bundle/part-3
And one that has apmd enabled on 'dir'
The SVN parts looks like
./dir/.svn
./dir/.svn/bundle/.svn
./dir/.svn/bundle/sub-bundle/.svn
When a client tries to work within a bundled directory, it will need
to reference the APMD directly, but that should be infrequent, since
the client will likely work at a level where the APMD information is
automatically determinable via the svn properties and context. Thus,
recursive updates and recursive commits, and recursive adds should
work 'like normal'. As new items are added/removed from the bundle,
the svn tools could be used to support their addition/removal without
substantial changes in the SVN codebase (and there are no client-side
scripts to keep in sync like the tarball scripts).
Before I start thinking about this approach any more, I wanted to get
feedback from the SVN folks to see if this approach might be
acceptable as an SVN option.
Any and all feedback is greatly appreciated.
Charlie
Charles Woloszynski
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Feb 3 20:26:38 2007