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

Re: URLs again

From: Karl Fogel <kfogel_at_galois.collab.net>
Date: 2001-02-16 22:09:18 CET

Yah; I don't think anyone's claiming a *functional* difference between
them (anyway, I haven't meant to).


Greg Stein <gstein@lyra.org> writes:
> On Fri, Feb 16, 2001 at 02:52:53PM -0500, Greg Hudson wrote:
> >...
> > Most of the rest of us hail from a mindset where you have a
> > "repository" which is versioned as a whole, like in PRCS. We have
> > some functionality (like checkouts of subdirectories, and selective
> > updates) which allows users to play with sub-hierarchies of the
> > project, but that's just a convenience, a way of getting a narrow or
> > slightly inconsistent view of the larger project.
> $ svn co http://svn.tigris.org/repos/subversion/subversion/libsvn_ra_dav
> or
> $ svn co http://svn.tigris.org/repos/subversion/
> I think that you can still play with sub-hierarchies in the plain-old-URL
> model. In fact, I've been intending for that to work the whole time. There
> should be no difference whether you checkout and work from the root, or
> whether you work from a subcomponent. (and it shouldn't matter, as long as
> the root/component/subcomponent of interest can be checked out!)
> And if you check out the whole thing, you can still:
> $ cd subversion/libsvn_fs
> $ svn up
> >...
> > As for myself, I've been waffling a bit. I think I currently believe
> > in separation, because it means that ra_local doesn't have to
> > artificially decompose the URL into repository and path except perhaps
> > (depending on our user interface) for initial checkouts.
> Note that ra_local can use set_wc_*_prop() to store the decomposed URL for a
> given directory. I've got zero problem with that.
> Formalizing the decomposed URL into public APIs is the problem for me :-)
> Cheers,
> -g
> --
> Greg Stein, http://www.lyra.org/
Received on Sat Oct 21 14:36:22 2006

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.