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.ghyselinck_at_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
________________________________________________________________________
Received on 2015-01-29 14:51:00 CET