[...]
> 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'd just like to +1 here.
I don't use symlinks on my maintained code either, but I have worked a
long time on a thirdy part software which used symlinks in the source
tree, and I confess it was a nightmare. To workaround the problem we
were uncompressing the tarball with "h" parameter (dereference
symlinks), and importing in the tree. Unfortunately, each time we had
to modify a file which had a symlink pointing to it, we had to filter
the patch before mailing to the maintainer, since it contained changes
in both versions (symlink and real file). We could have used some hack
in the makefile or another script, as barry mentioned, but we noticed
that this would introduce other inconveniences as well (I remember that
keeping track of symlink changes was one of them). Also, the maintainer
itself wasn't using CVS just because of that trouble (he could give up
on symlinks, but didn't want to, and implemented his own way to maintain
the code).
One of the features which catched my attention the first time I met
subversion was the purpose to include symlink support in the future. I
hope we aren't giving up on that now.
--
Gustavo Niemeyer
[ 2AAC 7928 0FBF 0299 5EB5 60E2 2253 B29A 6664 3A0C ]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Oct 16 20:05:03 2002