On 10.11.2011 16:21, Neels J Hofmeyr wrote:
> On 11/07/2011 07:14 PM, Miha Vitorovic wrote:
>> On 7.11.2011 16:08, Neels J Hofmeyr wrote:
>>> Can you argue up a case where one would want a non-revision-pegged
>>> 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.
> Agreed -- now: would you be OK if I told you: to omit those dir externals
> from commit, you have to either supply --exclude-externals, or you
> have to
> put the external on a specific revision, say r123, like:
> svn ps svn:externals "^/framework-src_at_123 bin/fw" .
> Like that you could choose for each external: do I fixate it to a
> revision, so that it is not committed automatically? Or do I leave out
> revision number, thus the external is included in commit recursion?
> Whenever a newer framework should be used, you have to modify the
> number in the externals definition and commit that. Subsequent updates
> bring the newer framework externals into all colleagues' WCs.
> Would you be fine with that?
Sorry for not replying sooner - my sentiments were simply not strong
enough either way. But there is something to be said about changing
default behavior. And I think others have done a splendid job doing that.
In short - whatever you (the developers) choose will be fine. I have a
feeling default behavior will remain as it is, though :)
Received on 2011-11-10 22:19:38 CET