Early Ehlinger wrote:
> Finally, a source-control system with a feature compelling enough to
> justify the headache of switching from the closed-source Visual Source
> Safe (multi-file commits)! Kudos to the entire SVN team! A fabulous
> piece of work.
>
> I only have one minor question...
>
> In VSS I was able to set up files that were "shared," which is similar to
> the SVN concept of copy-via-hardlink. The difference is that as the
> original file is updated, the shared-version keeps pace, whereas an SVN
> copy-via-hardlink file retains the "old" version.
>
> Does the same functionality exist in SVN, and I'm simply missing it?
>
> FYI, I've only found one practical use for this in VSS, but it's something
> that I've come to rely on:
>
> I've got a Borland C++ Builder library that I maintain. In BCB, the
> resource describing a GUI form is stored in a .dfm file that gets linked
> into the .exe. I've got a generic About dialog in this library, which a
> number of other applications use, and its .dfm is set up via VSS to always
> appear in a bin folder, even though the source for the dialog is in the
> source folder. This way the clients of the library link against the .dfm
> without having to add the source folder to their search path (which would
> introduce other problems). If BCB had a decent project manager, I would
> simply add a post-build step that copies the .dfm to the right place.
> Alas, though BCB doesn't, which is why I've been relying on the VSS
> feature.
Looks like svn:externals might be able to achieve what you want, probably in
a more sensible way than VSS hard links. Have a look at the book section
"Externals Definitions", which can be found at
<http://svnbook.red-bean.com/html-chunk/ch07s03.html> currently.
Philip Miller
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Feb 16 14:31:55 2004