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

Re: Master/slave setup

From: Yashpal Nagar <yash_at_linux-delhi.org>
Date: 2005-03-24 06:17:57 CET

On Thursday 24 Mar 2005 2:35 am, Steve Greenland wrote:
> >
> > How does other pepole use svk setup repositories?
>
> You don't. Each developer has their own svk repository, based on the
> "master" subversion repository. That's the whole point. Each developer
> can work on their own stuff, pulling in updates from the master as
> desired, committing back to the master when work is completed.
>
> Steve

May be my approach is wrong.. Let me tell you something about my setup.

We have two development centers geographically apart. Now the idea was if we
setup a slave server at second location. And when all developers commit on
slave that goes to master and back forth. I setup svk at slave & its
working..

Till now i am able to achieve the following
1. Commit on slave possible as long as master is available
2. when commit on slave it simultaneously push the commit to master and then
pull back to slave if anything committed on master in mean time.
3. All developers need to relay on slave and sync between master & slave is
done transparently.

Now the problem is no clients available for svk setup.
Agreed i can run svnserve on svk setup repository as Tom suggested but that
bypass whatever svk does :(
It only commits to slave, does't do back forth. So only slave gets updated.

Questions:
1. Is this approach right?
2. If you said each developer does have their own repository & talking to
master then what is the role of slave?
3. do i need to run svk on all clients(developers workstation) talking to
master?

Regards,
Yash

 

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Mar 24 06:23:21 2005

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.