Local repository access

["J. David Blackstone" <jx...@omega.uta.edu>]

  A picture really is worth a thousand words...

  I've been lurking on the subversion development list for a couple of
months, now.  I just checked out the new status document (Thanks, Ben!)
and noticed the diagram taken from the design document.  I've probably
seen it before, but a lot more things make since now than did two months
ago.

  I see two lines from "Repository Access Method" to "Subversion
Filesystem," one of which goes through "Local Repository Access."

  I realize local repository access has been discussed a little bit in
recent messages, but I was under the impression that the item "It is
natively client-server, hence much more maintainable than CVS. (In CVS,
the client-server protocol was added as an afterthought. This means that
most new features have to be implemented twice, or at least more than
once: code for the local case, and code for the client-server case.)"
in the design document implied that there would be no local access to
the repository -- everything would be funnelled through the network
layer.  I assumed that someone wanting access to a local repository
would simply point their CVSROOT/SVNROOT at the machine they were
working on.

  I realize local repository access has been relegated to a lower
priority, but I wonder why even create it at all.  It seems to me that
it makes two access paths to the repository resulting in more work and
more possibility of corrupted data.

  Just curious.

                       J. David Blackstone

Re: Local repository access

["Chris D. Sloan" <cd...@cs.hmc.edu>]

Hi,

I'm another lurker who has been lured out of the shadows to offer an
opinion.

Another advantage of local access to the repository is not having to
run a server.  If you want to run a repository on a machine you do not
own, having to have a sever running could be a problem.  You would
have to convince the admins that it was secure and that they could
trust you to run a service like this all of the time on their
machine.  I'm not sure that I understand subversion well enough to
conclude this, but I believe that setting up local access only
basically solves these issues.


Back to introductions:  My name is Chris Sloan.  I work at Green Hills
Software on an embedded operating system.  One day (about seven months
ago) I stumbled upon the Subversion web site and was really impressed.
All of my major complaints about CVS (which I use for myself as well
as for work) were listed as things that Subversion would fix and/or do
better.  I would like to contribute to the coding, but at the moment I
do not have the time to do so, so I content myself with skimming the
mailing list and eagerly waiting until Subversion is ready for use.

Keep up the good work.

	Chris


On Wed, Feb 28, 2001 at 01:16:50PM -0600, Ben Collins-Sussman wrote:
> Karl Fogel <kf...@galois.ch.collab.net> writes:
> 
> > >   I realize local repository access has been relegated to a lower
> > > priority, but I wonder why even create it at all.  It seems to me that
> > > it makes two access paths to the repository resulting in more work and
> > > more possibility of corrupted data.
> > 
> > Efficiency and debuggability. [...]
> > 
> > The extra work is not very great, as the code path for local access is
> > extremely short.
> 
> Also, I should add:  if you're just a lone user who wants to version
> some small, private thing on your personal machine (say, your /etc
> dir), do you *really* want the overhead of installing Apache and
> mod_dav?  It's like swatting a fly with a Buick.
> 
> This "simple" scenario is the most common use-case for tools like RCS
> and SCCS.  Newbies still use CVS to scratch this itch, though.  Why?
> Because CVS handles this use-case with just as little overhead as the
> older tools.  I believe, therefore, that Subversion should handle this
> use-case just as efficiently.
>

Re: Local repository access

[Ben Collins-Sussman <su...@newton.ch.collab.net>]

Karl Fogel <kf...@galois.ch.collab.net> writes:

> >   I realize local repository access has been relegated to a lower
> > priority, but I wonder why even create it at all.  It seems to me that
> > it makes two access paths to the repository resulting in more work and
> > more possibility of corrupted data.
> 
> Efficiency and debuggability. [...]
> 
> The extra work is not very great, as the code path for local access is
> extremely short.

Also, I should add:  if you're just a lone user who wants to version
some small, private thing on your personal machine (say, your /etc
dir), do you *really* want the overhead of installing Apache and
mod_dav?  It's like swatting a fly with a Buick.

This "simple" scenario is the most common use-case for tools like RCS
and SCCS.  Newbies still use CVS to scratch this itch, though.  Why?
Because CVS handles this use-case with just as little overhead as the
older tools.  I believe, therefore, that Subversion should handle this
use-case just as efficiently.

Re: Local repository access

[Karl Fogel <kf...@galois.collab.net>]

"J. David Blackstone" <jx...@omega.uta.edu> writes:
>   A picture really is worth a thousand words...
> 
>   I've been lurking on the subversion development list for a couple of
> months, now.  I just checked out the new status document (Thanks, Ben!)
> and noticed the diagram taken from the design document.  I've probably
> seen it before, but a lot more things make since now than did two months
> ago.
> 
>   I see two lines from "Repository Access Method" to "Subversion
> Filesystem," one of which goes through "Local Repository Access."
> 
>   I realize local repository access has been discussed a little bit in
> recent messages, but I was under the impression that the item "It is
> natively client-server, hence much more maintainable than CVS. (In CVS,
> the client-server protocol was added as an afterthought. This means that
> most new features have to be implemented twice, or at least more than
> once: code for the local case, and code for the client-server case.)"
> in the design document implied that there would be no local access to
> the repository -- everything would be funnelled through the network
> layer.  I assumed that someone wanting access to a local repository
> would simply point their CVSROOT/SVNROOT at the machine they were
> working on.
> 
>   I realize local repository access has been relegated to a lower
> priority, but I wonder why even create it at all.  It seems to me that
> it makes two access paths to the repository resulting in more work and
> more possibility of corrupted data.

Efficiency and debuggability.  Since the client and repository
interfaces are very well-separated, local access really is a case of
just not using the network layer and doing everything else pretty much
the same.  And it's useful to be able to test certain functionality
with and without networking, to isolate bugs.  The bug will often be
present in both cirmcumstances, but it's a lot more convenient to use
GDB in the latter scenario. :-)

The extra work is not very great, as the code path for local access is
extremely short.

-K