Interestingly enough, what Paul is suggesting here, "perform all
'non-commit' operations (log, update, etc.) against a local, replicated
server and commits against the remote, central server." is exactly how we
use svk today.
Michael
On 8/28/06, C. Michael Pilato <cmpilato@collab.net> wrote:
>
> Paul Cameron wrote:
> > Hello,
> >
> > I'm not sure if this should be posted to the users or dev alias, please
> > let me know if not appropriate for the dev list.
> >
> > I look forward to the new svnsync feature in 1.4. I see immediate
> > applications for repository backup via replication. I feel another
> > interesting application would be for remote offices to perform all
> > 'non-commit' operations (log, update, etc.) against a local, replicated
> > server and commits against the remote, central server. The obvious
> > benefit would be much improved performance for non-commit operations
> > instigated from the remote offices. I believe this capability would
> > require clients that support two urls for the same repository. Is this
> > feasible and/or planned, or am I way off base here?
> >
> > What other applications do people envision for this new feature?
>
> The biggest thing I was looking forward do with svnsync is the way it
> facilitates backend conversion and staging. A user with BDB
> repositories wishing to convert to FSFS without downtime can currently
> do so with custom scripts and such if they have access to the
> repository, but svnsync provides an easy way to wrap up all the dumping
> and loading and propsetting stuffs that are a part of that recipe. With
> creative use of hook scripts and svnsync, one should be able to set into
> motion a back-end conversion that, at the last possible second, swaps in
> the new repository for the old one with positively minimal downtime.
>
> --
> C. Michael Pilato <cmpilato@collab.net>
> CollabNet <> www.collab.net <> Distributed Development On Demand
>
>
>
>
Received on Tue Aug 29 20:11:37 2006