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

Re: svn commit: rev 1957 - trunk/subversion/include trunk/subversion/libsvn_wc

From: Karl Fogel <kfogel_at_newton.ch.collab.net>
Date: 2002-05-15 01:14:15 CEST

Branko Čibej <brane@xbc.nu> writes:
> Just a minute. Are you doing all this work /instead/ of adding
> reference nodes to the filesystem? And this will all get ripped out
> once we have reference nodes? Sorry, but I don't like that at all.

Well, not doing all this work if there's a better way :-). I was
never particularly entranced with this method, though I admired its
economy of effort :-). Mainly I just couldn't see a better one,
because I didn't understand any of the reference node proposals (or
rather, I didn't understand how they would solve the modules problem).

> I also didn't find any design doc for this feature, discussing pros
> and cons and tradeoffs vs. reference nodes. I only remember one or two
> posts to the dev list, without any real conclusions.
>
> (Can you point me to the relevant messages if I missed them? Thanks.)

The design doc for these recent commits is in issue #517. There were
a lot of posts to the dev list, mainly about using references --
search for subject "svn modules". The discussion was inconclusive,
yeah.

If I understood *exactly* what you mean by "adding reference nodes to
the filesystem", and how it solves the modules problem, I'd be able to
answer yes or no to your original question. Part of the problem with
the reference-based proposals was that they were light on concrete
details. A general idea would be presented, but then there was a fair
amount of handwaving. The proposal in issue #517 is detailed, and is
known to solve the problem.

If we *can* do this with reference nodes, great! It would be more
"along the grain" of Subversion, rather than against, so to speak.

> -1

Better have an alternate proposal, then :-).

I've just gone back and re-read those posts, so maybe I can put
together a proposal that uses references now. This is totally off the
top of my head -- I have *not* thought it through as much as I've
thought through Jason's proposal in issue #517. I'm just taking your
post as an opportunity to come up with a truly elegant module system,
as opposed to a merely workable one. But if we can't get elegance in
a reasonable amount of time, I think we should go with what's in #517.

Definitions/requirements for a modules system:

   1. A module is an alias, a single name that pulls together various
      sources to make a working copy tree. The sources may have
      specific revisions, or may be floating (i.e., at head).

   2. Modules must be versioned.

   3. Modules must be able to refer to sources in multiple
      repositories.

Okay, two solutions:

   Solution A:
   ===========
      Modules come from description files.
      See issue #517 for details :-).

   Solution B:
   ===========
      Reference nodes.

      First, note that ref nodes are different from symlinks. Making
      Subversion support symlinks is pretty simple:

         $ ln "../foo" bar
         $ ln "my cat's breath smells like cat food" baz
         $ ln "http://svn.collab.net/repos/svn/blah/blah" qux
         $ svn add bar baz qux
         $ svn ci -m "Added three symlinks." bar baz qux

      Subversion does not pay attention to the value (target) of a
      symlink. The values get updated if someone committed changes to
      them, but Subversion doesn't *interpret* the values in any way.

      Okay, now that we've cleared up *that* potential confusion... :-)

      The Subversion filesystem would support a new kind of node,
      called a `reference node'. A ref node is somewhat like a
      symlink, in that it stores text referencing some other source.
      That source might be local, might be in another repository
      entirely, might be a file, might be a dir... might even be a
      symlink! It's type might change from revision to revision (in
      the source repository, I mean -- the repository that contains
      the ref node doesn't know what type the target is).

      When you check out a tree containing reference nodes, each
      reference node is expanded into the appropriate entity. If
      subdir, then a subdir is created; if file, then a file is
      created, etc.

      The entry for the reference (i.e., in the .svn/entries file in
      the directory containing the reference) looks like a normal
      entry for whatever the target type is, but it has a few extra
      attributes (reference-url="http://..." and
      reference-target="http://..." and reference-target-rev="5" or
      somesuch), so that both the reference and its expansion can be
      versioned.

      A `module' is just a directory containing a bunch of references.

      One unanswered question is, how does a client create a
      reference? Make a text file with the reference value in it, and
      then use a special flag at add time?

          $ svn add --reference foo

      Or overload symlinks? I dunno. There are probably multiple
      acceptable solutions for the client-side user interface.

Anyway, is this something like what you had in mind?

-K

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed May 15 01:15:24 2002

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