Re: the state of thought on inter-/intra- project linking/sharing/externals

Matt,

Thank you for your thoughtful response.

Honestly I can't speak to the issue of sharing a file within multiple directories of the same project. I saw someone else had mentioned this deficiency and was trying to generalize. You do make a good point and I believe I agree with it on a user-level, but I'm not sure I support having such restrictions imposed by the tool developers on the users, but that is perhaps a discussion for another day.

As far as sharing files from one project into another, I have more direct experience with this. I find when you have a vast system of well modularized classes shared by several projects, it is often useful to want to use different subsets of such a system in different projects. Not only does this limit bloat from inclusion of unused classes, it also promotes development on stale projects, and regression testing in those projects raises the overall quality of the whole group of projects. Such sharing does raise dependency issues, but I can't immagine this is more of an issue then if these modules had been grouped into directories.

I welcome any feeback.

-Loren

----- Original Message ----
From: Matthew Janulewicz <Matthew.Janulewicz@nextestate.com>
To: techwiseman-svndev@yahoo.com; dev@subversion.tigris.org
Sent: Tuesday, December 27, 2005 11:08:55 AM
Subject: RE: the state of thought on inter-/intra- project linking/sharing/externals

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

---------------------------------------------------------------------
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:56:56 2005