You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Marc <su...@advantex.net> on 2006/09/28 19:35:23 UTC

Creating more than one repo

Hi Everyone,

First, I have to say... Snv kicks major butt.  Thanks to everyone that has
made this software possible.

Now, for the newbie question... I checked the book, but just couldn't find
anything that matched my particular situation.

We're planning on using svn to practice good version control for our
websites.  I have successfully created a repository for a sample website,
and had two team members do a checkout, change some files, update and
commit.  

Upon each commit, the staging version of the website (which is simply a
working copy) is automatically updated, via a post-commit hook.  The live
site will be updated manually for now, and it is just another working copy
of the trunk, updated only after the staging site is confirmed bug-free.

I used TortoiseSVN to create the repository.  The repository is accessed by
the clients using svn://svn.domain.com/trunk.  I have an entry in dns for
svn.domain.com.

Now, I just created a SECOND website, and again set up a new repository on a
separate directory on the hard drive, again using TortoiseSVN. I wanted to
use svn://svn.domain2.com/trunk.  However, when I point the client to THAT
domain and trunk, I still get the FIRST repository I created.

We want each website to have its own repository.  I'm clearly doing
something wrong, since it appears that only the one repository is
recognized, no matter which repository I enter into the TortoiseSVN client.

Can someone point me in the right direction?

Thanks,

Marc

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Creating more than one repo

Posted by Mark <ma...@mitsein.net>.
On 9/28/06, George Georgalis <ge...@galis.org> wrote:
> On Thu, Sep 28, 2006 at 03:35:23PM -0400, Marc wrote:
> >
> >Now, I just created a SECOND website, and again set up a new repository on a
> >separate directory on the hard drive, again using TortoiseSVN. I wanted to
> >use svn://svn.domain2.com/trunk.  However, when I point the client to THAT
> >domain and trunk, I still get the FIRST repository I created.
> >
>
> I don't think the svn:// protocol works like the http:// protocol.
> With http the domain is actually part of the request, in addition
> to being used to resolve the IP. With svn:// the domain is only
> used to resolve IP. At that IP, trunk is trunk no matter what the
> domain is. you need a more complicated solution, I think.
>
>
> // George
>

Or a simpler one.  Just don't use a virtual domain for each repository.

-- 
Mark
"Blessed is he who finds happiness in his own foolishness, for he will
always be happy."

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Creating more than one repo

Posted by George Georgalis <ge...@galis.org>.
On Thu, Sep 28, 2006 at 03:35:23PM -0400, Marc wrote:
>
>Now, I just created a SECOND website, and again set up a new repository on a
>separate directory on the hard drive, again using TortoiseSVN. I wanted to
>use svn://svn.domain2.com/trunk.  However, when I point the client to THAT
>domain and trunk, I still get the FIRST repository I created.
>

I don't think the svn:// protocol works like the http:// protocol.
With http the domain is actually part of the request, in addition
to being used to resolve the IP. With svn:// the domain is only
used to resolve IP. At that IP, trunk is trunk no matter what the
domain is. you need a more complicated solution, I think.


// George


-- 
George Georgalis, systems architect, administrator <IXOYE><

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Creating more than one repo

Posted by Jeff D <fi...@gmail.com>.
Marc wrote:
> Hi Everyone,
>
> First, I have to say... Snv kicks major butt.  Thanks to everyone that has
> made this software possible.
>
> Now, for the newbie question... I checked the book, but just couldn't find
> anything that matched my particular situation.
>
> We're planning on using svn to practice good version control for our
> websites.  I have successfully created a repository for a sample website,
> and had two team members do a checkout, change some files, update and
> commit.  
>
> Upon each commit, the staging version of the website (which is simply a
> working copy) is automatically updated, via a post-commit hook.  The live
> site will be updated manually for now, and it is just another working copy
> of the trunk, updated only after the staging site is confirmed bug-free.
>
> I used TortoiseSVN to create the repository.  The repository is accessed by
> the clients using svn://svn.domain.com/trunk.  I have an entry in dns for
> svn.domain.com.
>
> Now, I just created a SECOND website, and again set up a new repository on a
> separate directory on the hard drive, again using TortoiseSVN. I wanted to
> use svn://svn.domain2.com/trunk.  However, when I point the client to THAT
> domain and trunk, I still get the FIRST repository I created.
>
> We want each website to have its own repository.  I'm clearly doing
> something wrong, since it appears that only the one repository is
> recognized, no matter which repository I enter into the TortoiseSVN client.
>
> Can someone point me in the right direction?
>
> Thanks,
>
> Marc
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
>   
are domain1 and domain2 seperate IPs?  If so, you can start svnserve  
like :
svnserve --listen-host svn.domain1.com -r /path/to/rep/ -d
svnserve --listen-host svn.domain2.com -r /path/to/other/ -d

or, run one server with with both repositories in the same area, like 
/var/svn/rep1 /var/lib/rep2 and use authz to grant access to either one.



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Creating more than one repo

Posted by Tom Mornini <tm...@engineyard.com>.
I didn't see the original email, but I just setup a system where the  
URLs are:

   http://repo.company.com/

and

   https://repo.company.com/

A domain wide SSL certificate will allow this without problem.

On an interesting side note, this system is run load balanced across  
several HTTP servers with FSFS repos on a Red Hat Cluster System GFS  
filesystem.

Working like a charm so far!

On Sep 29, 2006, at 10:07 AM, Kenneth Porter wrote:

> --On Thursday, September 28, 2006 6:00 PM -0400 Kris Deugau  
> <kd...@vianet.ca> wrote:
>
>> You'll have to do one of:
>>
>> -> Set up each site on separate IPs, so that services like SVN can
>> properly match access to different sites to the matching back-end  
>> data.
>> -> Switch to HTTP access (please note, not HTTPS, as that will  
>> just dump
>> you back where you started).  This is probably the best long-term  
>> option.
>> -> Rethink your repository structures so that you embed the  
>> repository
>> name in the svn:// url somewhere after the domain name part.
>
> Or run separate servers on different ports. (This would also  
> address the HTTPS limitation.) The downside is that you have to  
> explicitly specify the port in the URL.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Creating more than one repo

Posted by Les Mikesell <le...@gmail.com>.
On Fri, 2006-09-29 at 21:55, Tom Mornini wrote:

> > And at some point, I'm sure I'll need to reduce the amount of  
> > history for
> > each trunk... Is anyone else managing a single large repo?  At what  
> > point do
> > you decide to remove some of the early historical tags/trunk versions?
> 
> I don't even think there are ways of doing this. Disks are cheap, but  
> the ability to keep all history is priceless!

There are limits to everything and it is a good idea to understand
them instead of blindly hoping they won't ever be a problem
for you.  I've got a 10+ year old CVS repository that is still
around because it has been relatively easy to prune out the
junk.  We'll probably drop the history when moving the parts
we still support into subversion, but I don't foresee a happy
next 10 years unless subversion adds an easier way to get
rid of mistakes.  Keeping a few around to remind you not to
repeat them can be useful, but keeping all of your mistakes
forever just doesn't seem like the right approach.  The disks
themselves are cheap now, but the time to do backups and the
effort to manage offsite copies is not. 

-- 
  Les Mikesell
   lesmikesell@gmail.com


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Creating more than one repo

Posted by Duncan Murdoch <mu...@stats.uwo.ca>.
On 9/30/2006 9:49 AM, Marc wrote:
> Hi Tom,
> 
>     >   > Instead of putting our repositor(ies) on the hosting 
>     >   servers, and 
>     >   > hosting the repositor(ies), the staging sites, and 
>     >   the live sites, I 
>     >   > am going to move ahead with putting a dedicated 
>     >   repository server 
>     >   > right here in our office.  It will be a single 
>     >   repository, with a 
>     >   > trunk for EACH website for which we do the 
>     >   development work, and we 
>     >   > will stage the sites on our internal staging server.  
>     >   The live sites 
>     >   > will still be working copies of our local repository.
>     >   
>     >   For ease of deployment, I'd definitely recommend the 
>     >   repositories be hosted where they're available on a 
>     >   public IP address!
> 
> We do have a public IP, that's necessary of course.
> 
> 
>     >   Rather than working copies, I'd recommend exports, but 
>     >   to each his own...
> 
> I thought about that, too, but I seemed to be getting steered towards just
> working copies when I last brought this up.  If EXPORTS can be automated
> using post-commit hooks, then I can do that too of course.  What do you feel
> is better about exports... The lack of a .svn directory in the final site?
> 
> Another reason why we chose Working Copies as the website publishing method
> was because we can simply do an "update", and grab only those files that
> have changed, making for a fast, well, UPDATE of the site.  With exports,
> don't you get the whole codebase over again, each time?  For some of our
> sites, that could be a difference between sending up 4 or 5 specific files,
> or sending up the entire web application at 300+mb...

I use working copies in a similar situation, but I imagine there are 
ways to avoid copying the whole thing, using rsync, or a post-commit hook.


> 
>     >   
>     >   > My question to everyone is, does anyone see a problem with a 
>     >   > repository "this large"?  I mean, when we load up all 
>     >   our sites into 
>     >   > it, it's going to be HUGE.  And it'll just grow 
>     >   larger with the 
>     >   > revisions.  How large should it be allowed to grow?  
>     >   (server has 300GB 
>     >   > RAID 1 right now...)
>     >   
>     >   Subversion repositories grow quite efficiently, as it 
>     >   uses many methods to reduce storage space. There are a 
>     >   lot of repositories in the world with a *lot* of code 
>     >   in them (think Apache Software
>     >   Foundation) and no trouble.
> 
> Gotcha.  Very Very Cool.
> 
>     >   > And at some point, I'm sure I'll need to reduce the 
>     >   amount of history 
>     >   > for each trunk... Is anyone else managing a single 
>     >   large repo?  At 
>     >   > what point do you decide to remove some of the early 
>     >   historical 
>     >   > tags/trunk versions?
>     >   
>     >   I don't even think there are ways of doing this. Disks 
>     >   are cheap, but the ability to keep all history is priceless!
> 
> Disks are cheap, but the space available to put those cheap disks in is,
> plainly, a PITA.  We're repurposing a 2u rackmount server, and it holds a
> total of four drives, and the case is now full. Two mirrored OS drives
> (don't remember their size...), and two mirrored data drives, around 300GB I
> believe.  I should think this would be enough for us, to last a long time,
> considering our current server data drive will all the sites, apps AND
> documentation is only around 5.6 GB! ;)  We have additional sites on the
> live servers totaling at least another 20-30gb though, that we'll be pulling
> down.  
> 
> But adding more internal disks to this particular server is out of the
> question, obviously.  It looks like we'll be okay.
> 
>     >   
>     >   > Lastly... The server I was going to dedicate to this 
>     >   repository is 
>     >   > currently an unused FreeBSD server.  I'm still 
>     >   cutting my teeth with 
>     >   > FreeBSD, but know
>     >   > my way around okay.  Setting up subversion on Windows 
>     >   was a SNAP.   
>     >   > Given the
>     >   > size of the repository being proposed, I assume 
>     >   there's going to be a 
>     >   > lot of files, and we all know how well Windows deals 
>     >   with a lot of 
>     >   > files... But I definitely know Windows Servers 
>     >   better.  Should I leave 
>     >   > it as a FreeBSD server for the purpose of it being 
>     >   great with large 
>     >   > directories (and just great in general), or wipe it 
>     >   and put Windows 
>     >   > 2003 Server on it for the purpose of eliminating an area of 
>     >   > inefficiency for myself?  Will Windows pretty much choke on a 
>     >   > repository with 70 websites in it?
>     >   
>     >   Your call. I'd choose a *nix, and I'd suggest you'd be 
>     >   wise to do so, but not everyone will see it that way.
> 
> Can you still use TortoiseSVN from a client to use "Repo-Browser", to browse
> the repo that would be on the *nix server?  (I think I already know the
> answer, but if I am going to be a newbie, I might as well act like one ;)

Yes, the client platform is independent of the server platform.

Duncan Murdoch
> 
>     >   P.S. You haven't mentioned backup in your plans anywhere...
> 
> Yes, we've already planned for backups of the repo server...  They will be
> done over the LAN to a backup machine, and from there, out to a
> geographically separate storage area as well.
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

RE: Creating more than one repo

Posted by Les Mikesell <le...@gmail.com>.
On Sat, 2006-09-30 at 08:49, Marc wrote:

> Another reason why we chose Working Copies as the website publishing method
> was because we can simply do an "update", and grab only those files that
> have changed, making for a fast, well, UPDATE of the site.  With exports,
> don't you get the whole codebase over again, each time?  For some of our
> sites, that could be a difference between sending up 4 or 5 specific files,
> or sending up the entire web application at 300+mb...

You'd probably want to export to a local test/staging area, then
run a scripted rsync to the real server(s).  Rsync is probably
even more efficient at updating differences to remote files.
Or you could rsync from a local working copy, excluding the
.svn directory, but if you do that you should be careful to
make a tag and update from the tag or something similar in
the script to be sure that what you publish is actually a
known version in the repository.

-- 
  Les Mikesell
   lesmikesell@gmail.com




---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

RE: Creating more than one repo

Posted by Kenneth Porter <sh...@sewingwitch.com>.
--On Saturday, September 30, 2006 9:49 AM -0400 Marc 
<su...@advantex.net> wrote:

> Can you still use TortoiseSVN from a client to use "Repo-Browser", to
> browse the repo that would be on the *nix server?  (I think I already
> know the answer, but if I am going to be a newbie, I might as well act
> like one ;)

Not only that, but you could install TRAC or another web-based repo browser.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

RE: Creating more than one repo

Posted by Marc <su...@advantex.net>.
Hi Tom,

    >   > Instead of putting our repositor(ies) on the hosting 
    >   servers, and 
    >   > hosting the repositor(ies), the staging sites, and 
    >   the live sites, I 
    >   > am going to move ahead with putting a dedicated 
    >   repository server 
    >   > right here in our office.  It will be a single 
    >   repository, with a 
    >   > trunk for EACH website for which we do the 
    >   development work, and we 
    >   > will stage the sites on our internal staging server.  
    >   The live sites 
    >   > will still be working copies of our local repository.
    >   
    >   For ease of deployment, I'd definitely recommend the 
    >   repositories be hosted where they're available on a 
    >   public IP address!

We do have a public IP, that's necessary of course.


    >   Rather than working copies, I'd recommend exports, but 
    >   to each his own...

I thought about that, too, but I seemed to be getting steered towards just
working copies when I last brought this up.  If EXPORTS can be automated
using post-commit hooks, then I can do that too of course.  What do you feel
is better about exports... The lack of a .svn directory in the final site?

Another reason why we chose Working Copies as the website publishing method
was because we can simply do an "update", and grab only those files that
have changed, making for a fast, well, UPDATE of the site.  With exports,
don't you get the whole codebase over again, each time?  For some of our
sites, that could be a difference between sending up 4 or 5 specific files,
or sending up the entire web application at 300+mb...

    >   
    >   > My question to everyone is, does anyone see a problem with a 
    >   > repository "this large"?  I mean, when we load up all 
    >   our sites into 
    >   > it, it's going to be HUGE.  And it'll just grow 
    >   larger with the 
    >   > revisions.  How large should it be allowed to grow?  
    >   (server has 300GB 
    >   > RAID 1 right now...)
    >   
    >   Subversion repositories grow quite efficiently, as it 
    >   uses many methods to reduce storage space. There are a 
    >   lot of repositories in the world with a *lot* of code 
    >   in them (think Apache Software
    >   Foundation) and no trouble.

Gotcha.  Very Very Cool.

    >   > And at some point, I'm sure I'll need to reduce the 
    >   amount of history 
    >   > for each trunk... Is anyone else managing a single 
    >   large repo?  At 
    >   > what point do you decide to remove some of the early 
    >   historical 
    >   > tags/trunk versions?
    >   
    >   I don't even think there are ways of doing this. Disks 
    >   are cheap, but the ability to keep all history is priceless!

Disks are cheap, but the space available to put those cheap disks in is,
plainly, a PITA.  We're repurposing a 2u rackmount server, and it holds a
total of four drives, and the case is now full. Two mirrored OS drives
(don't remember their size...), and two mirrored data drives, around 300GB I
believe.  I should think this would be enough for us, to last a long time,
considering our current server data drive will all the sites, apps AND
documentation is only around 5.6 GB! ;)  We have additional sites on the
live servers totaling at least another 20-30gb though, that we'll be pulling
down.  

But adding more internal disks to this particular server is out of the
question, obviously.  It looks like we'll be okay.

    >   
    >   > Lastly... The server I was going to dedicate to this 
    >   repository is 
    >   > currently an unused FreeBSD server.  I'm still 
    >   cutting my teeth with 
    >   > FreeBSD, but know
    >   > my way around okay.  Setting up subversion on Windows 
    >   was a SNAP.   
    >   > Given the
    >   > size of the repository being proposed, I assume 
    >   there's going to be a 
    >   > lot of files, and we all know how well Windows deals 
    >   with a lot of 
    >   > files... But I definitely know Windows Servers 
    >   better.  Should I leave 
    >   > it as a FreeBSD server for the purpose of it being 
    >   great with large 
    >   > directories (and just great in general), or wipe it 
    >   and put Windows 
    >   > 2003 Server on it for the purpose of eliminating an area of 
    >   > inefficiency for myself?  Will Windows pretty much choke on a 
    >   > repository with 70 websites in it?
    >   
    >   Your call. I'd choose a *nix, and I'd suggest you'd be 
    >   wise to do so, but not everyone will see it that way.

Can you still use TortoiseSVN from a client to use "Repo-Browser", to browse
the repo that would be on the *nix server?  (I think I already know the
answer, but if I am going to be a newbie, I might as well act like one ;)

    >   P.S. You haven't mentioned backup in your plans anywhere...

Yes, we've already planned for backups of the repo server...  They will be
done over the LAN to a backup machine, and from there, out to a
geographically separate storage area as well.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Creating more than one repo

Posted by Tom Mornini <tm...@infomania.com>.
On Sep 29, 2006, at 7:43 PM, Marc wrote:

> Thanks to everyone else for these insights... VERY helpful indeed.   
> At this
> point, I am going to change my plans here:
>
> Instead of putting our repositor(ies) on the hosting servers, and  
> hosting
> the repositor(ies), the staging sites, and the live sites, I am  
> going to
> move ahead with putting a dedicated repository server right here in  
> our
> office.  It will be a single repository, with a trunk for EACH  
> website for
> which we do the development work, and we will stage the sites on our
> internal staging server.  The live sites will still be working  
> copies of our
> local repository.

For ease of deployment, I'd definitely recommend the repositories be  
hosted where they're available on a public IP address!

Rather than working copies, I'd recommend exports, but to each his  
own...

> My question to everyone is, does anyone see a problem with a  
> repository
> "this large"?  I mean, when we load up all our sites into it, it's  
> going to
> be HUGE.  And it'll just grow larger with the revisions.  How large  
> should
> it be allowed to grow?  (server has 300GB RAID 1 right now...)

Subversion repositories grow quite efficiently, as it uses many  
methods to reduce storage space. There are a lot of repositories in  
the world with a *lot* of code in them (think Apache Software  
Foundation) and no trouble.

> And at some point, I'm sure I'll need to reduce the amount of  
> history for
> each trunk... Is anyone else managing a single large repo?  At what  
> point do
> you decide to remove some of the early historical tags/trunk versions?

I don't even think there are ways of doing this. Disks are cheap, but  
the ability to keep all history is priceless!

> Lastly... The server I was going to dedicate to this repository is  
> currently
> an unused FreeBSD server.  I'm still cutting my teeth with FreeBSD,  
> but know
> my way around okay.  Setting up subversion on Windows was a SNAP.   
> Given the
> size of the repository being proposed, I assume there's going to be  
> a lot of
> files, and we all know how well Windows deals with a lot of  
> files... But I
> definitely know Windows Servers better.  Should I leave it as a  
> FreeBSD
> server for the purpose of it being great with large directories  
> (and just
> great in general), or wipe it and put Windows 2003 Server on it for  
> the
> purpose of eliminating an area of inefficiency for myself?  Will  
> Windows
> pretty much choke on a repository with 70 websites in it?

Your call. I'd choose a *nix, and I'd suggest you'd be wise to do so,  
but not everyone will see it that way.

P.S. You haven't mentioned backup in your plans anywhere...

-- 
-- Tom Mornini

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

RE: Creating more than one repo

Posted by Marc <su...@advantex.net>.
Thanks to everyone else for these insights... VERY helpful indeed.  At this
point, I am going to change my plans here:

Instead of putting our repositor(ies) on the hosting servers, and hosting
the repositor(ies), the staging sites, and the live sites, I am going to
move ahead with putting a dedicated repository server right here in our
office.  It will be a single repository, with a trunk for EACH website for
which we do the development work, and we will stage the sites on our
internal staging server.  The live sites will still be working copies of our
local repository.

My question to everyone is, does anyone see a problem with a repository
"this large"?  I mean, when we load up all our sites into it, it's going to
be HUGE.  And it'll just grow larger with the revisions.  How large should
it be allowed to grow?  (server has 300GB RAID 1 right now...)  

And at some point, I'm sure I'll need to reduce the amount of history for
each trunk... Is anyone else managing a single large repo?  At what point do
you decide to remove some of the early historical tags/trunk versions?

Lastly... The server I was going to dedicate to this repository is currently
an unused FreeBSD server.  I'm still cutting my teeth with FreeBSD, but know
my way around okay.  Setting up subversion on Windows was a SNAP.  Given the
size of the repository being proposed, I assume there's going to be a lot of
files, and we all know how well Windows deals with a lot of files... But I
definitely know Windows Servers better.  Should I leave it as a FreeBSD
server for the purpose of it being great with large directories (and just
great in general), or wipe it and put Windows 2003 Server on it for the
purpose of eliminating an area of inefficiency for myself?  Will Windows
pretty much choke on a repository with 70 websites in it?

Thanks again everyone...

Marc

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Creating more than one repo

Posted by Kenneth Porter <sh...@sewingwitch.com>.
--On Thursday, September 28, 2006 6:00 PM -0400 Kris Deugau 
<kd...@vianet.ca> wrote:

> You'll have to do one of:
>
> -> Set up each site on separate IPs, so that services like SVN can
> properly match access to different sites to the matching back-end data.
> -> Switch to HTTP access (please note, not HTTPS, as that will just dump
> you back where you started).  This is probably the best long-term option.
> -> Rethink your repository structures so that you embed the repository
> name in the svn:// url somewhere after the domain name part.

Or run separate servers on different ports. (This would also address the 
HTTPS limitation.) The downside is that you have to explicitly specify the 
port in the URL.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Creating more than one repo

Posted by Kris Deugau <kd...@vianet.ca>.
Marc wrote:
> I used TortoiseSVN to create the repository.  The repository is accessed by
> the clients using svn://svn.domain.com/trunk.  I have an entry in dns for
> svn.domain.com.
> 
> Now, I just created a SECOND website, and again set up a new repository on a
> separate directory on the hard drive, again using TortoiseSVN. I wanted to
> use svn://svn.domain2.com/trunk.  However, when I point the client to THAT
> domain and trunk, I still get the FIRST repository I created.
> 
> We want each website to have its own repository.  I'm clearly doing
> something wrong, since it appears that only the one repository is
> recognized, no matter which repository I enter into the TortoiseSVN client.
> 
> Can someone point me in the right direction?

You're probably running into the same basic limitation that FTP, POP3, 
and a long list of other protols have with respect to supporting 
multiple logical domains on a single IP - the protocol itself doesn't 
have a method to specify which domain you're connecting to.  (I'm sure 
someone will also pipe up if I'm misinformed about this, too.  <g>)

HTTPS has a similar issue in that while HTTP can specify which domain 
you want to deal with, that information isn't available when 
establishing the SSL handshake for an HTTPS connection, so more than one 
website needing HTTPS access can't share an IP.

You'll have to do one of:

-> Set up each site on separate IPs, so that services like SVN can 
properly match access to different sites to the matching back-end data.
-> Switch to HTTP access (please note, not HTTPS, as that will just dump 
you back where you started).  This is probably the best long-term option.
-> Rethink your repository structures so that you embed the repository 
name in the svn:// url somewhere after the domain name part.

-kgd

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org