RE: svn ls - could it list non repo directories?

-----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
Received on Mon May 3 23:59:31 2004