I can't answer for the dev's, and this post may get moderated off the
list, but I can speak from a user/admin's standpoint.
There's a reason why only VSS supports this kind of linking/sharing. And
there are bigger reasons people move from it to something else.
Linking files from within a source tree point to an underdeveloped
architecture. If there are files scattered about that are shared amongst
multiple projects, or even within a project, you should consider
re-architecting your code so you include a 'common' code base. Or in the
case of files being shared within the same project ... maybe I'm missing
something here, but is this laziness on the developers part? Why have
identical named/content files within a tree in the first place?
Having a web of common files linked to and fro around the whole
structure tends to get rather messy. It's easy to lose track of where a
file originated, and why, why changes were made, why fff.dll has so many
interfaces to it that project ggg does not use (bloat), etc. Eventually
(trust me) a 'common' file that's not properly tracked will *need* to be
branched and you'll end up with two strikingly similar, but not
identical, files.
I've gone through this many times in the past, and when it comes time to
clean up the mess, everyone wishes someone would have had the
forethought to design the common interfaces to the software suite
beforehand, and provide them as a sort of internal 3rd party app.
I doubt this is why the subversion team, as well as most other teams
writing source control software these days, does not develop this kind
of functionality. But eventually, if your team gets in the habit of
sharing files this way, it will become unwieldy and will bite them.
-Matt
-----Original Message-----
From: techwiseman-svndev@yahoo.com [mailto:techwiseman-svndev@yahoo.com]
Sent: Monday, December 26, 2005 10:26 PM
To: dev@subversion.tigris.org
Subject: the state of thought on inter-/intra- project
linking/sharing/externals
I have been using subversion professionally for over 8 months now, and
am looking into its fitness and flexibility for a new project. One of
the biggest concerns I hear from past and current users of VSS is lack
of support for sharing files between or within projects. The answers I
have seen to this are typically to use symbolic links for within a
project (at least under *nix) and use svn:externals between projects.
Each method has its own set of tradeoffs and shortcommings. I'm
interested in bridging these gaps, but would first like to understand
why subversion handles these as it does, and what methedologoical,
design, and implementational considerations went into how subversion is
today.
Symlinks:
For shared files within a project symlinks are usually the most
intuitive answer. They do, however have the following issues:
1) They are implemeted by the client OS, so they are hardly ubiquous.
Even with such concepts as the "Windows Shortcut" (which is hardly a
shadow of a Unix symlink) there is certainly no pairity between
platforms.
2) If a user is checking out only PART of a project the symlink may very
well point to a parent directory that was NOT checked out, and would
therefore be broken.
2b) You can't symlink between projects without knowing where the other
project is to be checked out.
3) symlinks will need to be updated in the event a linked file is
renamed, moved, or removed.
svn:externals
The alternative to symlinks is svn:externals. svn:externals is
implemented WITHIN subversion, so it is much closer to what the problem
we're trying to solve, but it too has some issues:
1) svn:externals only supports directories, not individual files (I
suspect this has something to do with having a single .svn subdirectory
in each directory, but please comment.)
2) commits aren't recursive. (how about updates? etc?) I can immagine
situations where you may want recursive or non-recursive commits. should
this be added, perhaps, as a per-external setting?
3) URLs need to be absolute, making self-referential projects more work
to update in the event of a directory layout change.
Again, these aren't criticisims or value judgements, I'm simply trying
to document what I think I know, so I can get corrections, and
clarifications about WHY the status quo is as it is. Hopefully this
will cultivate some useful discussion on how these features SHOULD work,
and give me (or some other developer) some direction in creating a patch
to add capibilities to subversion.
I really like subversion, and appreciate all of your hard work the past
few years.
Thank you,
Loren Osborn
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Dec 27 20:09:02 2005