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

Re: Alternate Meta-folder Names for Mixing WC's

From: Ryan Schmidt <subversion-2009b_at_ryandesign.com>
Date: Thu, 17 Sep 2009 01:08:51 -0500

On Sep 16, 2009, at 22:16, user2037_at_ymail.com wrote:

> Often one has a repo for versioned code and one for config. There
> may even be another for content. Yet checking out overlapping
> working copies won't work since all use ".svn" folders.

I can't imagine why you would need overlapping working copies. There
is most likely a better way.

> If the meta-folder names could be customized then overlapping
> working copies would be possible. A switch, environment variable, or
> even just a sym-link to the Svn binary under a different name are
> all viable means. My preference is to use ".[argv-0]" and/or a
> switch like "--meta .mysvn". With the switch one could even notify
> Svn there are multiple WC's involved.
> Of course moving or deleting mixed folders is a problem unless each
> command is aware of all the WC's. Consolidating all the scattered
> meta folders under a single, root folder like Git or Bazaar may help.

I do not know how Git or Bazaar do it, but I do know that the working
copy code in Subversion is being rewritten, and I believe one goal is
to consolidate the metadata. This should happen for Subversion 1.7.0.
You can read more by searching for "wg-ng".

> While ensuring atomic commits across multiple repo's would be nice
> it is usually not required. And doing so would mean the server has
> to have a two-phase commit mechanism. Without this feature the
> servers wouldn't even need to know the client is mixing WC's. So no
> server changes should be needed.

I don't think you're going to get any support for atomic commits to
multiple repositories out of Subversion.


To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-09-17 08:10:20 CEST

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.