On Mon, Jul 20, 2009 at 8:12 PM, Les Mikesell<lesmikesell_at_gmail.com> wrote:
> Normally you expect version control systems to be able to be able to
> reproduce what you committed. If you commit a symlink you should expect
> to get a symlink back in a checkout, shouldn't you? When you describe
> the behavior of "almost all unix programs" you are conveniently ignoring
> the programs intended to do backup/restore or literal copies (tar, cpio,
> dump, etc.) which would be the the obvious counterpart for the expected
> action. But, why don't you include the 'real' copy in one of the
> places you want it, and after committing it, reference the directory
> holding it as an external in all those other places you want the same
> things to appear?
\It's better to fail outright, and report the failure, than to
mishandle them. Many systems have had problem with symlinks before:
the 'svnadmin hotcopy' command, for example, used to silently skip
over symlinks and not copy them or report the error. (It may still do
so: my patches to make it report an error and fail were not accepted.
Any 'case' statement that does not have a 'what if I failed to
recognize the case' default behavior is, IMHO, broken, but I didn't
have the C++ skills to have the function return a more clever value
and pass it back up the source tree for more sophisticated handling.)
Referencing directories can generate real extraneous nuttiness in your
source tree. It's often only one file, darn it, and the debris
scattered around your filesystem can cause other issues.
Fortunately, subversion-1.6.3, at least, supports having individual
files for svn:external. I think that this could provide precisely what
you need: a single file, pointed to and usable from various locations.
Just be cautious that changes made to the file in one location aren't
actually recorded despite your desires and affect the other branches.
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-07-21 14:39:04 CEST