On Monday 05 April 2004 21:17, John Peacock wrote:
> Stephen Warren wrote:
> > Ah. You're talking about porting an existing, say Unix, application to
> > Windows, where that application's current source directory structure uses
> > symlinks.
>
> What I'm saying is that is the one place I am aware that symlinks are
> frequently used (Unix source) which doesn't map to Windows all that well.
> There could be others (common include files for webservers which don't
> support some form of global includes) that I haven't thought of yet.
>
> I haven't seen a lot of discussion about what use case versioning symlinks
> really supports. I can definitely see having links _within_ the
> repository, so that the use of svn:externals would really only be needed
> for external files to a given repository. But I have no idea why you would
> want to version filesystem symlinks in the repository. Better to have the
> Makefile recreate the symlinks (copies on Windows) before building...
>
> John
SubVersion is not only used to version source code, ya know :-) For example,
my job is to maintain our embedded Linux distribution, our build system and
the resulting products. Everything under SubVersion control. At the end we
get some directories which you think of as chroot directories: complete Linux
trees which are then packaged into what I call hull-images: dd images of
flash discs that are partitioned and have SYSLINUX installed but nothing else
(no kernel, no binaries, nothing). We fill in the "chroot" directories into
these hull images.
It'd be nice to be able to version these "chroot" directories, but we can't as
they contain symlinks and there is no way to reproduce the symlinks
afterwards.
It's no problem that we can't, as we produce CPIO and dd images at the same
time, so we simply version the dd images (as these are what are flashed). But
if we'd be able to version the "chroot" directories as well (including
symlinks) we'd be able to tell any differences between two binary versions
more easily (and there are symlinks that change, especially in /etc/rc.d).
And in case you're wondering: of course we do know what SHOULD have changed as
we've patched the source ourselves, but due to bugs, mistakes or cosmic rays
sometimes the resulting binaries do not contain the changes they should
contain, and a simple svn diff would show whether the resulting
binaries/scripts/or even symlinks changed.
C'ya,
Marc
--
Marc Haisenko
Systemspezialist
Webport IT-Services GmbH
mailto: haisenko@webport.de
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Apr 6 10:58:14 2004