There's bit a lot of talk this week about a libsvn_wc redesign which
puts all metadata in a central location anyway. You may want to take
a look at that, since it would solve the bundle-smashing problem.
On 2/3/07, Charlie Woloszynski <cwoloszynski@gmail.com> wrote:
> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Feb 3 22:13:58 2007