-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Why don't you just prepare a webpage listing the repo URIs? Could be an
aspx page to scan the filesystem if you don't want to manually maintain it.
As listing repos isn't strictly a VM task chances might be low to get
such features into SVN. Wasn't there a lengthy discussion about that not
long ago?
Greetings,
M
Jeff Cave schrieb:
| -----Original Message-----
| From: John Peacock
| Sent: Monday, May 03, 2004 12:50 PM
|
| Thanks, I was starting to think I was going to be ignored with this one.
|
| My thoughts and reasoning. Let me know if I am out to lunch on anything:
|
|
|>OR, you could actually use the protocol intended for this purpose and
set up
|>Apache and use SVNParentPath (since this will work find with 'svn ls'
as you
|>want to use it).
|
|
| Unfortunately, installing a web server other than IIS is not an
option. Not my call.
|
| This does remind me that there was some talk about "Active
Directories" in Windows (about a year ago). I don't think this is
directly related, but I will try to find that thread to see what it was
discussing. I think it was more discussing accessing Apache based
repositories through windows.
|
|
|>This is where you are causing your own problems. svnserve does not
include
|>anything like SVNParentPath (like the Apache module does). Although that
|>wouldn't work either, since you are setting up two directory layers above
|>the actual repository (SVNGrandParentPath???).
|
|
| In terms of svn actually knowing what the Grandparentpath is, its not
really a big issue from the user standpoint. I don't actually want it to
do anything with the directory except report that it is there when I am
above it:
|
| Don't care to see:
| svn ls svn://server/comp1/proj1/branch/../../../
|
| Do care to see:
| svn ls svn://server/
|
| So unless you mean that svnserve will actually have problems
processing "svn://server/comp1/proj1" (which is a valid repo), I am
still happy with our current configuration. From what I have seen this
is not a problem, svn simply reports parent folders as "no repository
found" (fair enough).
|
|
|>svnserve does not include anything like SVNParentPath
|
|
| svnserve doesn't, but it doesn't need to.
|
| I guess it might have been useful to also mention that once a copy is
checked out, I don't care what it's path to repo is. That can be looked
up from within the working copy (if it is at all necessary). What I am
concerned about is determining which repo I want to checkout. svn
stores the full path to what it checked out. I am concerned with
determining what to checkout. Not where a checkout came from (I can
already do that).
|
| Am I making sense? That looks a little confusing to me.
|
|
|>What I'd recommend is that you have a single repository per company;
this is
|>also good if the projects should ever need to share any portion of
their code
|>(common libraries). The way you have organized it makes it much more
difficult
|>to do that.
|
|
| This scenario does come up, but in that case they are considered one
project (with sub projects). For example:
|
| comp
| |
| +- acct <------------| This is a repository
| |
| +- web
| | }
| +- manage }
| | } | These are sub applications
| +- db } <-----| that are being developed
| | } | for them
| +- field }
| | }
| +- sales
|
| An example of a case where I am really interested in keeping the
projects seperate is where we write some internal accounting software
for the company, maintain their company website, and maintain networking
security policies/scripts/stuff (I'm not a networking guy, I don't know
what they keep track of).
|
| To use the above example:
|
| comp1
| |
| +- acct
| |
| +- web
| |
| +- netcfg
|
| In that case, their network configuration is completely unrelated to
the source code of their accounting software. Just as the website
(listing products and services is completely unrelated to their internal
network configuration.
|
| While it is not absolutely necessary to keep them seperate, it would
be nice (network guys stay oblivious to website changes).
|
|
|>What you do from there is up to you; if you have completely internal
|>repositories (i.e. not on the public Internet), I would actually
suggest setting
|>up independent svnserve instances for each company's repository:
|>
|> svn://svn-company1
|> svn://svn-company2
|> svn://svn-company3
|> svn://svn-company4
|>
|>which could still be the same box, but with different svnserve
instances bound
|>to different IP addresses.
|
|
| This would bring me closer to what I am looking for, but suffers from
most of the same problems.
|
| An user must know the url/ip of a company to access the repo (as
opposed to the directory name). And then still have to know the project
directory name.
|
| (Under line indicates what user must know to access project)
|
| Current: svn://ip/company/project/
| ^^^^^^^^^^^^^^^
| IP per Company: svn://ip/project/
| ^^^^^^^^^^
|
| The real advantage I see here would be in opening the repositories to
key employees at our client's offices, which has been known to happen
from time to time. (Does this really help with that? Hmmm.. I'm not
sure.. maybe not. I have to think about that).
|
|
|
|
| BTW:
|
| I did have someone here point out that there might be a problem with
svn indicating which folders are repositories and which aren't. I admit
that this would require a visual flag of some kind (like a star or label
next to the folder name):
|
| $> svn ls svn://server/
| comp1/ (NR)
| company2/ (NR)
| comp356/ (NR)
|
| $> svn ls svn://comp1/proj1/
| branch/
| tag/
| trunk/
|
|
| ---------------------------------------------------------------------
| To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
| For additional commands, e-mail: users-help@subversion.tigris.org
|
|
- --
/********************************************************************
~ visit http://www.quanten-dilettanten.de/
~ Thanx, the "GR_FRameRAM8" is much more elegant than a mere "19",
~ naturally.
~ Infos zur Verschlüsselung mit OpenPGP http://www.gnupp.de
*********************************************************************/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFAl2BhXjHhiL8/upYRAkc6AJ4mob1xKSUGnDh0Y9A3i6GfotfkCQCgofzy
3oV3qv7V3VCr3bzgl1l5iI0=
=E3SE
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue May 4 10:21:30 2004