[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [vote] pin-externals branch to trunk

From: Tom Ghyselinck <tom.ghyselinck_at_excentis.com>
Date: Thu, 29 Jan 2015 13:40:14 +0100

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.
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.

  e.g.
  <project>
      <tool-1>
          <basicfunctions-X>
      <tool-2>
          <basicfunctions-Y>
      ...
      <sub-project-1>
          <module-A>
          <module-B>
      <sub-project-2>
          <module-C>
          <module-D>
          <module-E>
      ...

I understand that only the tree being copied can be modified.

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).

We could also think of an new property on the project branch:
Defining the exact revisions of all sub-projects and modules.

A second way to (possibly) solve this is:
- Defines the external references of the modules in the project instead
  of the sub-project.

- A new problem that arises here is that the required modules by the
  sub-project changes over time. This requires to *update the external*
  references of *all projects* using the sub-modules.

  e.g.
  <project>
      <basicfunctions-X>
      <basicfunctions-Y>
      <module-A>
      <module-B>
      <module-C>
      <module-D>
      <module-E>
      ...
      <tool-1>
      <tool-2>
      <sub-project-1>
      <sub-project-2>
      ...

Our current solution is mostly to "tag" *all dependent externals*,
but this is not a clean way IMHO. When two projects are tagged shortly
after each other, it's sub-projects and modules get tagged twice (or
even more) even when nothing may have changed...

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 :-)

With best regards,
Tom.

On do, 2015-01-29 at 12:33 +0100, Stefan Sperling wrote:
> On Thu, Jan 29, 2015 at 12:14:27PM +0100, Tom Ghyselinck wrote:
> > Hi everybody,
> >
> > I am following this feature with a lot of interest!
> >
> > One question pops up:
> > 1. Suppose I have a branch "B" with external references to "E"
> > 2. "E" has an external reference to "F"
> >
> > When I copy "B" to "C" with --pin-externals, then
> > 1. The external reference "E" will be pinned to e.g. "E_at_999".
> > 2. I suppose "Within" the repository/branch "E", "F" won't be pinned to
> > "F_at_888"
> >
> > Is this correct?
> >
> > I understand this is not what subversion wants/can do since
> > "E" may be in another repository where you don't have access to.
> > But this *does limit* the use-cases of the --pin-externals.
>
> Are you asking if external descriptions within repositories pointed
> to by externals will be pinned (recursively)? If so, the answer is no
> because there is no commit made to other repositories externals point to.
> The copy can only modify externals properties that are part of the tree
> being copied.
>
> Generally, if you rely on this kind of indirection, I think you're stretching
> the use case of this feature far beyond what it was designed for. For example,
> it was never meant to be a full-blown "dependency manager" for source code
> components even though some SVN users tend to (unwisely) use it for such
> purposes. There are other tools which were designed for this kind of thing.
> Apache Maven comes to mind, but there are others outside the Java world.

-- 
________________________________________________________________________
| 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 13:41:12 CET

This is an archived mail posted to the Subversion Dev mailing list.