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

Re: Checking out to a SVN directory

From: Keven Ring <keven_at_mitre.org>
Date: 2004-09-08 17:37:02 CEST

Edward Diener wrote:

>Thanks, but svn:externals will not work for me. Depending on the user, I
>want a particular local subdirectory to point to a particular repository
>path. Furthermore the repository path will be on a different repository than
>the top-level directory. As I understand svn:externals it sets the
>particular subdirectory to point to a particular repository path for all
>Here is the practical case with which I am working. First, for whatever
>reason, in my place of work we are using svnserve rather than httpd, so we
>do not have the fine-grained access control which httpd provides per
>repository path. I want to be able to check out from a repository path and
>then, for a particular subdirectory of the local directory to which I check
>out my files, switch to a repository path on another machine based on the
>user. This is all being done programatically ( Pysvn ).
>Why do we need to do this ? Because we need to provide access to specific
>files of the same name in a subdirectory based on the user. So if I have a
>subdirectory called 'conf' and a file called 'topsecret', I want user A to
>get 'topsecret' from a path on repository X and user B to get 'topsecret'
>from a path on repository Y. In no instance should user A and user B be able
>to access files on a repository for which they do not have permission.
>The only way I can think of doing this is that after the initial checkout,
>remove the .svn directory in 'conf' and then do a checkout from the correct
>path in the second repository. Given that this can practically be done I
>hope that when updates and commits are done recursively from the original
>top-level checkout directory that svn is mart enough to work with two
>different repositories at the same time.
Based on your description, the "conf" directory exists in at least 3
main repository
User A's repository
User B's repository

Unless the 'conf' directory in the main repository contains files that
are common to all users (as opposed to the "topsecret" file that is
unique for various users), why have the "conf" directory in the main
repository to begin with. Then, you aren't deleting the .svn directory
within "conf" that was created during the initial checkout of the main
repository, and everything else *should* work the same.

If the conf directory in the main repository does contain common files,
then you are in a bind, unless you can change your structure to
something like:

or similar.

The other option that *might* be do-able (although potentially quite
tedious) would be to provide externals from the User repositories back
to the "common" repository. Then, a user checks out their *private*
repository, and magically obtains the common stuff.

Unfortunately, neither of these two solutions will allow you to
recursively commit or update, since svn:externals are not followed (as
pointed out by Lee), and neither are different checkouts.

I would defer to someone else as to whether your solution (delete the
conf/.svn directory, and re-checkout from a different repository) would
have the desired effect. On the surface, it might, because the conf
directory itself would be listed as being under version control (in the
main repository), but the entries that are under version control in the
conf directory belong to either User A or User B's repository. Given
that you already effectively programmatically checking files out, it
shouldn't be hard to do...

Keven Ring               | "Oh no,  Not Again..."
The MITRE Corporation    |   Bowl of Petunias -
7515 Colshire Drive      |   The Hitchhikers Guide to the Galaxy
McLean VA 22102-7508     |
PH: (703)883-7026        |
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Sep 8 17:37:37 2004

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.