Von: Janosch Scharlipp [mailto:Janosch.Scharlipp_at_isys-vision.de]
> we are using externals to include common functionality (via source code)
> to our projects. So we have the following structure:
> CommonRepo (http://mysvn/common):
> - source files
> ProjectXRepo (http://mysvn/projectx):
> - project specific source files
> imports (has externals property)
> - source files from common
> Now we have two competing requirements:
> 1) We need to be able to develop common files as part of a project
> 2) We need to be able to reproduce old states of the projects exactly as
> were, when the state was commited
> From which i concluded:
> 1) We can use externals for this, filesystem links/file copies are error-
> and cumbersome
> 2) Externals have to be fixed to a specific revision
> This should in fact be enough to always have consistent states in the
> project repository, but sadly i can make the following mistakes without
> anyone noticing:
> a) I can update the externals folder (imports/common), this operation ignores
> that it had been fixed to a revision. (i think the reason is, that the fixed
> revision is only known to the parental project, and an update does not check
> whether it is applied to an externals folder)
> b) I can make changes inside the externals folder, commit them (and generate
> a new revision in the CommonRepo) without the parent project noticing it.
> (commit says: no files have been changed)
> c) After b) i can make changes in the project itself, commit them, without
> getting any information that my local state is inconsistent.
> These inconsistent states can only be detected on the client-side, from
> the perspective of the server, everything is fine. Setting externals to
> tags instead of revisions doesn't help, since it will subvert my first
> requirement. (and is very uncomfortable for the developer)
The traditional way to catch this is a continous integration system. When the build server builds, it will fail because it still gets the old, pinned external which does not provide the new interfaces.
It will only catch it "after the fact", but clearly before the code goes into production. And CI has enough other advantages to justify its existence.
> The following enhancements to TortoiseSVN would make this scenario work:
> - Prevent updates of externals-directories, or the fixed revision on the
> directory by the new revision number, so the project directory has a
> - Commits to externals-directories have to replace the fixed revision on
> parent directory too
> - Commiting changes in a project that has externals should check for
> * are all externals on a fixed revision?
> * are those externals realy on this revision on the harddisk?
TortoiseSVN supports client-side pre-commit hooks. You can deploy such a hook in your working environment to check the externals actual version vs. the declared version from the property, and prevent accidentally wrong commits that way.
> Does this make sense, or am i mistaken in some point? I think with these
> enhancements usage of externals could become secure.
> Kind regards,
> Janosch Scharlipp
> P.S: In the end, i additionally need to make sure on server side, that
> these checks have been performed, so this information should be somehow
> part of the commits meta-data ("externals have been checked for
On the server side, you could possibly also add some hook to check whether a commit which touches the common directory also updates at least one of the svn:externals properties referencing them.
We software Automation.
3S-Smart Software Solutions GmbH
Markus Schaber | Developer
Memminger Str. 151 | 87439 Kempten | Germany | Tel. +49-831-54031-0 | Fax +49-831-54031-50
Email: email@example.com | Web: http://www.3s-software.com
CoDeSys internet forum: http://forum.3s-software.com
Download CoDeSys sample projects: http://www.3s-software.com/index.shtml?sample_projects
Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2012-07-10 08:21:36 CEST