On 11/08/2011 08:55 AM, Markus Schaber wrote:
> Hi,
>
> Von: Miha Vitorovic [mailto:miha.vitorovic_at_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
Received on 2011-11-10 16:30:40 CET