On Thu, Jan 29, 2015 at 01:40:14PM +0100, Tom Ghyselinck wrote:
> Hi Stefan,
>
> Thank you for you quick reply!
>
> Indeed, I was pointing to some kind of "recursive pinning".
>
> Let me explain a little bit why this would be a great feature
> for our company:
>
> - We have some older projects which use this kind of dependencies
> extensively.
> - Some of our newer projects still use this, but it's correct in it's
> use in that case.
>
> It's not really a matter of "dependencies" as you described it,
> but more some kind of code-reuse.
For the purposes of this conversation I'd argue that's the same thing :-)
Code-reuse implies that you have a piece of code that's being re-used
by other pieces of code, hence there is a dependency between pieces
of code.
> Maven (and other build tools) provide built packages, but in the
> case of code-reuse, we have following situations:
> - Script etc. which are shared with other tools using "common base"
> functions.
> - Sub-projects shared within larger projects. These sub-projects combine
> specific modules which are versioned (read: branched) too and reside
> in their own repository.
Just some food for thought:
Do you use any 3rd party libraries that you didn't write yourself?
Do you use, for example, log4j (assuming it's a Java application)?
Do you use a compiler or build tool you didn't write yourself, and
which includes some basic runtime functionality (like basic memory
handling and string functions)? Do you sometimes upgrade them to
newer versions?
How are you managing those? I doubt you're using externals for them,
becuase you won't have acccess to SVN repositories used by vendors.
If you're managing them somehow why can't you manage your own reusable
libraries in the same way? Are your libraries not re-usable enough to
allow for this, and if they are not, then why not fix that problem instead?
> The thing we are looking for (for a very long time) is a convenient way
> to make a "snapshot" of a certain state of our projects.
> Thus including exact the same state of the sub-projects (externals) and
> modules within theses sub-projects (externals within the externals).
I don't think you'll ever find a nice way of doing this with externals.
You'll always need something sitting above externals to manage them.
Externals can be used to point at things. The fact that you cannot follow
their references in the other direction already makes them almost useless
for managing a mesh of dependencies between projects.
It simply doesn't scale. It is OK for TortoiseSVN to point at Subversion's
core libraries in their build, for example. That makes sense. But if it gets
more complex than that, there are probably other much better solutions.
> Of course this is still more an issue of code-management than
> a VCS issue. But the more the tools can help us to simplify these
> processes, the better life gets :-)
Yes, I agree on this. And I don't think it's in the SVN project's scope.
Subversion's core mission is to version files and directories, not to
manage project inter-dependencies.
Received on 2015-01-29 14:09:00 CET