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

svn modules (was Re: Features and release dates)

From: Eric Gillespie <epg_at_pretzelnet.org>
Date: 2002-05-01 23:40:16 CEST

Karl Fogel <kfogel@newton.ch.collab.net> writes:

> Actually, modules just got a whole lot closer. See recent changes to
>
> http://subversion.tigris.org/issues/show_bug.cgi?id=517
>
> Anyone feel like taking it on?

A co-worker and i have been kicking around the idea of writing code
for symlinks in the repository for internal use (we're anxious to
dump CVS :). We would of course contribute the patch, but i figured
you wouldn't take it until after 1.0. Since it sounds like you
might, let me describe the approach we were planning and see what
you think.

I don't like the text-file based modules. CVS does that and it
drives me nuts. Subversion doesn't really need to duplicate this
feature. All that is necessary is a kind of symlink in the repo.
Clients don't even know that something is a link; they see only a
file or directory (whatever the link points to). We'll probably
want some way for the client to discover if a node is a link or
not (the user might want to know for example), but under normal
operation the client neither knows nor cares.

Let's look at how this would work:

svn co http://foo/repo/trunk/foo/
cd foo
svn ln http://foo/repo/trunk/doctools/ .
svn ci
svn up # at this point the doctools directory becomes populated

# How many copies of the GPL do you have in your CVS repo? :)
svn ln http://foo/repo/trunk/licenses/BSD COPYING

When committing to a link, the client behaves as it always has.
But the ra layer knows this is a link and performs the action on
the link target.

This is more general-purpose and much more flexible than modules.
What does everyone think?

--
Eric Gillespie <*> epg@pretzelnet.org

Conformity is a sin.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed May 1 23:42:35 2002

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.