On Tue, Mar 11, 2003 at 01:19:33PM -0800, Ben Collins-Sussman wrote:
> Tony Mee <A.J.Mee@ncl.ac.uk> writes:
>
> > That just ain't going to please my sys op. EVER. Now why should I, as a
> > sys op. and hence being the person that is ultimately going to install
> > SVN or CVS pick SVN?
>
> Because Subversion is better than CVS in dozens and dozens of ways.
> Read the front page of the web site.
>
> The truth is, it's designed first and foremost to be a client/server
> system... meant to be networked. And that means hundreds of working
> copies spread across hundreds of computers and hard disks. That
> means minimum impact from the "extra disk" design, and maximum reward
> on the "efficient network usage" aspect. That's the primary use case
> for CVS.
>
> The fact that you can access a repository directly on local disk was a
> concession to a *much* less common use case: the poor student who
> just wants to use svn to privately version stuff in her home directory
> on some big unix machine on which she has no rights. Your use case is
> unusual too: it's not so common to have 15 developers all sharing a
> single disk.
It is common at every UNIX shop I have worked.
All the developers have a PC for Office which also runs Exceed. All
the work is done on big Solaris/AIX/SGI servers.
> > So really it's a case of:
> > a) moving the diffing routines from client process to the server process
> > b) altering the diffing process to get the working copy across the
> > network and pristine copy from the repository
> > c) altering the commit routines to recieve the differences from and
> > local process instead of over the network
> >
> > or maybe better put at a case of moving some streams about and the
> > position of a process in those streams. Not really any new code?
> >
> > Bearing in mind I don't know the code too well (yet). Where is the can
> > of worms kept?
>
> The can of worms is libsvn_wc. But please don't go there. You're
> going to get run down by a gigantic truck. People have discussed this
> topic over and over again: many people want it. But people who have
> been working on this codebase for nearly three years still can't
> fathom how incredibly difficult this change will be. We've
> deliberately tabled the discussion until we reach 1.0. No mere mortal
> will be able to just "jump in and rewrite the code." A zillion
> threads of code all depend on the assumption that the pristine copies
> are present; your description above doesn't even scratch the iceberg.
A good solution might be to get replicated repositories working.
Whomever wants a local copy of the repository can get a slave on his
machine. At that point all the duplication of files can go away.
Cheers,
florin
--
"NT is to UNIX what a doughnut is to a particle accelerator."
- application/pgp-signature attachment: stored
Received on Tue Mar 11 20:54:30 2003