On 11/08/2011 08:55 AM, Markus Schaber wrote:
Hi,
Von: Miha Vitorovic [mailto:miha.vitoro...@gmail.com]
On 7.11.2011 16:08, Neels J Hofmeyr wrote:
Can you argue up a case where one would want a non-revision-pegged
external excluded from commit? I'm reluctant to take simply previous
externals behavior as argument, because externals have always sucked so far.
I can :)
I spend my days writing "code" in LabVIEW. In short, it's a graphical
programming language. Its files are a sort of combination of source code and binary. We
have our projects organized around a common framework The framework is included in the
projects using externals. Don't ask me why, but recompiling a project also recompiles
some framework files. As a result this marks them as modified for Subversion. And when
committing the project we really don't want to have those framework files committed as
well.
I know it is not Subversion's fault this happens, but it is a use-case for not
committing external files.
This looks more like an use case for an Ignore-on-Commit feature (like
TortoiseSVN emulates via ChangeLists.).
The general problem is to ignore certain files / subdirs on commit, the
recommended workaround sometimes is to use templates and the build system. Your
workaround was using externals, as that just happened to work with SVN 1.6 and
your project layout.
Exactly. The thing is, many users right now rely on the fact that all dir
externals are excluded from commit recursion. I actually want externals to
continue being useful for this "exclude from commit" use case.
It seems to me that excluding only those externals (dir & file) that are
fixed to a specific revision is the best solution. My only worry are all
those users out there expecting dir externals to be excluded always.
That's why I'm asking: if I told everyone to place a specific revision in
their externals definitions to be able to exclude them from commits, would
that cause major havoc?
~Neels
