Bundles, Opaque items, and a possible path forward

[Charlie Woloszynski <cw...@gmail.com>]

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

Re: Bundles, Opaque items, and a possible path forward

[Ben Collins-Sussman <su...@red-bean.com>]

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 <cw...@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