RE: Re: [RFC] SVN 1.1.x: Shared Files (vs symlinks?)

>> 3) Each share in a group of shared files shall have a list of all
other related
>> shared nodes, so that upon update, all other shared nodes may be
updated to the
>> new root node.

> Might it be better for only the root share to have the list of shared
> nodes, and any share update goes to the root share, and is then
> propgated to other secondary shares if relevant.

Wouldn't symlinks do this automatically? Assuming symlinks are made to
handle this use case, which is what this discussion is basically in aid
of.

Say I have the following library files

  (repos)\library\trunk\include\xx.h
  (repos)\library\trunk\include\yy.h

And a project
  (repos)\project\trunk\...

If I create a symlink:

  (repos)\project\trunk\include --> \library\trunk\include

Then I will apparently have the following files:

  (repos)\project\trunk\include\xx.h
  (repos)\project\trunk\include\yy.h

.. which will track any change made to library\trunk, and any changes
made to project\.. will be automatically committed to library\...
'instead'

Basically what this means is a double lookup (on the SERVER side) on
every check out and every commit on a sym link, or where a symlink is
involved somewhere in the URL. Whereas pointing direct to the nodes
requires saves the extra URL lookup, but requires propagation.

(There might need to be some handling of someone checking in changes to
two URLS that resolve to the same location (eg both the symlink and
trunk), but this same problem would occur for shared files too. At the
moment it may be handled as an error condition because it could occur,
but only with a malformed commit request (commit the same file twice in
a single transaction)

With shared files, often what I actually want is to share a *released
version* of library code, not the trunk version. This could be done in
two ways, both valid I think.

1. Point the symlink to the release branch

  (repos)\project\trunk\include --> \library\branches\v2.1\include

(no extra work required!)

2. Include a revision number in the symlink

  (repos)\project\trunk\include --> \library\trunk\include at revision
314

The only issue I have with 1. is that the branch may possibly want to be
read-only. Repository permissions (eg mod_authz_svn) can enforce that.
The main issue with 2. is that it complicates the symlink design, and
also it is then inherently read-only, a concept that probably needs to
be worked through (ie at the moment you CAN'T attempt to commit to a
specific version number and the idea is ridiculous).

- Walter

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Apr 21 23:20:01 2004