I really meant to reply sooner ...
Karl Fogel wrote:
>Branko Čibej <brane@xbc.nu> writes:
>
>
>>-1
>>
>>
>
>Better have an alternate proposal, then :-).
>
Coming, coming ...
>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.
>
This would be a nice feature, but it's not a must for 1.0, and in fact
the client doesn't know how to handle working copies that refer to
multiple repositories (yet).
>Okay, two solutions:
>
> Solution A:
> ===========
> Modules come from description files.
> See issue #517 for details :-).
>
> Solution B:
> ===========
> Reference nodes.
>
>
>
[snip stuff about symlinks]
> 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.
>
This is basically it, but I'll expand a bit. I think we'd need two kinds
of references -- local (intra-repository) and global (inter-repository).
Whether those are implemented using the same node type isn't important
now. Global refs aren't necessary for 1.0, and are a huge problem by
themselves, so I'll ignore them.
In the FS, a local reference node would store the FS path (not the URL!)
of the target and (optionally) a revision number. If the rev number is
absent, the path refers to HEAD. Conflict resolution for ref nodes is
the same as for files.
On the client side, some commands have to be aware of ref nodes, and
there are usually two choices for the semantics: e.g., does "svn copy"
copy the reference or the target? The simplest answer is to treat
references like unix treats symlinks.
> 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.
>
>
You can't overload symlinks, because they aren't available everywhere.
What you need is a new command:
svn link [-r REVISION] TARGET SOURCE
where both SOURCE and TARGET can be either a WC path or an URL (into the
same repository), and revision refers to TARGET, of course. If SOURCE is
an URL, this caises an implicit commit of the link. If SOURCE already
exists and is a reference, this command would modify the reference itself.
There's also the question about how you remove a reference node. You
have two choices:
* "svn rm" on a reference always removes _just_ the reference, not
the target
* "svn unlink" removes only references; "svn rm" removes only
targets, but requires --force
I'm sort of leaning towards the first solution.
Come to think of it, "svn link -r" would be sort of like a tag, too ...
--
Brane Čibej <brane_at_xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri May 17 05:53:34 2002