Hi Stefan, Thank you for your notes!
On do, 2015-01-29 at 14:08 +0100, Stefan Sperling wrote: > 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? > Actually we do use 3rd party libraries and projects: We also "dumped" these either "source-based" or "pre-built" in our svn repositories. These often have (rather small) changes or additional files to integrate them into our build system. > 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? > Our build tools and compilers are managed by virtual machines with a fixed configuration. So this is rather hard to manage "version" code in a similar way. > > 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. > I totally agree! > 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. We have a meeting about code management in our team next week and I'll gladly take your notes with me ;-) Thanks! With best regards, Tom. -- ________________________________________________________________________ | tom.ghyseli...@excentis.com | | Tom Ghyselinck | Senior Engineer | Excentis N.V. | Gildestraat 8 B-9000 Ghent, Belgium | Tel: +32 9 269 22 91 - Fax: +32 9 329 31 74 ________________________________________________________________________
