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

RE: Suggestion for special file storage in 1.0

From: Greg Hudson <ghudson_at_MIT.EDU>
Date: 2002-10-14 22:45:38 CEST

On Mon, 2002-10-14 at 16:29, Barry Scott wrote:
> Another issue is what do you save as the contents of a symlink?
>
> If its relative then save its contents.
>
> If its absolute and points inside the working dir then you
> should store the fact that its relative to a point in the repo.
> This is hard to do as you might not have enough repo checked
> out to figure out that what its relative to.

If we add symlink special files to Subversion, then svn shouldn't be
messing with the contents at all. Any symlink to within the working dir
should be stored as relative.

> If I use a makefile these issues are trivia to solve.

Sure, but svn interacts poorly with makefiles (because it doesn't
support a timestamp property), and use cases which aren't about source
won't find it natural to add a "make" step after a checkout.

I'm not a huge fan of symlink special files, but I think people should
recognize that not supporting them is giving something up. All this
talk about wrapper scripts and Makefiles is just rationalization. If I
want to use Subversion to manage local modifications to tetex, which
contains symlinks as part of its distribution or did at one point, then
I will have to take annoying measures (just like I have to with CVS),
unless Subversion supports symlinks. This isn't the end of the world,
it's just a loss.

I think people are resorting to these rationalizations because they are
afraid of simply laying down a subjective statement like "this feature
isn't worth the code complexity."

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Oct 14 22:50:27 2002

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

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