You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Rafael Garcia-Suarez <ra...@hexaflux.com> on 2002/10/14 08:03:50 UTC

svn ln (symlink in repositories)

As there was some discussion on the possibility of storing symlinks into a
repos, I'd like to suggest something :

symlinks (or hard links, for that matter) are basically directory entries
that point to the same file. Instead of implementing Unix symlinks in the
repository (with all the portability problems), it could be useful to have
a 'svn ln' command, similar to 'svn cp', but that doesn't create a new
branch.

In other words, if you do
	$ svn ln foo bar
then it creates the resource '/path/bar' in the repository, as
a copy of '/path/foo', but in a way that '/path/bar' is always
updated when '/path/foo' is changed (and vice-versa). (For any
revision N > rev number where bar is created, foo@N and bar@N
are the same.)

When convenient or possible, bar could be created as a symlink
to foo in a working copy, but I don't see a high need for this.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: svn ln (symlink in repositories)

Posted by Nuutti Kotivuori <na...@iki.fi>.
Rafael Garcia-Suarez wrote:
> As there was some discussion on the possibility of storing symlinks
> into a repos, I'd like to suggest something :
> 
> symlinks (or hard links, for that matter) are basically directory
> entries that point to the same file. Instead of implementing Unix
> symlinks in the repository (with all the portability problems), it
> could be useful to have a 'svn ln' command, similar to 'svn cp', but
> that doesn't create a new branch.

A very big -1 on the word "instead". There are two completely
orthogonal things, which solve different problems. 'svn ln' for the
repository would be good in my opinion - and it has been suggested
before - but it is a different thing. What the discussion was about
was symlink _storage_ in a repository. The mail I wrote that was the
start of the recent discussion specifically excluded repository-side
symlinks from the scope.

-- Naked

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: svn ln (symlink in repositories)

Posted by Noel Yap <ya...@yahoo.com>.
--- Rafael Garcia-Suarez
<ra...@hexaflux.com> wrote:
> As there was some discussion on the possibility of
> storing symlinks into a
> repos, I'd like to suggest something :
> 
> symlinks (or hard links, for that matter) are
> basically directory entries
> that point to the same file. Instead of implementing
> Unix symlinks in the
> repository (with all the portability problems), it
> could be useful to have
> a 'svn ln' command, similar to 'svn cp', but that
> doesn't create a new
> branch.
> 
> In other words, if you do
> 	$ svn ln foo bar
> then it creates the resource '/path/bar' in the
> repository, as
> a copy of '/path/foo', but in a way that '/path/bar'
> is always
> updated when '/path/foo' is changed (and
> vice-versa). (For any
> revision N > rev number where bar is created, foo@N
> and bar@N
> are the same.)
> 
> When convenient or possible, bar could be created as
> a symlink
> to foo in a working copy, but I don't see a high
> need for this.

I think creating "svn ln" would also be a convenient
way to create tags since a hard link to a particular
revision should automatically be read-only.

MTC,
Noel

__________________________________________________
Do you Yahoo!?
Faith Hill - Exclusive Performances, Videos & More
http://faith.yahoo.com

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org