Yashpal Nagar wrote:
> May be my approach is wrong.. Let me tell you something about my setup.
Good.
> 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..
Yes. Commits to svk slave are synchronously pushed to the master. If
that was your *only* use then there would really be no need for a
slave copy. Because using a slave in this way cannot be commited to
unless the master is also available. In which case you could just
commit to the master directly through normal use of subversion. But
there are other advantages to using svk.
> 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.
Yes to all three of those points. But the real advantage of using svk
is to manage an offline repository to help you work on a local private
branch offline from the main master repository. But this offline work
is a local private branch. Emphasis on branch.
This is very much the same as if you were working on the master
respository but in a branch. Normally (as I have been using it
anyway) with svk a local branch copy of the main trunk is made. One
works in this branch. In the branch, commits can be made without
needing access to the master repository. When these changes are
merged into the slave respository they are also sync'd to the master
repository. Using svk helps to manage all of the merging and sync'ing
back and forth between your offline branch and the online master.
Work offline in the branch. Then when ready to commit get online and
merge into the main trunk.
If a project has a policy of Always-Branch (developing on a branch and
only merging into the trunk later) then svk is a good fit because this
is also the natural methodology of svk. But if your project has a
policy of Never-Branch and "clean commits" then svk may not be as good
of a fit for that situation.
> Now the problem is no clients available for svk setup.
What do you mean by clients? To me 'svn' is a client. To me 'svk' is
also a client. Right? Confused.
Bob
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Mar 24 18:45:54 2005