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

RE: RE: Symlinks on Win32...

From: Gale, David <David.Gale_at_Hypertherm.com>
Date: 2006-01-31 19:39:18 CET

Duke Tantiprasut wrote:
> I think it would be good if SVN can natively support symlinks within
> its internal repository tree and manage it itelf rather than relying
> on the file system that is checked out on.
> Perhaps something along the lines of:
> svn link svn://source svn://dest
> The idea is rather than creating a copy (i.e. branch), it would allow
> changes to files in that directory to flow through and not branch.
> Bidirectional would be good, but even just unidirectional link
> svn:externals would be a good start. Editing svn:externals is
> troublesome, it's not easy to just add and remove directory members,
> especially when you need to automate.

I'd second this idea.


  - file1

svn link svn://example.com/foo/file1 svn://example.com/bar/file2

Should produce:
  - file1
  - file2

At which point, the following should be true:
svn co svn://example.com/
cd bar
<change file2>
svn ci
cd ../foo
svn stat -u
U file1

Ideally, "svn link" would support the various wc/repository options that
svn copy & svn move do (wc->wc, wc->repo, repo->repo, repo->wc). It
shouldn't be possible to link to a file that has been deleted (use copy
to resurrect a file instead), as this is rather non-sensical. Only
changes to the contents of a file should propagate; copying/moving a
file shouldn't affect links (or break them--this would be better than
symlinks on linux!), as there isn't anything requiring linked files to
have the same name. I think property changes should also propagate, now
that I'm thinking about it.

Any other design thoughts? Any votes against, or shall we pass this on
to the dev list?


To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Jan 31 19:43:24 2006

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.